Expiry-related payment errors
Codes covered: expired_payment_method · invalid_expiry_date · expired_buyer_action
What this error family means
A family of failures where time ran out on something: the stored payment method is past its expiry, the recorded expiry date itself is invalid, or a pending customer action (like a verification request) lapsed before the customer completed it.
Why it happens on subscription renewals
- expired_payment_method — like an expired card, but at the level of the vaulted record: whatever instrument the subscription bills (card, wallet-backed method) is past its valid window.
- invalid_expiry_date — the expiry stored for the card is malformed or impossible, usually a data-entry or migration artifact rather than a real card state.
- expired_buyer_action — the customer was asked to do something (verify, approve, update) with a deadline, and the window closed before they acted.
The merchant playbook
- None of these recover on retry — each needs either fresh payment details or a re-issued customer action, so route all three straight to the update/re-request path.
- For expired_payment_method, treat exactly like an expired card: immediate update request, and ideally a pre-expiry scan that catches it before the renewal date.
- For invalid_expiry_date, have the customer re-enter the card in full — correcting a corrupt stored date isn't something a merchant control fixes.
- For expired_buyer_action, simply re-trigger the original request and say so plainly ('the link expired, here's a fresh one') — the customer's intent was probably fine; the deadline wasn't.
Should you retry?
No for the whole family. Each member fails deterministically until the underlying record or request is refreshed; the playbook is re-request, not re-attempt.
Common questions
How is expired_payment_method different from expired_card?
Expired_card refers to the physical card's expiry; expired_payment_method is broader — the stored billing instrument (whatever its type) is out of date. Operationally both end in a customer update, so most stores can treat them as one bucket.
Can these be prevented?
The expiry-based ones largely can: stored methods expose their expiry in advance, so scanning upcoming expiries and requesting updates a month early avoids the failure entirely. Expired_buyer_action is prevented by shorter response chains — fewer steps between the ask and the action.
Related codes: expired_card · invalid_payment_method · authentication_required · or see the
full decline-code guide.
Where Moorly fits: Moorly reads the decline reason behind every failed renewal in your existing subscription app and applies the playbook above automatically — the right treatment per code, with a dollar figure on what each failure family costs your store. 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 s.r.o. Code names follow Shopify's public API documentation as of August 2026; bank behavior varies by issuer — always confirm against your own admin.