Automate failed subscription payment follow-up on Shopify, decline by decline
Updated · By Ecomsellertool editorial team
To automate failed subscription payments on Shopify, start from Shopify Flow's Subscription billing attempt failure trigger or the subscription_billing_attempts/failure webhook. Read the decline code, then apply a rule for it: retry later for insufficient funds, send a card update link for an expired card, ask the customer to confirm a bank challenge, and stop for suspected fraud. Pause rather than cancel, and route exceptions to a person.
- The Shopify Subscriptions app sets one retry count and one interval for payment failures, then skips, pauses or cancels when all retries fail, notifying the customer (checked October 13, 2026).
- Shopify Flow has Subscription billing attempt failure, success and challenged triggers, plus Subscription contract created and updated triggers.
- Shopify's payment error list for billing attempts has 46 codes, from INSUFFICIENT_FUNDS and EXPIRED_CARD to FRAUD_SUSPECTED and AUTHENTICATION_REQUIRED.
- Shopify tells subscription apps to retry only errors that make sense to retry, and not to charge the same payment method more than 30 times in 35 days.
- Payment method update links from the Shopify admin expire 48 hours after they are sent.
The step map: who runs each step
Trigger: A subscription renewal charge fails, which fires Shopify Flow's Subscription billing attempt failure trigger and the subscription_billing_attempts/failure webhook (or the challenged trigger when the bank asks the customer to confirm).
| Step | What happens | Who runs it |
|---|---|---|
| 1 | When a renewal fails, rules read the error code, contract, customer and order value, and sort the failure into a decline group: funds, temporary, new card, contact the bank, confirmation needed, fraud, store setup or inventory. | Rule |
| 2 | Rules set the next retry for that group, or no retry, and keep a count per payment method so retries stay well inside Shopify's limit of 30 charges in 35 days. | Rule |
| 3 | Rules send the message that matches the group: a card update link for an expired card, a 'contact your bank' note for an issuer decline, a confirm-payment reminder for a bank challenge, and nothing yet for a temporary processor error. | Rule |
| 4 | When the last retry fails, rules apply the contract action set for that group, normally pause instead of cancel, and tag the customer so marketing and support can see it. | Rule |
| 5 | An AI model drafts a reply when a customer answers the dunning email, using only the contract and billing facts. It never changes the contract, issues a refund or promises a date. | AI model |
| 6 | A person handles the exceptions: suspected fraud, store-side setup errors, high-value subscribers after the final attempt, and any customer who disputes a charge. | Person |
| 7 | A daily report lists failed renewals by decline group, revenue still in retry, contracts paused or failed this week, and renewals recovered after a card update. | Rule |
5 rule steps · 1 AI model step · 1 person step. A rule follows fixed logic you approve; an AI model handles messy input and its output is checked by rules; a person makes the calls listed below.
What stays with a person
- Any FRAUD_SUSPECTED decline, before anyone contacts the customer or bills again
- Store-side errors such as an unsupported payment method, currency or merchant rule, which need a settings fix, not a customer email
- Cancelling a contract, since a cancelled contract cannot be resumed and the customer has to order again
- High-value or long-tenure subscribers whose final retry failed
- Customer replies that dispute a charge or ask for a refund
Which tools can run it
- The Shopify Subscriptions app's own retry settings and notifications, for a small subscription base with one rule for every failure
- Shopify Flow's subscription billing triggers with tags, Slack alerts and a Send HTTP request step to your email or SMS tool
- Zapier, Make or n8n on the subscription webhooks, for per-reason messages and a daily report without custom code
- Custom code on your accounts, for a subscription app built on Shopify's APIs where your code schedules every retry and contract change
Systems it connects
- Shopify Subscriptions or another subscription app
- Shopify Flow
- Shopify customers and payment methods
- Email and SMS tools
- Helpdesk
- Slack or email for the exceptions queue
Build size: Medium
Shopify exposes the decline code and the events; the work is the per-reason rules, the messages and who may change the contract.
A failed renewal is revenue that already said yes. The customer chose the subscription, and then a card expired, a bank declined, or a payment needed one more tap from the customer. Most subscription brands on Shopify handle these by hand: someone scans the failed list, emails a few customers and forgets the rest until the contract runs out of retries. This recipe reads the reason for every failure, sets the retry and the message that fit that reason, and leaves a person only the cases that need judgment. It is one page of our automation library.
Which rule fits each failed payment reason?
Start from the decline code, because the right next step changes with it. When a renewal fails, the billing attempt carries a code from Shopify's list of payment error codes for subscription billing attempts, 46 values in all (checked October 13, 2026). The table groups the common ones. The retry timings are our suggested starting rules, not Shopify defaults: tune them to your own recovery data. The contract statuses come from Shopify's subscription contract status list: active, paused, cancelled, expired and failed.
| Decline group (example codes) | Retry rule | Customer message and channel | What changes on the contract | When a person steps in |
|---|---|---|---|---|
| Funds: INSUFFICIENT_FUNDS, TRANSACTION_LIMIT_EXCEEDED | Retry after 3 days, then after 5 more; no more than 3 retries on the same card | Email right after the failure: "we will try again on [date]; nothing to do unless you want to use another card," with an update link | Stays active; pause after the last retry | Only for high-value subscribers after the last retry |
| Temporary: TRANSIENT_ERROR, PROCESSING_ERROR, PAYMENT_PROVIDER_ERROR, GENERIC_ERROR | Retry the next day | None yet; the funds message if the retry also fails | Stays active | When the same code hits many contracts in one hour: likely a gateway problem, so ops checks before more retries |
| New card needed: EXPIRED_CARD, EXPIRED_PAYMENT_METHOD, INVALID_NUMBER, INCORRECT_NUMBER, INVALID_EXPIRY_DATE, INVALID_PAYMENT_METHOD | No retry on the same card; retry once when the card is updated | Email at once with a card update link; resend after 2 days, since links expire in 48 hours; SMS if the customer opted in | Stays active during a 7-day grace period, then paused | When the customer replies with a question |
| Contact the bank: DO_NOT_HONOR, CALL_ISSUER, CARD_DECLINED, PAYMENT_METHOD_DECLINED, RETRY_DECLINED | One retry after 4 days at most | Email: "your bank declined the charge; contact them or use another card," with the update link | Paused after the single retry fails | Only if the customer asks for help |
| Confirmation needed: AUTHENTICATION_REQUIRED, OFF_SESSION_REJECTED, EXPIRED_BUYER_ACTION, or a challenged attempt | No automatic retry; the customer must complete the bank's check | Reminder email and SMS that the bank needs them to confirm the payment; a second reminder after 2 days | Stays active while the confirmation is open; paused after 5 days | When the check is still open after 5 days, support contacts the customer |
| Fraud: FRAUD_SUSPECTED | Never retry | None automated | Paused at once | Always, before anyone contacts the customer or bills again |
| Wrong details: INCORRECT_ZIP, INCORRECT_ADDRESS, INCORRECT_CVC, INVALID_SHIPPING_ADDRESS | No retry until the details change | Email asking the customer to check their billing or shipping details, with the update link | Stays active for 7 days, then paused | When a shipping address is missing for a physical box |
| Store setup: PAYMENT_METHOD_UNSUPPORTED, INVALID_CURRENCY, MERCHANT_RULE, TEST_MODE | No retry until the setting is fixed | None: the customer did nothing wrong | Stays active; billing resumes after the fix | Always, right away: ops fixes the gateway or rule |
| Already paid: INVOICE_ALREADY_PAID | Stop | None | No change | A person checks for a double charge before anything else happens |
| Inventory (INSUFFICIENT_INVENTORY, a billing error rather than a payment error) | Follow the app's separate Not enough inventory retry setting | Email offering a swap or a skip, not a card update | Skip the cycle if stock does not return in time | The buyer or inventory planner decides the swap |
Two Shopify notes shape the table. Shopify's subscription contract guide says it is up to apps to re-bill failed attempts, to retry only errors that make sense to retry, such as insufficient funds, and not to re-bill the same payment method more than 30 times in 35 days; beyond that the request fails and the payment method is revoked (checked October 13, 2026). And Shopify's changelog of February 4, 2026 added finer codes such as DO_NOT_HONOR and CALL_ISSUER in API version 2026-04, while 2026-01 and earlier return the older mapped codes. Build the rules against the version your app calls.
What does the subscription app's dunning already do, and what does custom automation add?
The Shopify Subscriptions app already retries. Its app settings page says that under Billing attempts you set the number of retry attempts and the days between them, separately for payment method failure and for not enough inventory, and choose to skip, pause or cancel the subscription when all retries fail, with a notification to the customer in each case (checked October 13, 2026). Customer email notifications are on by default and are switched on or off under Settings, then Notifications. That is a sound floor. Its limit is that one rule covers every payment failure.
| Job | What the Shopify Subscriptions app does (per Shopify's help center) | What custom automation adds |
|---|---|---|
| Retry timing | One retry count and one interval for all payment failures | Timing per decline group; no retries for codes that cannot succeed |
| After the last retry | Skip, pause or cancel, one choice for every failure | A choice per group and per customer value, with cancellation left to a person |
| Customer message | The app's notification emails, edited under Settings, then Notifications | A message that names the fix (new card, call the bank, confirm the payment), sent by email, SMS or the helpdesk |
| Card update | A Send link to update card button on the contract; customers can manage payment methods in their account | The link sent the moment a hard decline arrives, and resent before the 48-hour expiry |
| Finding the problem | Contracts filtered by status or inventory error; customers filtered by Failed payment | A daily queue of failed renewals by reason and value, and an alert when one code spikes across many contracts |
| Events | Flow triggers for billing attempts and contracts | Routing those events to your email, SMS, helpdesk and reporting tools |
The card-update details come from three Shopify pages. The contracts page describes the Send link to update card step and warns that a cancellation cannot be undone, so the customer would have to place a new subscription order. The customer subscriptions page adds the Failed payment filter and says update links expire 48 hours after they are sent. The customer experience page says customers get an email 3 days before each recurring charge and can manage their payment methods in their account (all checked October 13, 2026).
Some failures never happen. Shopify's eligibility considerations page says Shopify Payments works with major card networks to update saved card details automatically, widely supported in the United States, and that with other gateways customers might need to update their details by hand (checked October 13, 2026). On another gateway, the expired-card row of the table carries more of the load.
Which Shopify events can start the workflow?
Shopify Flow's trigger list has five subscription triggers: billing attempt challenged, failure and success, and subscription contract created and updated (checked October 13, 2026). The billing attempt failure trigger passes the failed billing attempt and its contract. The challenged trigger fires when an attempt is challenged, and the contract updated trigger passes the contract and the customer, which is how a rule sees a pause or a resume.
For code, the Admin API's webhook topic list includes subscription_billing_attempts/failure, success and challenged, the last described as the bank challenging the charge under 3D Secure, plus contract pause, cancel and fail topics and customer payment method create, update and revoke (checked October 13, 2026). One trap: Shopify's contract guide says the success and failure webhooks are not sent until a challenge is completed. If the customer never confirms, nothing arrives, so the confirmation row needs its own timer.
Who may change the contract depends on which app created it. Shopify's subscription contracts overview says apps charge customers by starting billing attempts on contracts they own, and the access scopes page lists the contract scopes as read_own and write_own subscription contracts, with Shopify approval required (checked October 13, 2026). Flow's Send Admin API request action says it does not support some app-specific subscription mutations. So with the Shopify Subscriptions app, automation reads the events and handles messages and routing, while the app's settings keep retries and contract changes.
With a subscription app built on Shopify's APIs, your code owns all of it. The subscriptionBillingAttemptCreate mutation starts each retry and needs the write_own_subscription_contracts scope plus a user with the manage orders information permission, and customerPaymentMethodSendUpdateEmail emails the customer a secure link to update a saved payment method, with the write_customers scope (checked October 13, 2026). Each billing attempt also carries an idempotency key, which Shopify describes as a unique key to avoid duplicate payments, so a resent request never charges twice. For inventory failures, the broader billing attempt error list includes INSUFFICIENT_INVENTORY.
What stays with a person?
The decisions that cost a customer or carry risk. A suspected-fraud decline goes to a person before any email, because a dunning message to a stolen card's owner causes more harm than the lost renewal. Store-side errors go to whoever owns the payment settings, since no customer email fixes an unsupported currency. Cancellation stays a human or customer choice: Shopify says it cannot be undone, and a paused contract keeps the door open. Customer replies to dunning emails land in your support-ticket triage flow, where an AI model drafts and a person sends.
Charge disputes are their own path. If a customer files a chargeback with the reason Subscription canceled, the evidence is the cancellation record and the dunning emails this workflow already logged; our chargeback evidence recipe shows how that pack is built and why a person submits it. For example, a brand renewing 2,000 subscriptions a month that sees 150 failures could have the rules handle the funds, temporary and new-card rows on their own, leaving a person perhaps a dozen fraud, setup and high-value cases. Those numbers are illustrative; your mix will differ.
Measure the process, not a promise. The daily report counts failed renewals by decline group, revenue still in retry, contracts paused this week, and renewals recovered after a card update or a confirmation. It can post next to your daily sales report in Slack. If one group recovers poorly, change that row's timing or message and watch the next month. For what Flow handles without code, see our guide to what Shopify Flow automates.
Who builds subscription dunning automation for Shopify brands?
Ecomsellertool builds workflow automation on your own Shopify store, subscription app, email and SMS tools. We have built software on Amazon's seller APIs since 2017 and shipped 50+ tools for 100+ teams. For failed renewals we map your decline codes and messages with you first, then build the triggers, the per-reason rules, the exception queue and the report. Send a project brief or read how our workflow automation service works.
The building blocks are work we have shipped:
- Shopify data in one operating layer. For Seller7 we built one workspace that brings Amazon, Walmart, Target Plus, Shopify, Mirakl and eBay orders into a single catalog, order and finance layer through each marketplace's own API, with alerts on one dashboard.
- Revenue reporting a team acts on. For Lavley we built sales analytics with goals set on units sold, gross revenue, net profit and net margin, broken down by brand, product and period.
The workflow can run on Ecomsellertool Growth OS beside your order, returns and dispute flows. More on how we work with Shopify stores is on our page for Shopify brands.
Get your failed-payment follow-up built
Send us your subscription app and your decline mix
Describe the workflow you want automated. We reply with a written plan: scope, timeline and a fixed price.
Frequently asked questions
How do I automate failed subscription payments on Shopify?
Start from Shopify Flow's Subscription billing attempt failure trigger or the subscription_billing_attempts/failure webhook. Read the billing attempt's error code, sort it into a decline group, and apply a rule per group: when to retry, which message to send and what happens to the contract after the last attempt. Keep fraud, store-side errors and cancellations with a person.
Does the Shopify Subscriptions app retry failed payments?
Yes. In the app's Settings, under Billing attempts, you set the number of retry attempts and the days between them for payment method failures, with a separate setting for not enough inventory. You also choose whether to skip, pause or cancel the subscription when all retries fail, and Shopify notifies the customer in each case.
Should I retry every declined subscription payment?
No. Shopify's developer guide tells subscription apps to rebill only errors that make sense to retry, such as insufficient funds, and not to charge the same payment method more than 30 times in 35 days. An expired card or an incorrect number will fail again until the customer updates it, so send a card update link instead.
Can Shopify Flow handle subscription dunning on its own?
Partly. Flow has triggers for a failed, successful or challenged billing attempt and for contracts created or updated, so it can tag customers, alert your team and call another tool. Shopify says its Send Admin API request action does not support some subscription mutations, so retries and contract changes usually stay with the subscription app.
Should a failed subscription be paused or cancelled?
Pause it in most cases. Shopify says a cancelled contract cannot be undone and the customer has to place a new subscription order, while a paused contract can be resumed once the card is fixed. Leave cancellation to a person, or to customers who ask for it.
How long does a Shopify card update link last?
Shopify says payment method update links sent from the admin expire 48 hours after they are sent. A follow-up rule should resend the link if the customer has not updated the card after two days, rather than send the same expired link again.
