Store-configuration errors
Codes covered: merchant_account_error · payment_provider_is_not_enabled · merchant_rule · test_mode · non_test_order_limit_reached · payment_method_incompatible_with_gateway_config · invalid_currency · purchase_type_not_supported
What this error family means
Failures where nothing is wrong with the customer at all — the store's own payment setup blocked the charge. A disabled provider, a merchant-defined rule, a gateway in the wrong mode, or a currency or purchase type the configured gateway can't process.
Why it happens on subscription renewals
- payment_provider_is_not_enabled — the payment provider is off or unavailable on the store account (deactivated, under review, or restricted), so every renewal fails identically while it lasts.
- merchant_account_error / payment_method_incompatible_with_gateway_config / test_mode — the gateway configuration itself is broken or in a mode that can't charge real payment methods.
- merchant_rule — a rule the store itself set (risk threshold, restriction) declined the charge.
- invalid_currency / purchase_type_not_supported — the charge asks the configured gateway for something it doesn't support.
The merchant playbook
- Recognize the signature: many renewals failing at once, same code, regardless of customer — that pattern means look at your own payment settings, not at cards.
- Freeze customer-facing dunning while the condition lasts. Retries burn counters and card-update emails train customers to ignore you — neither can succeed until the configuration is fixed.
- Watch the auto-cancel danger: if the app cancels subscriptions after N failures, a store-side outage can permanently cancel healthy subscribers. Extend or pause the retry window first, fix the config second.
- After fixing, reconcile every renewal that was due during the window — some pick up automatically on the next cycle, some sit failed until manually retried.
Should you retry?
Retry only after the configuration is fixed — then yes, sweep the affected renewals. Before the fix, no attempt can succeed and every attempt does collateral damage.
Common questions
How do I tell a configuration failure from a wave of customer declines?
Correlation. Customer declines scatter across reasons and days; configuration failures hit every renewal in the window with the same code. If your failure list suddenly turns uniform, it's you, not them.
Should customers be notified during a store-side payment outage?
Not with payment-failure emails — their cards are fine. If the outage runs long enough to delay service, a plain service notice ('billing was briefly delayed on our side, nothing is needed from you') preserves trust; a card-update ask damages it.
Related codes: generic_error · transient_error · do_not_honor · amount_too_small · or see the
full decline-code guide.
Where Moorly fits: Moorly reads the raw decline reason your subscription app records for each failed renewal, keeps it attached to the case instead of collapsing it to “payment failed”, and sorts failures into families, so the total you lost is broken out by the kind of failure behind it. Codes it has not yet classified are handled conservatively rather than guessed at. It starts read-only. Join the early-access list →
Moorly is an independent product by Velun Labs and is not affiliated with Shopify, Appstle Inc., or Seal Subscriptions. Code names follow Shopify's public API documentation as of August 2026; bank behavior varies by issuer — always confirm against your own admin.