Platform
Tokenisation
Replacing a card number with something safe to store — what exists today, and what does not.
This page describes a subject the platform has an answer for and this portal cannot yet state. What is written below is the shape of the answer, not a commitment about this installation.
- Whether network tokenisation (Visa VTS, Mastercard MDES, Jaywan equivalent) is in the roadmap.
- Whether wallet provisioning will be exposed as an API or handled entirely inside the platform.
- Whether card-on-file tokens for merchants are in scope for the UAE package.
No endpoint on this platform issues, reads or de-tokenises a payment token. That is the honest state, and this page exists to say it rather than to leave you inferring it from a heading that never appears.
The word "token" does appear on this portal, twice, and neither instance is card tokenisation:
- OAuth2 access tokens authenticate your integration. Those are documented under authentication.
- The shadow card number is a stable internal reference used in place of the PAN across almost every operation. It is safe to store and safe to log, and it is what your database should key on.
What the shadow card number does, and does not, do
If you are looking for tokenisation because you want to avoid holding card numbers, the shadow card number already solves that problem for you. Almost every operation addresses a card by it. You can build a complete integration without ever storing a PAN.
What it does not do is travel. It is meaningful only inside this platform: a scheme does not recognise it, a merchant cannot charge against it, and a wallet cannot be provisioned from it. That is what network tokenisation would provide, and that is what is absent.
What is missing, named
| Capability | State |
|---|---|
| Network tokens (Visa, Mastercard, Jaywan) | No endpoint |
| Wallet provisioning (Apple Pay, Google Pay, Samsung Pay) | No endpoint |
| Card-on-file tokens for merchants | No endpoint |
| Token lifecycle — suspend, resume, delete | No endpoint |
| Token to PAN mapping for dispute investigation | No endpoint |
Wallets depend on the first two, which is why the wallets capability is also marked planned rather than described as available. They are one gap, not two.
What to do about it
If your card programme needs wallet support at launch, this is a scoping conversation to have before the programme design phase closes, not a matter of finding the right endpoint. The questions at the top of this page are the ones to put to DgPays; each of them changes the answer materially.