This Server-to-Server guide describes how you can store the data, provision a network token
with the involvement of the card network and then subsequently use the network token authorization data for a payment.
To better understand what network tokens are, please read
Tokenization guide.
To know which acquirers do support network tokenization, please reach out to your Customer Success Manager.
To collect card data, you must be PCI-DSS compliant. To minimize your compliance requirements,
please use COPYandPAY Network Tokens.
The merchant collects card data from shopper and initiates tokenization. No payment request/flow involved.
A registration token is synchronously provisioned and returned to the merchant. The registration token can then be used in
subsequent payments. In the background, a network token is being provisioned by the card network with Issuer involved in
the token approval process to make it active for payments.
Send the payment request using the stored registration token.
Transactions:
1. Create the token
Perform a server-to-server POST request with the required customer data, but excluding paymentType. The response to
a successful request is an id that should be stored and used in subsequent payments.
A token transaction history is provided in the response to let you know that the network token provisioning kicked-off with
the card network. The provisioning request takes time with issuer involved in the token approval process. The network token will
be fetched with the subsequent payment attempt.
Perform a server-to-server POST request over the registration token retrieved in the previous step.
A token transaction history is provided in the response to tell you that the network token is attempted to be fetched from
the card network. The payment authorization continues with real card data if no network token is yet active for payments.
The network token BIN (Bank Identification Number) is different than the original PAN (Primary Account Number) BIN.
However, the original PAN BIN is provided in the response to help you with a better post-authorization real issuer BIN management.
The merchant collects card data from shopper and initiates tokenization along an account verification
(zero amount auth) or initial purchase. A registration token is synchronously provisioned and returned to the merchant once the
payment is complete. The registration token can then be used in subsequent payments. In the background, a network token is being provisioned by
the card network with Issuer involved in the token approval process. The payment is authorized with real card data
or with the network token if available and active.
Send the payment request with the collected card data asking for the card to be tokenized once the payment ends successfully.
Transactions:
1. Create the token during payment
Perform a server-to-server POST request with createRegistration=true and all required payment
and customer data, including payment type, amount and currency. The response to a successful request is a registrationId
that should be stored and used in subsequent payments.
A token transaction history is provided in the response to let you know that the network token provisioning kicked-off with the
card network. The network token is then attempted to be fetched before the payment authorization beggins. If no network token is
yet active for payments then the payment authorization continues with real card data.
A merchant initiated (MIT) payment is submitted based on the available card-on-file agreement with the shopper.
Card is already on file, but as it's not yet network tokenized then a provisioning of a network token is kicking-off.
The current payment is authorized with real card data. The subsequent payments will attempt to fetch a network token
from the card network before payment authorization beggins.
Send the payment request using the stored registration token to initiate network token creation with the card network.
Transactions:
1. Switch to network token
Perform a server-to-server POST request over the stored registration token with all required payment and customer data,
including payment type, amount and currency.
A token transaction history is provided in the response to let you know that the network token provisioning kicked-off with the card network.
While the network token is being provisioned by the card network with issuer involved in the token approval process, the payment authorization continues
with real card data. The network token will be fetched with the subsequent payment authorization.
A shopper returns on the merchant’s website (card is already tokenized). Network token is provisioned and active for payment.
An unscheduled purchase with the saved token is performed. A cardholder initiated (CIT) payment is then authorized with the
active network token if the acquirer supports it.
Send the payment request using the stored registration token (shopper is present).
Transactions:
1. Send payment initiated by the cardholder
Perform a server-to-server POST request over the stored registration token with all required payment and customer data,
including payment type, amount and currency.
A token transaction history is provided in the response to tell you that the network token is attempted to be fetched from
the card network. The payment authorization continues with real card data if no network token is yet active for payments.
The network token BIN (Bank Identification Number) is different than the original PAN (Primary Account Number) BIN.
However, the original PAN BIN is provided in the response to help you with a better post-authorization real issuer BIN management.
A merchant initiated (MIT) payment is submitted based on the available card-on-file agreement with the shopper.
Card is already tokenized. Network token is provisioned and active for payment. MIT payment is authorized with the network token
if the acquirer supports it.
Send the payment request using the stored registration token (shopper is not present).
Transactions:
1. Send payment initiated by the merchant
Perform a server-to-server POST request over the stored registration token with all required payment and customer data,
including payment type, amount and currency.
A token transaction history is provided in the response to tell you that the network token is attempted to be fetched from
the card network. The payment authorization continues with real card data if no network token is yet active for payments.
The network token BIN (Bank Identification Number) is different than the original PAN (Primary Account Number) BIN.
However, the original PAN BIN is provided in the response to help you with a better post-authorization real issuer BIN management.
The merchant has its own Token Service Provider (TSP) and wants to submit payments with its existing network token authorization data.
The merchant provides all the required network token data including dynamic cryptographic data when necessary. The payment is authorized
with the network token if the acquirer supports it.
Send the payment request using the network token and cryptographic data as received from your Token Service Provider.
Transactions:
1. Send payment using your network token
Perform a server-to-server POST request with your available network token and required payment / customer data,
including payment type, amount and currency.