[BUG] Subscription billing attempts failing with PAYMENT_PROVIDER_IS_NOT_ENABLED on shops with Shopify Payments active

Hi —

We’re seeing intermittent billing attempt failures with the PAYMENT_PROVIDER_IS_NOT_ENABLED error code on subscriptions whose payment methods were just created in Shopify Payments on shops where Shopify
Payments is clearly activated. In some cases the error persists across retries; in others, the very next billing attempt on the same subscription succeeds without anything changing on our end or (as far as we
can tell) on the shop’s end.

We started seeing this in early April 2026.

Some facts:

  • The affected subscriptions were created with payment methods on Shopify Payments, not a legacy gateway
  • Shopify Payments is activated on the shops where this is happening
  • Nothing about the subscription, payment method, or shop gateway config changes between a failing billing attempt and a subsequent succeeding one
  • The behavior is inconsistent — same shop, same subscription shape, sometimes fails and sometimes doesn’t
  • In some cases the PAYMENT_PROVIDER_IS_NOT_ENABLED error persists across multiple retries; in others it clears on its own

Sample billing attempt

  • (failed) gid://shopify/SubscriptionBillingAttempt/224420790517
  • (succeeded same sub - no changes) gid://shopify/SubscriptionBillingAttempt/224421282037

Because the error clears on its own in some cases and the shops’ Shopify Payments configuration is unchanged throughout, this looks to us like something on the platform side rather than a merchant configuration
issue — but we’d love a second set of eyes on that billing attempt to confirm.

Any guidance would be appreciated — this is causing billing failures for subscription merchants and seems to be escalating.

Thanks in advance!

Hey @Brian_Singer :waving_hand: We identified an issue in early April that caused intermittent PAYMENT_PROVIDER_IS_NOT_ENABLED failures on subscription billing attempts for shops with Shopify Payments active. It affected multiple subscription apps and we identified and mitigated the underlying cause.

Billing attempts that failed during this window should succeed on retry, since no data was corrupted and the payment method/gateway configuration was never actually invalid. If your app has retry logic, those should clear on the next pass. For any billing attempts that exhausted their retry limit during the incident window, a new billing attempt on the same contract should go through.

If you’re still seeing new failures after roughly April 8, that would point to something else and I’d want to dig in further. In that case, can you share the affected x-request-id headers and a few of the more recent failing billing attempt GIDs so I can investigate on our end?

1 Like

Thanks for the quick response @Donal-Shopify - April 10th is the last one that I have an example of at the moment (its the one referenced in the post) bit I’m fairly confident that we’ve seen it in the last few days as well

Unfortunately I don’t have the x-request-ids (we aren’t storing those so can only grab them when we try running BAs manually)

April 10 is definitely past the window I was tracking, so going to take a closer look. If you can share any of the most recent failing billing attempt GIDs, I should be able to track down what’s happening on our side. Thanks Brian!

for now - just this one gid://shopify/SubscriptionBillingAttempt/224420790517

but I’ll see if I can get you more

1 Like

Thanks @Brian_Singer, got enough from that GID to tie it down. Attempt 224420790517 hit a known, now-mitigated issue in the subscription billing path.

The PAYMENT_PROVIDER_IS_NOT_ENABLED label is misleading here. Shopify Payments was active on the shop throughout. Our internal trace shows the billing layer intermittently failed to resolve the vaulted card during a payment method check, even though the card itself was valid (your 22:00 UTC retry on the same contract and card confirms that). The intermittency came from a recent change in how vaulted payment method identifiers were resolved during billing, and it only surfaced under specific timing conditions.

That change was rolled back at 2026-04-10 22:16 UTC, so the window this was active in is closed. If you see any attempts fail with this signature dated on or after 22:16 UTC on April 10, share the GIDs and I’ll take another look. The same error code is reused by a few other paths in the billing layer, so a recurrence would be worth investigating from scratch - hope this helps!

Very much. Thank you!

We’ll keep an eye out but we’re definitely seeing less over the last week or so.

Hi @Donal-Shopify,

We are also suffering the same issue, we have contacted paypal aswe were told by Shopify support and Paypal have now referred us back to Shopify and highlighted this post.

Are you able to assist.

Thanks

James

Hey @James_Harkess, the issue in this thread was specific to Shopify Payments. A change in the subscription billing path was rolled back on April 10 at 22:16 UTC, and that’s what cleared the failures Brian was seeing.

If your failures involve PayPal as the subscription payment method, that’s a different code path and the root cause wouldn’t be covered by this issue. To look into your specific case I’d need the failing billing attempt GIDs and a shop domain. If you’re using a third-party subscription app, those GIDs will be in their dashboard or support tooling, so you may need to get them to pull the specifics. X-request-ids are also useful if you can capture them when triggering attempts manually.

@Donal-Shopify We are encountering this issue on our store as well as of 4/24/26. 156 paypal transactions had this same error code on SKIO side. I believe the bug still exists. This is the first time we have seen this error code.

Thanks for the extra reports, both of you. To set expectations, the issue resolved earlier in this thread was specific to the Shopify Payments billing path. PayPal goes through a different code path, so even though the error code is the same, what you’re seeing isn’t covered by that fix and needs to be looked at on its own.

To dig into either case, I’ll need a few things in the thread:

  1. 2-3 failing SubscriptionBillingAttempt GIDs from the recent batches

  2. An x-request-id from a failure if you can capture one (running a billing attempt manually is usually the easiest way)

If you’re going through SKIO or another subscription app, those GIDs will be in their dashboard or available from their support team. Once I have them I can trace the failures on our side and confirm what’s actually going wrong.