Tokenization

Tokenization replaces sensitive payment data such as credit card number with a unique identifier or token.
Once you obtain a token for card data or a bank account, you can charge transactions on these tokens without having to store the payment data.

This guide describes how you can store the data using our SDK and Server-to-Server API, how you can subsequently use the stored card details for a one-click payment and how to delete stored data.

Supported payment methods to store

Currently tokenization of credit card and bank account information is supported.

The following card details can be tokenized:

card holder,

card number,

expiration date.

CVV cannot be stored with a token, you can prompt the shopper to re-enter the CVV code for subsequent transaction, if required.

The following bank account details can be tokenized:

bank account holder,

IBAN.

Storing payment data

SDK provides two options for storing the payment data:

Store the data during a payment: When a shopper is checking out for the first time, he has to fill in his complete payment data. Use this option to automatically store his data during the payment for reuse in later transactions.

Store the data as stand-alone: If your site provides shoppers with an administrative area where they can register their payment details independent of a checkout-process, this option is for you.

Store the data during a payment

1. Enable tokenization of the payment parameters

You can store the data during a payment. Just set the property isTokenizationEnabled to YES for the created payment parameters. It is available for the OPPCardPaymentParams and OPPBankAccountPaymentParams. Then create and submit a transaction as usual.

1. Enable tokenization of the payment parameters

You can store the data during a payment. Just set the property isTokenizationEnabled to YES for the created payment parameters. It’s available for the CardPaymentParams and BankAccountPaymentParams. Then create and submit a transaction as usual.

2. Receive a token along with payment status

Our server will generate token for the passed payment details and return it with the payment status (step 3). Parameter registrationId is your generated token. Your server is responsible for handling and storing the token.

Store the data as stand-alone

It is also possible to create just a registration separate from any later payment.
A registration-only transaction is basically using the same workflow and parameters as a payment. You just need to update checkout request and use another endpoint when submitting transaction.

Using payment data

1. Prepare checkout with tokens

Add token parameter to the prepared checkout request (step 1). Your server should send shopper' tokens along with other configuration data such as amount, currency, order type and etc.

Tokens should be sent in the registrations[n].id parameter, where n is a sequence number from zero, incrementing for each shopper's token. For example, if the shopper has two tokens, you would send registrations[0].id = {first tokenID} and registrations[1].id = {second tokenID}.

Then create and submit a transaction with token payment parameters as usual.

NOTE: CVV cannot be stored with a token, you can prompt the shopper to re-enter the CVV code for subsequent transaction, if required. CVV should be provided to the OPPTokenPaymentParams before submitting transaction.

1. Prepare checkout with tokens

Add token parameter to the prepare checkout request (step 1). Your server should send shoppers' tokens along with other configuration data such as amount, currency, order type and etc.

Tokens should be sent in the registrations[n].id parameter, where n is a sequence number from zero, incrementing for each shopper's token. For example, if the shopper has two tokens, you would send registrations[0].id = {first tokenID} and registrations[1].id = {second tokenID}.

Then create and submit a transaction with token payment parameters as usual.

NOTE: CVV cannot be stored with a token, you can prompt the shopper to re-enter the CVV code for subsequent transaction, if required. CVV should be provided to the TokenPaymentParams before submitting transaction.

Skipping 3D-Secure for stored cards

To skip 3D-Secure authentication for stored cards, your server should send one additional parameter recurringType=REGISTRATION_BASED during Preparing the checkout.

Deleting the stored payment data

Once stored, a token can be deleted using the backend API method. See details in Server-to-Server section.
You will have to expose this API on your server, because authentication data should be sent as parameters.