How to recover failed payments in Zuora

Zuora gives you a lot of control over payment collection, which also means a lot of settings to get right. Failed payments in Zuora touch at least four areas: payment runs, retry rules, notifications, and the way customers update their payment method. This guide walks through each one and ends with a practical setup plan.

It sticks to Zuora’s own documentation: Payment runs, Configure payment retry rules, Payment Retry, Configurable Payment Retry, Payment attempts and retry rules, Standard events for Zuora Payments and How do I allow customers to modify their stored payment methods? (all accessed November 2026). Field names can vary with your tenant’s version, so check them in your own settings.

Step 1: understand payment runs

In Zuora, automatic collection happens through payment runs. A payment run collects open invoices using electronic payment methods such as cards or ACH. According to the payment runs documentation:

• A run can process up to 200,000 invoices.
• There are ad hoc runs, which you start by hand, and recurring runs, which execute on a daily, weekly or monthly schedule.
• Runs only collect from accounts with auto-pay enabled. Auto-pay is set on each customer account, so an account without it will never be charged by a run, and its invoices will simply sit open.
• When an invoice is being processed by a payment, it is locked, and any other payment against it fails. Zuora recommends deciding which invoices are collected by which method (payment run, payment page, API) so they do not collide.

The first thing to check when “Zuora is not retrying” is often not retries at all: it is whether the account has auto-pay on and a default electronic payment method.

Step 2: choose your retry mechanism

Zuora has two ways to retry a failed electronic payment. Zuora advises against running both at the same time.

Tenant-level payment retry rules

The built-in rules, described in Configure payment retry rules, apply to failed payment processing by default when payment retry is enabled in your tenant. You set:

• the maximum number of consecutive times a failed payment method is retried;
• a minimum interval since the last failed attempt (for example, with 8 hours, no automated retry happens if the last failure was less than 8 hours ago);
• a time period during which payments are not retried.

You can override these per payment method. These rules are simple and predictable, but the same rules apply to every decline, whatever its reason.

Configurable Payment Retry (CPR)

Configurable Payment Retry is Zuora’s more flexible option. It lets you set retry logic per customer group and per gateway response code, mapping codes to categories such as hard, medium and soft declines. Key points from the docs:

Setting or behaviour	What Zuora documents
Retry window	Days from entering retry until the last attempt, maximum 90 days
Number of attempts	Maximum 20; the payment run makes the first attempt, CPR makes the rest
Smart Retry	An optional machine learning model that picks retry times from subscriber and transaction characteristics
Hard declines	A Stop Retry On Hard Declines option ends the cycle on a hard decline
Timing	Attempts run in batches on the hour, so retries cannot be more frequent than hourly
Payment methods	Card payments only, not direct debit such as ACH or SEPA
Rule changes	Apply to future attempts only; concluded cycles are not restarted

Two behaviours from the CPR best practices are easy to miss:

• CPR turns auto-pay off while a retry cycle runs, so the regular payment run does not charge the invoice again. According to the auto-pay settings page, what changes depends on the retry level: at invoice level only the invoice’s auto-pay flag is turned off; at account level the account’s auto-pay is turned off and turned back on only once payment is collected. Zuora recommends invoice-level retry, which keeps the account eligible for future payment runs. An older best-practices page describes both flags being set to false, so check which level your tenant uses.
• To stop retries immediately (for example, the customer paid by bank transfer), you end the retry cycle manually, which you can do through the CPR APIs.

If you are unsure how to classify a response code, Zuora suggests mapping it as a soft decline and monitoring the results. Zuora also documents a way to test Smart Retry against your existing logic before switching everything over.

Step 3: tell the customer, with notifications and callouts

Retries recover temporary declines. Expired, replaced or blocked cards need the customer. Zuora’s standard events for payments give you the hooks:

• Payment Declined: fires when the gateway declines an electronic payment. A “Sequence of failed attempt” setting controls on which consecutive failure the notification fires; it is compared with the payment method’s NumConsecutiveFailures and defaults to 1. External payments do not trigger these notifications.
• Card expiration warnings: events 15 and 30 days before the default card expires (the expiration date is the last day of the expiry month). These let you ask for a new card before anything fails.
• Payment Method Updated: fires when the default payment method changes, which is your signal to stop reminders.

Each notification can be delivered as an email or as a callout, an HTTP request to your endpoint, configured in the notification definition. Use callouts to update your own app (banner, access) and to trigger any messaging you run outside Zuora. Zuora Workflow can also react to these events and send templated emails or call external APIs if you prefer to keep the logic inside Zuora.

A simple notification plan:

Trigger	Message	Channel
Card expires in 30 days	“Your card expires soon, update it here”	Email
First declined payment	“Your payment did not go through”, with the update link	Email and in-app
Third consecutive failure	Reminder with the date access is affected	Email
Payment method updated	Confirmation, no further reminders	Email

Step 4: let the customer update their payment method

The update link in those emails needs somewhere to land. Zuora documents three ways to change a stored payment method in its guide on modifying stored payment methods:

1. The hosted payment method page for credit cards, passing the existing payment method ID (pmId) so the customer can update card information. This is the route that keeps card data off your servers; Zuora recommends Payment Pages 2.0 over handling card details through the API.
2. The Update a payment method REST operation. Zuora’s API reference strongly recommends Payment Pages 2.0 instead of calling it directly, and sending a card number through it puts your own systems in PCI scope.
3. The Zuora UI, in the Electronic Payment Methods section of the customer account, for support agents.

After a new default payment method is saved, make sure the open invoice is actually collected, either by the next payment run (check auto-pay, which CPR may have switched off) or by an immediate payment. Remember the invoice lock: do not let a payment page and a payment run charge the same invoice at the same time.

A recovery checklist for Zuora

1. Audit auto-pay on every active subscription account and confirm a default electronic payment method exists.
2. Pick one retry mechanism: tenant rules for simplicity, CPR for decline-aware logic and customer groups. Not both.
3. Map response codes in CPR and turn on Stop Retry On Hard Declines, so a stolen card is not retried for weeks.
4. Keep the retry window shorter than the billing period for monthly plans.
5. Turn on card expiration warnings at 30 and 15 days, and look at Payment Method Updater, which asks the Visa, Mastercard and American Express updater services for new card details before the bill cycle day on supported gateways.
6. Set up the Payment Declined notification with a link to a hosted payment page, plus a callout to your app.
7. Collect after an update: confirm the invoice is charged once a new card is saved.
8. Review declines monthly by response code and customer group.

Doing this with NoChurn

Zuora stays in charge of invoicing, payment runs, retries and your gateway. NoChurn connects through a Zuora OAuth client, imports accounts and subscriptions, receives Zuora notifications and adds AI-written recovery emails that you review before they go out, with a link to update the payment method. It also adds cancel flows with reasons, offers (a discount or a plan change on the Zuora subscription) and a one-click cancel that is always visible, win-back emails at day 30, 60 and 90 based on the cancel reason, and a churn score from 0 to 100. Disputes come from the gateway behind Zuora; with Stripe or Braintree, NoChurn gathers the evidence and drafts a reply for you to review. See NoChurn + Zuora.