Tokenization with Custom UI

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

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.

Here is an example of the Payment Status response:

{
  "id":"8a8294495e295260015e2da4694059a4",
  "registrationId":"8a82944a580a782101581f3a0b4b5ab9",
  "card":{
    "bin":"420000",
    "last4Digits":"0000",
    "holder":"Jane Jones",
    "expiryMonth":"05",
    "expiryYear":"2018"
  },
  "result":{
    "code":"000.100.110",
    "description":"Request successfully processed in 'Merchant in Integrator Test Mode'"
  },
  // ...
}

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.

1. Prepare checkout

You have to change two parameters in step 1:

  • createRegistration=true has to be sent.
  • paymentType should not be sent.

Receive a token with registration status

Request transaction status from your server as it's described in integration guide.

NOTE: Resource path for registration-only transaction differs from the path for getting payment status.

Parameter id is your generated token. See an example of the Registration Status response below:

{
  "id":"8a82944a580a782101581f3a0b4b5ab9",
  "card":{
    "bin":"420000",
    "last4Digits":"0000",
    "holder":"Jane Jones",
    "expiryMonth":"05",
    "expiryYear":"2018"
  },
  "result":{
    "code":"000.100.110",
    "description":"Request successfully processed in 'Merchant in Integrator Test Mode'"
  },
  // ...
}


Using payment data


Getting the payment data by token ID

After checkout is created with customer tokens, you can request the stored payment data along with checkout info using SDK API.


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.