Card push provisioning lets an issuer place a payment card into a digital wallet from its own app or website. The cardholder taps “Add to Wallet,” completes any required verification, and receives a device-specific network token. The flow is convenient, but it is a separate integration from creating the card itself.
This guide follows the hand-offs between the issuer app, provisioning service, card network, wallet and issuer processor.
What card push provisioning does
Manual wallet enrollment asks a cardholder to enter card details inside Apple Pay, Google Pay or another wallet. Push provisioning starts in the issuer’s app. The app identifies an eligible card, requests an encrypted payload, and passes that payload to the wallet’s supported interface.
Visa’s In-App Provisioning API documents this model for Apple Pay, Google Pay and Samsung Pay. It can be used during debit or credit card issuance, after a card already exists, and for use cases including prepaid, virtual, commercial and one-time cards. Visa says its API produces encrypted card data for the selected wallet rather than asking the client to pass raw card details into the wallet flow.
Provisioning does not move the original card number onto the device for payments. The card network creates a token associated with a specific card, device and wallet. Adyen describes a wallet network token as a 16-digit PAN alternative unique to that pairing.
The parties in the flow
One “Add to Wallet” button coordinates several systems:
- Issuer app or website: starts the request and presents the user interface.
- Issuer or program manager: decides which cards and users may provision.
- Issuer processor: supplies card and authentication data and reports token state.
- Card network token service: creates and maintains the network token.
- Digital wallet: checks device eligibility and hosts the token on the user’s device.
- Cardholder: accepts wallet terms and completes verification when required.
The program still needs the issuing relationship explained in BIN sponsorship. Push provisioning does not replace the bank, processor or network; it connects their existing card record to a wallet token.
Card enrollment and encrypted payloads
Visa separates universal card enrollment from the wallet-specific provisioning request. Enrollment registers the account and returns a universal card identifier. The client can then use that identifier to request encrypted card data for the chosen wallet without repeatedly handling the primary account number.
The client passes the encrypted payload to the wallet for tokenization. Visa’s current Google Unified Push Provisioning documentation describes one payload containing separate opaque data for the funding PAN and device PAN. It also lists Google onboarding and application or web-host whitelisting as prerequisites.
Those details show why the payload is not the whole product. The app must know whether the device and card are eligible, whether a token already exists, which wallet the user selected, and what to show when enrollment is declined or needs verification.
Authentication belongs in the card setup
Some wallet requests can be approved with low friction. Others need proof that the person adding the card is the legitimate cardholder.
Adyen requires authentication data to be attached to an issued card before it can support its documented wallet flow. A program can link a mobile number, an email address or both. When verification is required, Adyen sends a one-time password to the selected contact method; a successful check allows the card to be added.
This is an operating control, not just an API field. The program must keep contact data current, protect changes to that data, avoid exposing whether an account exists, and give support staff a safe path for users who cannot receive the code. A changed phone number immediately before provisioning deserves different risk treatment from a long-standing verified number.
Model the token separately from the card
A physical or virtual card can have more than one wallet token. A user might add the same card to a phone and a watch, or replace one device without replacing the underlying card.
Keep a token record with at least:
- processor or network token ID;
- underlying payment-instrument ID;
- wallet type and token requestor;
- device operating system and form factor when available;
- creation time and last four digits;
- current status;
- authentication outcome;
- the last event used to update the record.
Adyen documents token states including inactive, active, suspended and closed. It also allows a token to be suspended, reactivated or permanently closed separately from the card. Closing the underlying payment instrument can close its tokens, but a lost phone may justify suspending one token while the card remains usable elsewhere.
Webhooks are the source of final state
The app should not mark a card as active in a wallet merely because the user tapped the button or because an API accepted the request.
Adyen’s token webhooks distinguish creation from later status updates. A newly created token can be inactive while a risk decision is approved, requires authentication or is declined. An update confirms that the token became active, was suspended or was closed. The documented flow can require OTP or phone verification before activation.
Treat those events as asynchronous and retry-safe. Store event IDs, accept duplicate delivery, and reject older state changes that arrive after a newer one. The user interface can then show accurate states such as “pending verification,” “ready in wallet” or “removed from wallet.”
The same event discipline applies to card authorizations. Card authorization reversal explains why event order also matters after the wallet token is used for a purchase.
Controls for a production rollout
Before launch, define controls at three levels.
Eligibility controls: supported card products, countries, BIN ranges, devices and wallets. Visa says the relevant issuer must participate in the Visa Token System and that clients must meet each wallet provider’s prerequisites.
Provisioning controls: device and account risk, recent credential changes, token count per card, verification method and fallback support. Adyen documents transaction rules that can limit the number of active tokens on one card.
Lifecycle controls: suspend, reactivate and close a token; respond when the card is closed; and reconcile processor events with the app’s state. Permanent closure should require a different confirmation path from a temporary suspension.
For transaction-level limits after provisioning, see card spending controls.
What to test
Test the full state machine on supported devices, not only a successful happy path:
- eligible card with automatic approval;
- verification by SMS and email;
- wrong or expired verification code;
- card already present in the selected wallet;
- unsupported device, region or card product;
- duplicate provisioning request;
- webhook delivered twice or out of order;
- token suspended and reactivated;
- token removed from the wallet;
- card closed while several device tokens exist.
Visa notes that its sandbox exposes only a subset of possible requests and that production promotion requires the applicable onboarding and agreement. Sandbox success therefore proves the integration shape, not production eligibility.
