WooCommerce high-risk payment gateways after a Stripe shutdown

WooCommerce is the easy platform to fix

If you are going to be terminated by a mainstream processor, it is better to be on WooCommerce than almost anywhere else. That sounds glib after a shutdown, but it is structurally true and it changes what your recovery looks like.

WooCommerce is a plugin running on hosting you control. It has no opinion about what you sell, no acceptable use policy of its own, and a documented API that any gateway can build against. When Stripe or WooPayments closes your account, you have lost a payment provider, not a store.

Compare that to a hosted platform where the payments layer is owned by the platform itself and switching means working around the product rather than reconfiguring it.

What actually broke

WooPayments is Stripe underneath. The branding is WooCommerce; the underwriting, the restricted business list and the risk decisions are Stripe’s. Merchants regularly discover this at the worst possible moment, having assumed that the WooCommerce-branded product was a separate relationship.

Which means: if your category is on Stripe’s restricted list, WooPayments was never a durable option. Moving to PayPal’s WooCommerce integration usually reruns the same experience a few months later, because PayPal maintains comparable category restrictions.

The route out is a gateway backed by an acquirer that underwrites your category deliberately, rather than one that will discover it during a periodic review.

The subscription trap

This is the part that costs merchants real money, and it is worth reading twice if you bill on renewal.

WooCommerce Subscriptions ties each subscription to the gateway that created it. Card tokens held by your old gateway are, in most cases, not portable to a new one — the tokens are the old provider’s asset, held under their PCI scope.

The practical consequence: on the day you switch, your existing subscribers stop renewing unless they re-enter their card details.

What to do about it:

• Ask about token migration before signing. Some gateways can receive a token export from specific providers. Most cannot. Establish which before you commit, not after.
• Plan a re-authorisation campaign. Email subscribers ahead of the switch, explain plainly why they need to re-enter a card, and make the link one click.
• Expect losses and budget for them. Some percentage will simply not re-authorise. A realistic assumption is better than an optimistic one.
• Do not run both gateways in parallel indefinitely. It is tempting, and it makes reconciliation and dispute handling steadily worse.

Test the boring paths

New gateway plugins are usually fine on the happy path and unreliable on the paths nobody tests. Before you go live on production, run all of these on staging:

1. Authorisation and capture, including a 3-D Secure challenge
2. A partial refund, then a second partial refund against the same order
3. A full refund on an order that was already partially refunded
4. A failed renewal, and whatever dunning you have configured
5. A dispute notification arriving and appearing where you expect it

Refunds and disputes are where poorly maintained extensions break. Finding out during your first chargeback, when the clock is running, is a bad way to find out.

After you switch

Watch authorisation rates for a week. A new gateway with untuned risk rules or badly configured 3-D Secure can quietly decline good customers, and a five point drop in approval rate is easy to mistake for a slow week.

Ask your provider for decline reason codes rather than a headline rate. The distinction between issuer declines, risk-rule declines and authentication failures tells you what to fix, and only one of those three is anything to do with your customers.