Widget Network Tokens

COPYandPAY Network Tokens

Last updated:October 21, 2024

COPYandPAY 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.

Use cases

Tokenization during payment

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:

  1. Merchant-determined tokenization (see below). Add createRegistration=true in the checkout request.
  2. Shopper-determined tokenization. Add a checkbox to the COPYandPAY form to let the customer decide whether or not to store the raw card details.

How it works

1

Prepare the checkout

Send the request parameters server-to-server to prepare the payment form.

2

Create the payment form

Display the payment form on your checkout page. Shopper submits the card and payment information.

Network token provisioning for the collected card data is automatically triggered with card network.

Payment authorization is performed with network token, if provisioned and active, or otherwise, with real card data.

3

Get the payment status

Find out if the payment and registration were successful.

4
OPTIONAL

Send payment using the registration

Send payment using stored registration token.

Transactions:
RG
RG
TK
TK
DB
DB
TF
TF
3D
3D
RE
RE
DB
DB
TF
TF
RE
RE

1. Prepare the checkout

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:

  • With the checkoutId received from first step 
    <script src="https://eu-test.inpendium.net/v1/paymentWidgets.js?checkoutId={checkoutId}"></script>
  • With the shopperResultUrl as the page on your site where the end consumer should be redirected after the payment is complete 
    <form action="{shopperResultUrl}" class="paymentWidgets" data-brands="VISA MASTER AMEX"></form>

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. 

resourcePath=/v1/checkouts/{checkoutId}/registration

Payment response

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:

See also