Skip to content
UPay Business
Digital Wallets3 min read

Digital Wallet Support: What Tokenization Actually Requires

Adding a card to Apple Pay or Google Pay looks like one tap. Behind it sits a tokenization chain with several parties who each have to say yes.


"Does it work with Apple Pay?" is usually the second question a prospective cardholder asks. The honest answer is "if the programme is eligible" — and the reason that hedge exists is worth understanding, because it shapes what you can promise in your own marketing.

What tokenization is

When a card is added to a digital wallet, the actual card number is not stored on the device. Instead the network issues a Device Account Number — a token that only works from that device, in that wallet. Tapping to pay transmits the token plus a one-time cryptogram, never the underlying PAN.

This is why a compromised phone does not expose the card, and why removing a device revokes only that token.

The chain of approvals

Each participant has to be in place before a card can be provisioned:

  1. The card network operates the Token Service Provider that mints and manages tokens.
  2. The issuer must be enrolled with that service for your card range.
  3. The BIN range itself must be configured as eligible — this is per-range, not per-programme.
  4. The wallet provider (Apple, Google, Samsung, Tencent) must support the issuer in that market.
  5. The device and OS must support the wallet in the cardholder's region.

Any one of these missing means no provisioning. This is why availability genuinely varies by programme, network, issuer, device and market — the disclaimer is not legal padding, it is a description of the dependency chain.

Push versus manual provisioning

Manual is the familiar path: the cardholder opens the wallet app and enters or scans the card. It works without any integration on your side.

Push provisioning puts an "Add to Apple Pay" button directly inside your app. One tap, no typing, card in the wallet. Conversion is dramatically better — a meaningful share of cardholders never complete manual entry.

Push requires additional integration and separate approval from the wallet provider. If wallet adoption matters to your economics, scope it from the start rather than treating it as a later enhancement.

What this means for your marketing

Two rules keep you out of trouble:

  • Do not state flat availability. "Works with Apple Pay" becomes false the moment a cardholder in an unsupported market tries it. "Eligible cards can be added to Apple Pay" stays true.
  • Do not recreate the marks. Apple, Google, Samsung and Tencent each publish brand guidelines specifying exact artwork, clear space and permitted wording. They also require you to be an approved participant before displaying the mark at all. Redrawn logos are both non-compliant and a trademark problem.

Verification and cardholder experience

Some provisioning attempts trigger step-up verification — a one-time code, or a call to support — depending on the issuer's risk configuration. Plan for it: an unexplained verification prompt during onboarding is a common drop-off point. Tell cardholders it may happen and why.

Before you promise anything

Confirm, per programme:

  • Which wallets your issuer supports, in which markets
  • Whether your BIN range is token-enabled
  • Whether push provisioning is available or manual-only
  • What the step-up verification flow looks like for your cardholders

Get those four answers and you can write wallet copy that is both compelling and accurate.

Want the specifics for your programme? Book a call and we will confirm what is actually available for your markets.

Ready to accept crypto payments?

Get a custom proposal for payment rails or white-label card issuing.

Book a call

Related reading