Introduction: The Morning Card Payments Stopped Working Across Japan

On the morning of July 16, 2026, credit card payment outages occurred across Japan. From shortly after 8:00 a.m., some credit cards could no longer be used at convenience store registers, at station ticket machines, for Mobile Suica top-ups (Mobile Suica is JR East’s smartphone-based transit card), and on e-commerce sites. Some stores began directing customers to pay with cash or other methods.

For those of us working in IT operations and maintenance, this outage raises a particularly thought-provoking point: some businesses were unable to provide their services even though their own systems had not failed.

In fact, one card issuer explained that there had been no problem with its own systems, and one payment network operator stated clearly that the outage was “not our failure.” Yet from the user’s perspective, the situation was the same: the card simply did not work.

In this article, I review how the outage unfolded based on companies’ published information and media reports. I then examine a challenge facing modern system operations, namely that a service can be affected by external services even when nothing is wrong internally, in light of ITIL practices such as relationship management, supplier management, and incident management.

Regarding the cause, Visa’s Japanese subsidiary has explained that the outage resulted from a program change. However, the relationship between this cause and the outage information published by each company has not been fully clarified. In this article, I keep the facts published by each company separate from the operational lessons that can be drawn from them.

Chapter 1: What Happened? Differing Explanations from Each Company

First, let’s review the events of July 16, 2026, in chronological order based on published information.

Around 8:10 a.m.: Sumitomo Mitsui Card, one of Japan’s largest card issuers, later announced that from around this time cards could not be used at some merchants.

Morning: CARDNET (Japan Card Network), a payment network that connects merchants with card companies, detected a higher-than-normal number of payment errors and posted several outage detection notices on its merchant-facing page.

Around 10:00 a.m.: On JR East’s Mobile Suica, the issue that had made card payments difficult due to an outage in an external credit card system was resolved.

Around 10:40 a.m.: A recovery notice was posted on CARDNET’s merchant page. ITmedia NEWS also reported that the outage appeared to have been resolved by around this time.

Shortly after noon: Sumitomo Mitsui Card announced recovery. The company stated that the outage lasted from around 8:10 a.m. to around 12:08 p.m.

What stands out here is that the explanations of the outage differed depending on the company involved.

Sumitomo Mitsui Card attributed the problem to an “international brand network failure,” meaning a failure in the network of a global card brand such as Visa or Mastercard.

JR East explained that the difficulty with Mobile Suica top-ups and related payments was due to a failure in an “external credit card system.” However, it did not specify which system had failed.

CARDNET, meanwhile, explained that the outage was not a failure of its own system. According to the company, the outage information on its merchant page reflected its detection of an unusually high number of payment errors at merchants, and did not indicate a failure of its own system.

In other words, the situations each company was aware of, and the scope of what each was explaining, were not the same.

The announced recovery times also differed: 10:00 a.m. for Mobile Suica and around 12:08 p.m. for Sumitomo Mitsui Card. This does not necessarily mean the explanations contradict one another. Because each company uses different systems and monitors a different range of services, the timing at which the impact cleared may also have differed.

For users, it was a single problem: “my card doesn’t work.” Behind the scenes, however, multiple systems and businesses were involved. Grasping the full picture immediately after the outage began was likely far from easy.

Chapter 2: The Cause as Explained by Visa

On July 17, 2026, the day after the outage, Visa’s Japanese subsidiary explained the cause.

According to a report by ITmedia Mobile, Visa’s Japanese subsidiary responded as follows:

“The incident was caused by the effects of a program change to a merchant connectivity service, and was not caused by an external attack or similar.” (translated from Japanese)

The company stated that the cause was the effect of a program change in Cybersource, a merchant connectivity service provided by Visa.

Regarding VisaNet, Visa’s core network, the company explained:

“It continued to operate normally throughout the incident and was not affected.” (translated from Japanese)

In other words, according to Visa, the outage was caused not by an external attack but by the effects of a program change in Cybersource, while VisaNet itself continued to operate normally.

Cybersource’s official status page also records delays and timeouts in payment processing on July 16, 2026.

What draws my attention here is that a program change triggered the outage.

As discussed in a previous article, changes to a system can affect the stable operation of a service. In this case too, according to Visa, a program change led to the outage.

However, whether the testing and approval associated with the change were appropriate cannot be determined from the published information. The fact that a program change was the cause does not allow us to conclude that change management was deficient.

It also cannot be fully confirmed from the published information to what extent the “international brand network failure” described by Sumitomo Mitsui Card and the Cybersource disruption described by Visa refer to technically the same event.

Even so, there are lessons to be learned from this outage.

Namely, even when your own systems are functioning normally, a failure in an external service can disrupt the delivery of services to users.

Chapter 3: Why Services Stop Even When “Our Systems Are Fine”

Looking at this case from an operations and maintenance perspective, we need to focus not only on the program change itself but also on the fact that payment services are supported by many businesses.

When we shop with a credit card, a wide range of systems work together behind the scenes: merchants’ payment terminals and e-commerce sites, payment service providers, merchant connectivity services, card companies, and the networks of international card brands.

The actual payment route differs by service, but in every case multiple businesses share the work.

Users are normally unaware of this mechanism. However, if one of the external services required for payment fails, the payment may not be completed even if all other systems are operating normally.

In this case, Sumitomo Mitsui Card stated there was no failure in its own systems, and CARDNET also stated that the failure was not its own. Even so, some card payments became unavailable.

The impact was not limited to card companies. Convenience stores, e-commerce sites, and transportation services also reported that card payments were unavailable or difficult to use.

Looking at this situation, I see the same problem as in the telecommunications and cloud infrastructure outages discussed in previous articles.

That problem is dependency on external services that are difficult to see from inside your own organization.

Even if there is nothing wrong with your own servers or network, if a service further down the chain stops, your service will be affected too.

Moreover, at the moment an outage occurs, it may not be clear which external service is the cause. If the cause lies not with a company you contract with directly but with a service used further down the chain, understanding the situation becomes even more difficult.

In operations, once you have confirmed that your own systems are running normally, you may be tempted to breathe a sigh of relief.

From the user’s perspective, however, it makes no difference whether the failure lies in your system or in an external service. If the service they want to use doesn’t work, they experience it as the same outage.

Seen this way, shouldn’t we treat “our systems are operating normally” and “we are able to deliver the service to users” as two separate things?

Preparing with ITIL

So how can those responsible for operations prepare for outages caused by external services?

Drawing on ITIL practices, let’s consider what to keep in mind in day-to-day operations.

Relationship Management and Supplier Management: Understanding the Chain of Dependencies

ITIL includes relationship management, a practice for maintaining and improving relationships with the stakeholders involved in a service, and supplier management, a practice for managing the suppliers needed to deliver services.

What I want to consider from this case is the importance of looking not only at the parties you contract with directly but also at the external services they use in turn.

In services like payments, where many businesses are involved, a failure at a business or service used by your direct contractor, not just at the contractor itself, can affect you.

Of course, understanding every dependency is not realistic. Contractual or security reasons may prevent you from examining the configuration of external services in detail.

Even so, you should at least identify which external services have a major impact on your own services.

For example, it may be worth confirming the following points for important external services:

Which operations and systems depend on that external service?
If an outage occurs, how far will the impact spread?
From whom, and through what channels, can outage information be obtained?
If the outage is prolonged, is there an alternative?

In particular, it is important to clarify contact methods and the scope of information sharing during outages through contracts and operational agreements with contractors.

If you only start asking “who should we contact?” after an outage has occurred, your initial response will be delayed.

Incident Management: How to Respond When the Cause Is Unknown

In this outage, the cause was not clear immediately after it began.

While Sumitomo Mitsui Card, CARDNET, and others denied failures in their own systems, users remained unable to use their cards.

This is where ITIL’s incident management comes into play.

Incident management prioritizes minimizing the impact on the service and restoring normal operations over identifying the root cause.

In other words, not knowing the cause does not mean you can put your response to users on hold.

For example, if there appears to be a problem with an external payment service but the details are unclear, you can still communicate what has been confirmed so far:

“Some credit card payments are currently unavailable. The cause is under investigation. Please use cash or other payment methods.”

In this way, you can communicate what is happening without asserting a cause, and guide users on the actions they can take.

In fact, it was reported that during this outage some stores directed customers to use cash, transit IC cards, or QR code payment services.

On the other hand, in an outage involving multiple businesses, deciding what to tell users also becomes difficult.

Unless you separate the facts you have confirmed yourself from the information provided by external businesses, you may end up communicating the wrong cause. And if recovery status differs between businesses, what you tell users will change as well.

That is why it is important to decide in advance where to gather information during an outage, how internal communication will work, and how to inform users.

Even when the cause is unknown, communicate what is happening, what is currently being checked, and what users should do.

This kind of initial response helps reduce confusion during an outage.

Service Continuity Management: Alternatives When External Services Stop

Another perspective to consider is service continuity management.

In this outage, some stores were able to accept cash or other payment methods even when credit cards could not be used.

However, not every service can provide alternatives in the same way. In operations that depend on online payment or on specific external services, users may have no other option.

And even if multiple payment methods are available, they may be affected at the same time if they depend on the same payment infrastructure.

This is easy to overlook when thinking about service continuity.

Beyond simply offering multiple payment methods, you need to understand what each one depends on and confirm whether it can actually serve as an alternative during an outage.

The outage drills discussed in a previous article can help here.

For example, how about imagining a scenario in which an external payment service suddenly becomes unavailable?

Where will you obtain outage information? Who will tell users what? Is switching to an alternative possible? If no recovery notice comes from the external business, how will you keep responding?

By confirming these points through drills, you should be able to reduce moments of hesitation when an actual outage occurs.

Even if you cannot restore the external service yourself, you can prepare to minimize the impact of its failure.

Conclusion: Turning Invisible Dependencies into Visible Preparedness

Even when your own servers and network are working normally, a failure in an external service you depend on can affect users. And the more complex your relationships with external services become, the longer it takes to identify the cause and scope of impact.

That is why it is important to understand your dependencies on external services on an ongoing basis, and to prepare communication structures, explanations for users, and alternatives in advance.

The ITIL practices of relationship management, supplier management, incident management, and service continuity management offer a useful reference for organizing these preparations.

Rather than thinking “our systems are fine, so we’re okay,” ask “what will we do if an external service we use stops?”

Aren’t there dependencies on external services in the services you are responsible for that you rarely think about?

Which external services, if they stopped, would affect your operations and users? At that point, whom would you contact, and what would you tell users?

It is worth checking once, before an outage leaves you in a cold sweat.

Note: Descriptions of the outage timeline and cause in this article are based on published materials from each company and on media reports. Visa’s Japanese subsidiary has explained that a program change to Cybersource caused the outage, but the technical relationship between this and the events published by the various companies involved has not been fully confirmed. The analysis using ITIL practices reflects the author’s views and does not represent the official position of ITIL or of the businesses mentioned in this article.

References

ITmedia Mobile (July 17, 2026) “Visa Japan reveals the root cause of the ‘credit card outage’: ‘Not caused by an external attack or similar’” (in Japanese)
https://www.itmedia.co.jp/mobile/spv/2607/17/news103.html

ITmedia NEWS (July 16, 2026) “Morning credit card outage appears resolved; trouble in ‘international brand network’ [Updated]” (in Japanese)
https://www.itmedia.co.jp/news/articles/2607/16/news071.html

ITmedia Mobile (July 16, 2026) “Sumitomo Mitsui Card reveals cause of ‘credit card outage’; Tokyo stores ask customers to ‘please use cash or transit IC cards’” (in Japanese)
https://www.itmedia.co.jp/mobile/amp/2607/16/news102.html

Nikkei (July 16, 2026) “Credit cards temporarily unusable; possible communication failure at international brand” (in Japanese)
https://www.nikkei.com/article/DGXZQOUD162GI0W6A710C2000000/

piyolog (July 17, 2026, updated thereafter) “A summary of the nationwide credit card payment outage in July 2026” (in Japanese)
https://piyolog.hatenadiary.jp/entry/2026/07/17/065349

Cybersource (July 2026) “Authorizations and Decision Manager Service Disruption”
https://status.cybersource.com/incidents/ry0rqlcp824c

PeopleCert “ITIL 4 Practitioner: Relationship Management”
https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-relationship-management-3865

PeopleCert “ITIL 4 Practitioner: Supplier Management”
https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-supplier-management-3869