Your payment processor changed its API and nobody told you: surviving gateway updates

A payment gateway rarely announces a breaking change to the person who actually needs to hear it. The notice goes to a developer mailing list, a changelog page, or an app partner's API dashboard, six months before the cutoff. Then the cutoff date arrives, the old API version stops accepting requests, and checkout starts failing for a slice of your customers who happen to route through that particular code path. Nobody on your team gets an email. You just notice, weeks later, that conversion looks a little soft and you can't say why.

Why the warning never reaches the store owner

Payment processors like Stripe, PayPal, Adyen, and the card networks themselves run on versioned APIs. Old versions get deprecated on a schedule, often a year or more out, so that software vendors have time to update their integrations. That part works reasonably well between processors and app developers.

The gap is the next link in the chain. Your store doesn't talk to the payment gateway directly, usually. It talks through a plugin, an app, or a theme's checkout extension, and that integration talks to the gateway. The deprecation notice goes to whoever built that integration. If they update it in time, you never notice anything happened. If they're slow, distracted, or the app is no longer actively maintained, the integration keeps calling an API version that's about to stop working, and you find out when the calls start failing.

This is structurally similar to other quiet-dependency failures stores run into, like the WooCommerce migrations that break plugin compatibility without warning (see HPOS, block checkout, and WordPress 7.1), or the way plugin conflicts surface only after an update ships. A payment gateway update is the same shape of problem with higher stakes, because the failure sits directly on top of revenue.

How a gateway deprecation actually presents

It rarely looks like a full outage. A gateway update usually breaks something narrower: a specific card network's tokenization format, a specific currency's rounding behavior, a webhook payload schema that changed shape. That means the failure often affects a subset of orders while the rest of checkout keeps working fine.

A common pattern: customers using saved payment methods or a particular wallet (Apple Pay, Google Pay, a regional method like iDEAL or Bancontact) start seeing declines or silent hangs at the confirm-payment step, while customers entering a fresh card number checkout normally. From the store owner's dashboard, this looks like normal daily variance in decline rates, not a system failure. Support tickets, if you get any, arrive as vague complaints (