As a wallet, Paze stores Consumer payment cards as network tokens, meaning that the number on a Consumer’s physical card, the Funding Primary Account Number (FPAN) is not retained by Paze. This helps to limit Consumer impact if an individual network token is compromised, since their card’s issuer can simply deactivate the single affected network token while keeping the original card and its other network tokens as-is. This also allows Paze, as the token requestor, to receive automatic updates from Payment Networks in the event of card reissuance.

Network token availability is not limited to Paze. A Merchant, or a payment service provider (PSP) acting on a Merchant’s behalf, may work directly with Payment Networks to exchange consumers’ FPANs for network tokens. This allows the Merchant and their consumers to access the aforementioned benefits of network tokenization.

Network tokenization is distinct from other forms of tokenization. A Merchant may contract with a PSP to fully delegate management of payment credentials. PSPs can store this data in compliance with payment card industry (PCI) standards and generate a proprietary token for Merchants to reference, thereby preventing Merchants from needing to develop their own PCI-compliant systems.

A nuance of PCI compliance is that since network tokens and their associated data have the same structure as FPANs, automated auditing systems may flag them in a database as non-compliant. As a result, a Merchant may have a network token but still request that their PSP tokenize that value once more. PSP tokens are generally distinct in structure from FPANs.

The following diagram illustrates which entity retains which data across three potential tokenization scenarios.

Implementation Effort Estimation

Because the Paze Service includes several optional features, Merchants and their PSPs will have varying amounts of work required to complete an integration.

The following table below provides yes/no questions that can indicate a Merchant or PSP’s effort required to integrate with Paze, with “yes” answers requiring significantly less development than “no” answers. In most cases, the answer to the functional question is a suitable proxy for the answer to the technical question.

The Incremental Development column assumes that all preceding questions have been answered with “yes.”

Implementation Effort Estimation**

Feature	Functional Question	Technical Question	Incremental Development
One-time purchase	Do you currently support digital wallet transactions?	Do you support transacting using a network token instead of an FPAN?	Decryption of Paze–specific payload
Multiple transactions from the same consumer authorization	Do you currently support specific payment structures that Merchants need (e.g., split shipment, recurring payments)?	Do you currently support the network-specific requirements to process Merchant-initiated transactions (MIT)?	Using network token for MIT processing
Merchant retention of payment card credentials for future use	N/A	Do you currently support exchanging FPANs with Payment Networks for persistent Merchant network tokens?	Following networks’ token-for-token swap guidelines for consumer-initiated transactions (CIT)

Even if a PSP supports all the above services, Merchants should confirm if their particular contractual agreement includes those offerings.

Multiple Transactions with the Same Authorization

Consumer-Initiated Transactions (CIT) where the Consumer actively participates in a purchase are supported directly through the Paze Service, or by relying on the Merchant as stated below.

Paze supports a unique solution for Merchant retention of Consumer payment cards on file. Typically, retaining a card on file means keeping the Consumer’s FPAN in a PCI-compliant fashion or working with the respective Payment Network to generate a network token from the FPAN. With Paze, Merchants can exchange the network token received from Paze for their own network token.

The following processes describe how to use Paze to enable a credential on file when a Merchant has received consent from the Consumer to store payment data for subsequent purchases. Data provided by Paze can be exchanged with the appropriate Payment Network for a dedicated Merchant network token, which will operate within the guidelines of that service.

Requirement: In order to obtain a credential on file, a Merchant must participate directly or indirectly as a token requestor with the applicable Payment Network Token Service Provider (e.g., Mastercard Digital Enablement Service (MDES), Visa Token Service (VTS)). Discover does not offer a service to enable a credential on file for Discover cards received from Paze. Aside from providing the required payment token, cryptogram and dynamic data, Paze does not participate in establishing a Consumer’s credential on file with a Merchant. This section is provided solely for Merchants’ reference and is recommended to be provided to their PSPs where applicable.

Note: The Payment Network resources provided below are subject to change at each Payment Network’s sole discretion. Refer to their respective developer documentation for the latest technical requirements.

Mastercard Tokenization

For Mastercard tokens, refer to:

https://developer.mastercard.com/mdes-digital-enablement/documentation/ for a simple tokenization API
https://developer.mastercard.com/mastercard-checkout-solutions/documentation/use-cases/card-on-file/ for a tokenization platform

For additional details, contact [email protected]

Use the following data to populate the request parameters:

MDES

tokenRequestorId: the Merchant’s token requestor identifier with Mastercard
accountNumber: token received from Paze
expiryMonth: panExpirationMonth received from Paze
expiryYear: panExpirationYear received from Paze
source: “Existing Credentials”
securityCode: dynamicData value received from Paze

SCOF

serviceId: the Merchant’s token requestor identifier with Mastercard
primaryAccountNumber: token received from Paze
panExpirationMonth: panExpirationMonth received from Paze
panExpirationYear: panExpirationYear received from Paze
cardSource: “Existing Credentials”
cardSecurityCode: dynamicData value received from Paze

Note: Distinct Mastercard cryptograms are used for a Payment Transaction authorization (20-byte cryptogram) and its subsequent tokenization request (3-digit cryptogram). A Merchant can use the Paze Merchant B2B API to request the 3-digit cryptogram within ten calendar Days of the consumer authentication event.

Visa Tokenization

For Visa tokens, refer to https://developer.visa.com/capabilities/vts.

Use the following data to populate the request parameters:
clientAppID: the Merchant’s Token Requestor identifier with Visa
clientDeviceID: ECOM
clientWalletAccountID: the identifier that the Merchant will use to identify the Consumer when they next visit the Merchant’s website
locale: en_US
protectionType: CLOUD
panSource: TOKEN_FOR_TOKEN
encPaymentInstrument: token received from Paze
name: fullName received from Paze
expirationDate: ExpirationDate object containing the panExpirationMonth and panExpirationYear received from Paze
billingAddress: BillingAddress object received from Paze
presentationType: ECOM