Tokenization technologies enable the browser to obtain a payment token from a token service provider (TSP), such as a credit card network or issuer, and thus avoid sending the user's credit card information (esp. the Primary Account Number or PAN) to the merchant. This not only improves security and privacy for the user, but also reduces risk for the merchant and other parties.
Although many existing payment technologies (e.g., the major credit card brands, ApplePay, etc.) support tokenization, no browser-friendly open standard is yet available. That will change as the W3C makes progress on its Tokenized Card Payment Method. This wiki page summarizes our work on adding tokenization support to the Firefox web payments implementation.
Despite the fact that the Tokenized Card Payment Method is still lacking a number of important details, the general approach is clear from similar technologies (such as the EMV® Payment Tokenisation Specification and Apple Pay):
- These will be "network tokens" (not virtual card numbers) obtained from a credit card network such as Visa, MasterCard, or Amex.
- OPEN ISSUE: We might need to call separate (but similar) APIs at each card network, obtain API keys for each of those endpoints, etc. Research is underway to determine if we can use a payment gateway and thus call only a single API.
- As far as we know so far (more details soon), these APIs involve a few methods:
* A one-step request-response interaction to obtain a long-lived token based on a PAN, which is encrypted using public-key cryptography before sending to the TSP. * This token will need to be securely persisted to long-term storage. * Another one-step request-response interaction to obtain a payment token for a given transaction, to which one input is the long-lived token.
- After obtaining the transaction-specific payment token, the browser would be able to support the `tokenized-card` method specified in the W3C specification. The workflow appears to be:
* As part of the payment request, the browser would receive the URL of the TSP associated with the merchant website. * The browser would contact the TSP to obtain the payment details for sending to the merchant, including the last four digits of the actual PAN (or a masked card number) along with the expiry month and year of the actual card, as well as the card network of the original PAN.
As a point of comparison regarding privacy and security, it's worthwhile to read the Apple Pay section of the iOS Security Guide.
Scope of Work
In this section we will define a high-level scope of work for the tokenization effort. If the Approach section above does not contain sufficient information to complete the scoping, please add to the Open Issues section below.
- Can we use a payment gateway and thus call only a single API?
As of April 2018, the W3C Tokenized Card Payment Method is still an unofficial proposal and has not yet been published as a "First Public Working Draft" of the Web Payments WG, let alone as a Candidate Recommendation. The scope of work in the previous section is intended to function as early-stage input to W3C standardization.
Other tokenization technologies would be available more quickly (e.g., obtain tokens from existing token service providers and auto-detect support for such methods if offered by the merchant website); however, they are currently out of scope for this document.