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
To initiate network token provisioning, perform a server-to-server POST request with the required customer data,
excluding paymentType. A successful request will return an id that should be stored and
used in subsequent payments.
Tokenization response
The response will include a token transaction history, indicating that the network token provisioning process
has started with the card network. This process involves the issuer and may take some time for approval. In the
test environment, there is a simulated 2-second delay to mirror production conditions. The network token will be
retrieved during the next payment attempt.
Sample request:
2. Send payment using the token
To send a payment using the network token, perform a server-to-server POST request using the registration token retrieved
in the previous step.
Payment response
The response will include a token transaction history, indicating that an attempt was made to fetch the network
token from the card network. If no network token is active for payments, the payment authorization will proceed
using the real card data.
When the network token is fetched, the response will also provide the original PAN BIN. This information will be exposed
in the payment response as part of the card.bin parameter. It’s important to note
that the network token BIN is different from the original PAN BIN. This distinction is crucial for post-authorization
issuer BIN management, ensuring that you have the necessary details to handle the transaction accurately.
Sample request:
Tokenization during payment
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
To create a 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. A successful request will
return a registrationId that should be stored and used in subsequent payments.
Tokenization response
The response will include a token transaction history, indicating that the network token provisioning process has
started with the card network. Due to a simulated 2-second delay in the test environment, the network token provisioning
request will be in flight, and the payment will continue using the original PAN. The network token fetching is
attempted, but the response will indicate that the provisioning request is still in progress.
When the network token is fetched, the response will also provide the original PAN BIN. This information will be
exposed in the payment response as part of the card.bin parameter. It’s important to note that
the network token BIN is different from the original PAN BIN. This distinction is crucial for post-authorization
issuer BIN management, ensuring that you have the necessary details to handle the transaction accurately.
Sample request:
Switching to network token
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
To switch to a network token, perform a server-to-server POST request using the stored registration token
with all required payment and customer data, including payment type, amount, and currency.
Payment response
The response will include a token transaction history, indicating that the network token provisioning process
has started with the card network. While the network token is being provisioned by the card network, involving
the issuer in the token approval process, the payment authorization will continue using the real card data.
Due to a simulated 2-second delay in the test environment, the network token provisioning request will be in
flight, and the network token will be prepared for subsequent payment authorizations.
Sample request:
CIT payment with network token
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
To send a payment initiated by the cardholder, perform a server-to-server POST request using the stored
registration token with all required payment and customer data, including payment type, amount, and currency.
Payment response
The response will include a token transaction history, indicating that an attempt was made to fetch the network
token from the card network. If no network token is active for payments, the payment authorization will proceed
using the real card data.
When the network token is fetched, the response will also provide the original PAN BIN. This information will be
exposed in the payment response as part of the card.bin parameter. It’s important to note that the
network token BIN is different from the original PAN BIN. This distinction is crucial for post-authorization
issuer BIN management, ensuring that you have the necessary details to handle the transaction accurately.
Sample request:
MIT payment with network token
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
To send a payment initiated by the merchant, perform a server-to-server POST request using the stored registration
token with all required payment and customer data, including payment type, amount, and currency.
Payment response
The response will include a token transaction history, indicating that an attempt was made to fetch the network
token from the card network. If no network token is active for payments, the payment authorization will proceed
using the real card data.
When the network token is fetched, the response will also provide the original PAN BIN. This information will
be exposed in the payment response as part of the card.bin parameter. It’s important to note that the
network token BIN is different from the original PAN BIN. This distinction is crucial for post-authorization issuer
BIN management, ensuring that you have the necessary details to handle the transaction accurately.
Sample request:
Payment with your network token
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
To send a payment using your network token, perform a server-to-server POST request with your available network
token and the required payment and customer data, including payment type, amount, and currency.
Using tokenAccount.* data parameters
When provisioning network tokens and obtaining cryptograms through your own Token Service Provider (TSP),
you can pass the network token authorization data points in the request using the tokenAccount.*
data parameters. This ensures that all necessary information is included for the network token authorization.
oppwa
Server-to-Server Network Tokens
