PIPE allows you to securely collect card data from shoppers and initiate provisioning
of a network token with the respective card network. While the network token is being provisioned, you are
immediately receiving a registration token to store it for future usage e.g. recurring payments, one-click payments.
To better understand network tokens in eCommerce and inStore, please read
Tokenization Guide.
To know which acquirers do support network tokens, please reach out to your Customer Success Manager.
The merchant collects card data from shopper via widget 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.
There are two ways to store the raw card details during a payment checkout:
Merchant-determined tokenization (see below).
Add createRegistration=true in the checkout request.
Shopper-determined
tokenization. Add a checkbox to the PIPE form to let the customer decide whether
or not to store the raw card details.
To initiate network token provisioning, 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 an id required in the second step to create the payment form.
Sample request:
2. Create the payment form
Create the payment form by adding the following lines of HTML/JavaScript to your page:
The response will include a token transaction history, indicating that the network token provisioning process has
started with the card network. The network token is then attempted to be fetched before the 3D Secure authentication
and payment authorization begins. Due to a simulated 2-second delay in the test environment, the network token
provisioning request will be in flight, and if no network token is yet active, both the 3D Secure authentication
and payment authorization will continue 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:
4. Send payment using the registration
To send a payment using the network token, perform a server-to-server POST request using the registration token retrieved
in the previous step. Alternatively, use
one-click checkout to authorize the payment with a selected stored registration token.
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:
Standalone tokenization
The merchant collects card data from shopper via widget and initiates the registration 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.
To initiate network token provisioning, perform a server-to-server POST request to prepare the checkout with the
required customer data, including createRegistration=true but excluding paymentType. The
response to a successful request is an id required in the second step to create the registration form.
Sample request:
2. Create the registration form
Create the registration form by adding the following lines of HTML/JavaScript to your page:
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:
4. Send payment using the registration
To send a payment using the network token, perform a server-to-server POST request using the registration token retrieved
in the previous step. Alternatively, use
one-click checkout to authorize the payment with a selected stored registration token.
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:
One-click checkout
Speed up of the checkout process by re-using the raw card data a shopper entered previously. A shopper returns on the
merchant’s website (card is already tokenized). Network token is provisioned and active for payment. An unscheduled
one-click purchase with one of the saved registration tokens is performed. A cardholder initiated (CIT) payment is
authorized with the active network token.
Find out if the payment with the network token was successful.
Transactions:
1. Prepare the checkout
To initiate network token provisioning, perform a server-to-server POST request to prepare the checkout with the required
payment data, including the registration token IDs. The stored card on files should be sent in the registrations[n].id
parameter, where n is a sequence number from zero, incrementing for each of the customer's registration IDs. The response
to a successful request is an id required in the second step to create the one-click payment form.
Sample request:
2. Create the payment form
Create the payment form by adding the following lines of HTML/JavaScript to your page:
When PIPE builds up the payment form it automatically fetches the registrations data from the server and displays the pre-filled widgets to the shopper.
Sample form:
3. Get the payment status
Once the payment request is processed, the customer is redirected to your shopperResultUrl along with
a GET parameter resourcePath.
The response will include a token transaction history, indicating an attempt to fetch the network token performed
before the 3D Secure authentication and payment authorization begins. If no network token is yet active, both the
3D Secure authentication and payment authorization will continue 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.
