Recurring payments: card update for active subscription + Visa Account Updater / Mastercard ABU support

[geosme]

We're integrating Smart Checkout recurring payments (stored-token,
merchant-initiated charges via viva-payments/charges/{transactionId})
for a SaaS subscription product. Two questions where the documentation
and recent dev-support responses don't give a definitive answer in 2026.

1. Visa Account Updater / Mastercard Automatic Billing Updater

When a customer's card is reissued (expiry, replacement after loss/theft,
upgrade from debit to credit, etc.), does Viva.com participate in the card
networks' updater services (Visa Account Updater / Mastercard ABU) so that
the stored transaction ID continues to work against the refreshed card
details — i.e. silent renewal without customer interaction?

• If yes: is it on by default, or does it require enablement / fee?
• If no: is it on the roadmap?

Reason: Stripe, Adyen, Mollie and other major processors expose VAU/ABU
to merchants. Without it, every card reissue produces a hard decline
that requires a full re-checkout flow — significant churn.

2. Customer-initiated card update for an existing recurring subscription

Issue #2508 (Feb 2024) was answered: "this functionality is not
supported. For the customer to change the card, you should repeat the
entire process as it is a new subscription."

Is this still the case in 2026? If so, the documented best practice
question is what to do with the OLD transaction ID once the customer
completes a new Smart Checkout with allowRecurring: true:

• Do we cancel/void the old transaction ID? (Is there an endpoint for that?)
• Or do we just stop using it and let it remain in our DB?
• Is there any merchant-side guidance to avoid charging the old token by
  accident after the customer has updated?

Concretely: if a customer has an active monthly subscription on token T1
and wants to update their card, the integration pattern we'd build is:

1. Customer clicks "Update card" in our portal
2. We redirect to a new Smart Checkout with allowRecurring: true and
   amount = 0 (or some minimal auth amount?)
3. We get token T2 back on the 1796 webhook
4. We mark T1 as superseded and start charging T2 from next cycle

Is this the correct pattern? Specifically:

• Can amount = 0 create an allowRecurring token, or is a minimum
  amount required?
• Is there a recommended way to do a "zero-amount card-on-file
  authorization" that just captures a recurring-eligible token without
  charging?

3. Webhook for card update completion

Issue #2508 also asked about a webhook firing after card update.
Has anything changed here? If not, we'll continue to drive state
transitions off the 1796 event for the new token.

---

Context: Greek SaaS, subscription model with monthly + annual products
per customer, EU PSD2 compliance required, currently routing new
customers to Viva by default after a successful sandbox + production
integration of Smart Checkout.
Production merchant profile, single Website ID.

Thanks 🙏