Overview
Digital Wallet Recurring lets merchants use Apple Pay and Google Pay for subscriptions and stored payment methods, not just one-off purchases. Use this article when helping merchants enable wallet-based recurring billing or set expectations around how it works.
For technical integration details, refer to NMI's developer documentation linked in the Getting Started section below.
What Is Digital Wallet Recurring?
Digital Wallet Recurring allows Apple Pay and Google Pay credentials to be stored and reused for repeat billing, similar to a saved card. It supports:
- Subscriptions through the NMI Recurring service
- Stored payment methods in the Customer Vault
- Merchant-initiated card-on-file (CoF) payments through the Payment API
Why It Matters for Partners
Digital Wallet Recurring is increasingly requested by merchants offering subscriptions, memberships, and repeat billing. Partners should understand the following:
- Merchants must already accept Apple Pay or Google Pay for one-off transactions before recurring will work.
- Both the product and processor must support the feature.
- Setup triggers a live transaction immediately, unlike card-based recurring, which waits for the scheduled start date.
- Merchants must save the original Transaction ID. All follow-up charges depend on it.
Prerequisites and Access Requirements
Before a merchant can use Digital Wallet Recurring, the following must be in place:
- Apple Pay or Google Pay enabled for one-off transactions
- Apple Pay domain and certificate setup complete (Apple Pay only)
- Merchant on a supported processor
- Integration through the Transaction API or Collect.js
Tip: Confirm a one-off wallet transaction works before attempting recurring. This rules out most configuration issues up front.
How It Works
Supported Products
| Product | Supported |
|---|---|
| Payment API | ✅ Yes |
| Customer Vault | ✅ Yes |
| Recurring | ✅ Yes |
| Collect.js | ✅ Yes |
| Virtual Terminal | ❌ No |
| QuickClick | ❌ No |
| Collect Checkout | ❌ No |
Supported Processors
NMI Payments, TSYS – EMV, EPX, First Data Nashville, Vantiv / Worldpay , Global Payments East – EMV, Checkout.com Unified Payments, First Data Compass, Paymentech Tampa
Coming Soon: Paymentech Salem
Note: If a merchant's processor is not listed, the feature will not work, even if Apple Pay one-off does.
Differences from Card-Based Recurring
Wallet-based recurring behaves differently from card-based recurring:
| Aspect | Card-Based | Wallet-Based |
|---|---|---|
| Transaction at setup | Optional | Required |
| Cryptogram | Not used | Required at setup |
| First authorization | At first scheduled payment | At registration |
| Card-on-file reliability | Varies | More consistent |
A Live Transaction Fires at Setup
With card-based recurring, nothing happens until the first scheduled charge. With wallet-based recurring, a real transaction fires immediately when the vault entry or subscription is created.
- Apple Pay sends a sale for the amount in the wallet payload by default.
- Google Pay sends a $0 authorization by default.
This happens because wallet cryptograms expire quickly. Using them at setup confirms the credential is valid, sets up reliable card-on-file data, and surfaces issues immediately rather than weeks later.
The setup response includes a Transaction ID that the merchant must save and reference on all follow-up charges.
Integration Options
Merchants can integrate in one of three ways:
- Encrypted payload: Merchant sends the encrypted wallet bundle to NMI. NMI handles decryption.
- Decrypted values: Merchant decrypts the wallet payload and sends the card data plus cryptogram to NMI.
- Collect.js: Collect.js renders the wallet button and returns a token to the merchant. Collect.js automatically configures the token for recurring use.
Most merchants will use Collect.js or the encrypted payload option.
Getting Started
Digital Wallet Recurring is live on all processors listed above. To get a merchant started:
- Confirm the merchant accepts Apple Pay or Google Pay for one-off transactions.
- Verify the merchant's processor appears on the supported list.
- Direct the merchant's developer to NMI's technical documentation:
- Preparing Subscriptions using Digital Wallet Data
- Adding Digital Wallet Data to the Customer Vault
- Digital Wallet Setup (Collect.js)
Common Questions
Do merchants need to build a special request for recurring wallet payments? Yes. The wallet must know the payment is recurring so it generates the right kind of token. Collect.js handles this automatically when a recurring or vault flag is included.
Are there extra fees? No. The Recurring and Customer Vault cost the same for cards and wallets.
Can merchants use Virtual Terminal, QuickClick, or Collect Checkout? No. Only the Payment API and Collect.js support this feature.
Will it work on every processor? No. Refer to the supported processors list above.
What if the merchant loses the original Transaction ID? Follow-up charges cannot be linked. The customer must re-authorize through a new wallet transaction.
Does Google Pay work the same as Apple Pay? Mostly. The main difference at setup: Apple Pay sends a sale for the wallet payload amount, while Google Pay sends a $0 authorization.
Can a card-based subscription be converted to a wallet subscription? Not directly. The customer must re-authorize through their wallet, creating a new setup transaction.
Key Definitions
- Digital Wallet: Apple Pay or Google Pay.
- Cryptogram: A short-lived encrypted value generated by the wallet. It cannot be reused and expires quickly.
- Customer Vault: NMI's secure storage for payment credentials.
- Recurring: NMI's subscription engine that bills automatically on a schedule.
- Card-on-File (CoF): A stored payment credential used for future merchant-initiated transactions.
- Transaction ID: The unique ID returned at setup. All future charges must link back to it.
Need Help?
For additional support, please contact our Support team by Submitting a Ticket: https://support.nmi.com/hc/en-gb/requests/new.