Skip to main content

​
📄 Guide

Whether you are an exchange, a wallet or a platform, you can let cardholders add their DCS-issued card to Apple Wallet and Google Wallet with a single tap inside your app (known as push provisioning). There is no need to key in the card number manually, and the cardholder can start paying contactlessly straight from the phone. As a licensed issuer with its own BINs, DCS issues both virtual and physical cards that are compatible with the major digital wallets, so your cardholders can pay through Apple Pay, Google Pay and similar services.
How integration works today (read this first): Apple Pay self-service integration is now available through DCSProvisioningSDK and POST /open-api/card/v1/digital-wallet-ticket. The SDK handles in-app provisioning and Apple Wallet extensions, while the server endpoint issues the temporary ticket. Apple entitlement, card-program and token-service configuration still require coordination with the DCS integration team. See Apple Pay SDK Installation and the Implementation Guide. Confirm the Google Pay integration path with DCS when the project starts.

​
Mental model

Provisioning a card into a digital wallet means mapping a physical or virtual card to a token held inside the wallet: the real card number (PAN) is never placed on the device. The wallet pays with the token instead of the PAN, and the card scheme translates between the token and the underlying card. Four parties are involved:
Push provisioning parties and responsibilitiesPush provisioning parties and responsibilities
Relationship with Secure card details: the card data used for wallet provisioning comes from the same source as secure card details (both involve the real PAN), so the same PCI scope, key handling and whitelisting requirements apply. Read the two pages together.

​
Business flow and responsibilities

The table below lists the key steps of today’s manually coordinated flow, in the order they happen:
Why DCS submits on your behalf: push provisioning entitlements are granted by Visa and by Apple / Google at the issuer (BIN sponsor) level. DCS handles that relationship centrally as the issuer, so partners neither need to, nor should, contact Apple / Google or the card scheme channels directly.

​
Runtime provisioning flow (cardholder’s view)

In-app provisioning sequenceIn-app provisioning sequence
At Apple Pay runtime, the SDK first generates originRef; your backend exchanges it for a ticket through POST /open-api/card/v1/digital-wallet-ticket; the SDK then completes the encrypted PassKit and DCS / Visa exchange. See the Implementation Guide.

​
Current constraints and reconciliation

  • No sandbox: Visa does not provide sandbox cards for provisioning, so you must test with production cards. See Sandbox environment.
  • Not a launch blocker: provisioning can be enabled in parallel after your main flow is live; it is not a prerequisite for going live with card issuance.
  • Token lifecycle: when a card is replaced, reissued or its expiry date changes, the card scheme maintains the wallet token automatically through the Visa lifecycle mechanism, so cardholders normally do not need to provision the card again. Event notifications for these changes are on the roadmap.
  • Provisioning failures: wallet-side risk checks (device risk, repeated attempts in a short window, region mismatch and similar) can decline a provisioning request, and neither DCS nor the card scheme can override the wallet provider’s decision. We recommend telling the cardholder to retry after 24-48 hours.
  • Digital wallet reconciliation: purchases made with a wallet token appear in the daily reconciliation files alongside ordinary card transactions. Whether those files will carry a flag that identifies digital wallet transactions will be confirmed as the reconciliation capability matures. See Reconciliation files.

​
Next steps