Wallet-paid subscriptions look like the unmovable part of a migration: there's no card number to export — or so it seems. This guide explains what a wallet plan actually is under the hood, what moves into Yuno, and how to cut over so the payment lifecycle continues untouched: same credential, same schedule, same customer experience.
The wallet is only involved once in a subscription's life: at the very first checkout, when your customer confirmed the payment in the Apple Pay or Google Pay sheet. At that moment the wallet handed your processor a tokenized card credential plus a one-time cryptogram, and that cryptogram was consumed by the first, customer-present charge.
Every renewal since has been something much more ordinary: a merchant-initiated charge (MIT) against that stored credential, running on regular card rails and flagged as part of a subscription series. No wallet sheet, no Face ID, no Google prompt. Apple and Google are not in the renewal loop at all.
| Wallet | What your processor actually stores | What that means for migration |
|---|---|---|
| Apple Pay | Always a DPAN — a device account number. A real, network-issued card number that stands in for the customer's card. | Exports and vaults like a card, because on the network it is a card. |
| Google Pay | Either a DPAN (tokenized, like Apple Pay) or an FPAN — the actual card number. | DPAN behaves like Apple Pay. FPAN is simply a normal card on file — nothing wallet-specific applies. |
The credential your renewals run on is issued by the card networks, not by your current processor. It is not proprietary to them, and it does not die when you leave. What must survive the move is (1) the credential itself and (2) the context that marks each renewal as the continuation of an existing series — the stored-credential flags and, ideally, the network transaction ID of the original authorization. Both are covered below.
Every migrated method comes back as old payment-method ID → Yuno vaulted_token. That table is what lets each of your subscription records point at its new credential. Store it durably before you re-arm a single plan.
Methods can only be enrolled against existing customers. Create them with your own merchant_customer_id so your records, the old processor's references, and Yuno's customer_id all line up.
This is a written request to the processor you're leaving (for example, Stripe). Be explicit about scope — the default export is often cards only. Ask for: wallet-tokenized methods (Apple Pay / Google Pay DPANs), network tokens if provisioned, payment-method IDs, and — if they can provide them — the network transaction IDs of each method's first charge.
The transfer runs directly between the processor and Yuno over SFTP with PGP encryption. You own the communication with your processor; Yuno coordinates the technical hand-off with them directly.
DPANs vault exactly like cards — on the network they are card numbers. Each imported method is returned mapped to its old payment-method ID as a vaulted_token, the reference you'll charge from now on.
Prefer an API-driven move, or need to cover methods that arrive after the file export? The same per-method enrollment call works for wallet-origin methods too — the wallet type is detected automatically from the provider's metadata. See Enroll Stripe tokens in Yuno for the exact request.
Option A — your scheduler. Keep billing logic in your own system and fire one merchant-initiated payment per renewal (payload in the next section). Full control over retries, proration, and plan changes.
Option B — Yuno subscriptions. Create a subscription per plan with the vaulted_token, and set the schedule so the engine's first charge lands on the plan's next natural renewal date. The current period was already collected on the old stack — the engine must start at the boundary, not today, or you double-charge.
Per plan (or per cohort): the current period was paid on the old processor, the next one is charged by Yuno. Disable the old subscription's auto-renewal the moment its Yuno replacement is armed — never leave both live, and never leave a gap.
Start with a pilot cohort. Track renewal outcomes via webhooks, keep retries on, and compare approval rates against your pre-migration baseline before moving the rest of the portfolio.
One request per renewal, server to server. No checkout session, no customer present. This is the same shape for a migrated Apple Pay plan, a Google Pay plan, or a plain card plan — by renewal time they are all stored credentials on card rails.
POST https://api.y.uno/v1/payments
# headers: public-api-key, private-secret-key, X-Idempotency-Key (unique per renewal attempt){
"account_id": "your-account-id",
"merchant_order_id": "renewal-2026-08-0042",
"country": "US",
"amount": { "currency": "USD", "value": 1999 },
"customer_payer": { "id": "<yuno-customer-id>" },
"workflow": "DIRECT",
"payment_method": {
"type": "CARD",
"vaulted_token": "<from-the-migration-mapping>",
"detail": {
"card": {
"stored_credentials": {
"reason": "SUBSCRIPTION",
"usage": "USED",
"network_transaction_id": "<from-the-export, if provided>"
}
}
}
}
}Sending a renewal without stored_credentials. An unflagged, out-of-session charge looks to the issuer like a brand-new customer-initiated payment with no cardholder present — exactly the pattern issuers decline. The flags are not decoration; they are what keeps your approval rates where they were before the move.
Using Yuno's subscription engine instead of your own scheduler? Create the subscription with payment_method.type: "CARD", the vaulted_token, and card.store_credentials.usage: "USED" — note the field is spelled store_credentials on the Subscriptions API. Because a customer-initiated authorization already happened before the subscription existed, this flag is mandatory there too.
usage: USED + reason: SUBSCRIPTION (+ the original network transaction ID when available) tell the issuing bank this is the same subscription continuing — not an unfamiliar merchant firing unexplained charges.While migrated plans cut over, new signups already run natively on Yuno — and both cohorts converge on the same renewal shape.
vault_on_success: true and stored_credentials { reason: "SUBSCRIPTION", usage: "FIRST" }.vaulted_token with usage: "USED" — or hand the plan to the subscription engine with the first cycle offset, since you already charged period one.Full wallet checkout flows (session setup, recurring context on the sheet, free-trial verification) are covered in the Apple Pay and Google Pay guides, and in Apple Pay direct integration if you own the sheet yourself.
A subscription merchant we recently worked with — web checkout, most volume in North America, cards in their own payment form plus Apple Pay and Google Pay buttons — was leaving a single-processor setup for a two-provider split, precisely to stop depending on one company for every renewal. A meaningful share of their active plans was wallet-paid, which is what made the migration feel blocked. It wasn't:
A customer starts a monthly plan through the Apple Pay sheet. First charge is customer-initiated on the old processor; the DPAN is stored there. Renewals tick along monthly.
Customers are created in Yuno. The merchant requests the export — cards plus wallet DPANs plus network tokens plus method IDs — and the file lands in Yuno's vault over SFTP. The mapping table (old method ID → vaulted_token) comes back. Meanwhile, the billing schedule is exported separately from the old processor's API. Nothing customer-facing has changed; the old processor still bills the current period.
Each plan's schedule is re-created against its vaulted_token, first charge set to the plan's next renewal date. Old auto-renew is switched off the same moment. No gap, no overlap.
The May customer's renewal fires from Yuno: usage: USED, reason: SUBSCRIPTION, original network transaction ID attached, routed to the provider that held the original agreement. Approved. The customer sees the same charge, on the same date, on the same statement.
Approval rates confirmed against baseline, routing opens to the second provider. Wallet plans now fail over like everything else in the portfolio — the single point of failure is gone, and no customer ever noticed a migration happened.
Nothing the customer ever touched changed: not the card in their wallet, not the renewal date, not the amount. The only thing that moved was who executes the charge — and the credential, flags, and transaction lineage moved with it.
merchant_customer_id mapping on hand.vaulted_token mapping stored durably.stored_credentials with usage: "USED" and reason: "SUBSCRIPTION".