FAILED PAYMENTSZUORA

How to handle expiring cards in Zuora

How to stop expired cards from failing Zuora renewals: Payment Method Updater, real-time updaters, 15 and 30 day expiration events, and hosted card update pages.

Published 5 min read

Expired cards are the most predictable failed payments there are. You know the expiry date months in advance, yet many renewals still fail on cards that ran out last month. Zuora gives you two complementary tools against this: an automatic updater that fetches new card details from the card networks, and expiration events that let you ask the customer before anything fails.

This guide explains both, then gives you a setup you can apply. It sticks to Zuora’s own documentation: Payment Method Updater, the Payment Method Updater overview, Set up Chase Payment Method Updater, Support for Real Time Account Updater (Adyen), Standard events for Zuora Payments and How do I allow customers to modify their stored payment methods? (all accessed November 2026). For the general background on updaters and network tokens, see network tokens and card account updaters.

Why expired cards still fail

Banks replace cards for many reasons: expiry, loss, fraud, a new card design. The customer gets a new card and updates the places they remember; subscriptions they set up long ago are not on the list. When the renewal runs on the old card, it declines. If nobody intervenes, a customer who never meant to leave churns.

There are two ways to fix this:

  1. Get the new details from the network, without involving the customer. This is what account updater services do.
  2. Ask the customer to update their card, ideally before the old one expires.

You want both, because updaters only cover participating issuers and some card types.

Payment Method Updater (batch)

Zuora’s Payment Method Updater (PMU) sends card details in batches to the card networks’ updater services and writes the results back to Zuora. According to the PMU documentation and its overview:

  • It covers Visa, Mastercard and American Express, through the Visa Account Updater, Mastercard Automatic Billing Updater and American Express Card Refresher services.
  • It runs before each bill cycle day, so updated details are in place when the payment run charges the card.
  • Results can include a new card number (Zuora saves it as a new default payment method), a new expiration date, or a closed account flag. Cards marked closed are no longer used to process payments.
  • The service typically takes 2 to 5 days, because each network’s updater runs on its own schedule.

Gateway support

PMU is configured per gateway type. Zuora’s docs list PMU support for gateways including Adyen, BlueSnap, Chase, Checkout.com, CyberSource, First Data, Merchant e-Solutions, Vantiv and Worldpay, and list Global Payments as not supported. Some updaters (CyberSource, and Zuora’s American Express updater) work without a separate payment-processing contract with that gateway; the others require that you also process payments through it. One updater covers all payment methods of a gateway type; updating specific gateway instances is not supported.

Timing the batch

You configure how many days before the bill cycle day the service starts. The right lead time depends on the gateway: for Chase, Zuora recommends 10 days, under Settings, Payments, Set Up Payment Method Updater (Chase setup). Starting too late means the update arrives after the payment run has already declined.

When cards cannot be submitted

Zuora’s troubleshooting guide notes that invalid card data shows with a Warning status and a NotApprovedForSubmitted update type, which you can export from Reporting, Data Sources. Those cards will never be updated automatically, so they go straight to customer outreach.

Real-time updaters

Some gateways update card details at the moment of payment instead of in a batch. Zuora documents real-time account updater support for Adyen (Adyen RTAU), limited to Visa and Mastercard cards issued in the US and Canada, and a separate page for a Stripe real-time account updater. Check the conditions on those pages for your account before relying on them.

Expiration events: ask before it fails

Zuora’s standard events for payments include two expiration warnings tied to the Payment Method Expiration event:

Event When it fires
30 Day Warning The account’s default payment method expires within 30 days
15 Day Warning The account’s default payment method expires within 15 days

Details from Zuora’s docs:

  • A card’s expiration date is the last day of its expiry month.
  • A scheduled job evaluates these events daily (at 5:15 am UTC for EU and US Cloud Data Center 1 tenants, 5:15 am Los Angeles time for US Cloud Data Center 2).
  • The warnings still go out for a closed payment method; Zuora advises not leaving a closed method as the account default.
  • They only concern the default payment method.

Each warning can be delivered by email or as a callout to your system. Because PMU may refresh the card in the meantime, have your email or callout handler re-check the expiry on the account before sending anything to the customer.

Giving the customer a way to update

When the updater cannot help, the customer has to enter a new card. Zuora’s guide on modifying stored payment methods describes the options:

  • The hosted payment page (Payment Pages 2.0), loaded with the existing payment method ID (pmId) so the customer can update card information. This keeps card data off your servers.
  • The Update a payment method API, which Zuora recommends against for card data in favour of Payment Pages 2.0.
  • The Zuora UI, for support agents.

Link your expiration emails straight to a page that loads the hosted payment form for that account. After the new card is saved as the default, the next payment run uses it.

A setup plan

  1. Enable PMU for each gateway type you use, with a lead time that fits the gateway (10 days for Chase, per Zuora).
  2. Check real-time updater options if you process through Adyen or Stripe.
  3. Turn on the 30 and 15 day warnings with a callout to your system.
  4. Re-check before sending. If PMU already updated the card, skip the email.
  5. Send the 30-day email with a link to the hosted payment page. Keep it short: which card, when it expires, one button.
  6. Send the 15-day reminder only if the card is still unchanged.
  7. Export NotApprovedForSubmitted cards monthly and contact those customers directly.
  8. Keep a failed-payment fallback. Some cards will still fail; see how to recover failed payments in Zuora.

Doing this with NoChurn

Zuora’s Payment Method Updater, expiration events and payment runs stay in Zuora. NoChurn reads the payment method type and expiry from Zuora and adds AI-written emails that you review before they go out, with a link for the customer to update the payment method, plus recovery emails when a renewal still fails. Each customer also gets a churn score from 0 to 100. See NoChurn + Zuora.

PROMPT

Read https://www.nochurn.sh/llms.txt,
then follow https://www.nochurn.sh/docs/quickstart/
to add NoChurn to this app. Use a test key
(nc_test_…) until I say we go live.

Stop leaking revenue.

  • Free until $300 MRR
  • No card needed
  • Live in 10 minutes
  • Never a cut of what we recover