Tokenization


Tokenization makes your transactions easier. Once you have created a token, you don’t have to enter all the payment data every time, because the data will be stored with the tokenization. That makes it possible to use the payment data later. The token can be used for recurring transactions.

The Tokenization includes the registration, the use of the stored payment data and then the cancellation of the stored payment data.


   Merchant needs to set authentication token in header for each request. To generate authentication token, please refer Auth token API.

Registering the payment data

You have two opportunities to create a token.


Customer sign up :

Merchant or Partner can register a customer with using this API.

Customer sign up request is send over HTTPS to the merchantServices/api/v1/customerSignup resource using POST method.


Sample Request


Sample Response


Data storing during a payment:

While sending a POST request to the /transactionServices/REST/v1/payments endpoint it is possible to store the payment’s data simultaneous to the payment. The POST request you have to send is the createRegistration parameter with a value of true.

For future operations you need the parameter registrationId which you get as an additional response. With this parameter you have access to the stored parameter data later.


Sample Request


Sample Response


Data storing as stand-alone:

Your second option for a registration is a stand-alone request to /transactionServices/REST/v1/registrations endpoint. What means that you directly receive a registration object in the ID field.


Sample Request


Sample Response


Payments using the stored payment data:

When the customer has just registered his data but didn’t send the payment on the same time. In this case you can store the data as stand-alone, so you send the payment directly to the /transactionServices/REST/v1/paywithtoken/{id} endpoint.


Sample Request


Sample Response


Use stored payment data for Recurring Payments

If you want to use the stored payment data for recurring payments, you need to add the parameter recurringType to your requests.

There are two different values for the payment request which depend on if it’s an initial or a subsequent payment request.

  • Use the value INITIAL for an initial payment
  • Use the value REPEATED for a subsequent payment.

 If you are in need of a more detailed explanation, please check the Recurring tutorial.


Get Installment With Token

To get the list of Installment values, the request to be sent over /transactionServices/REST/v1/getInstallmentWithToken/{id} endpoint, where token has to be sent in place of {id} in the URL.


Sample Request


Sample Response


Delete the Stored Data

Sometimes it’s necessary to delete the stored registration. Therefore send the paymentType with value DL to /transactionServices/REST/v1/paywithtoken/{id} endpoint. Use the HTTP POST method against the registrationId.


Sample Request


Sample Response


The list of registration IDs

To get the list of registration IDs which registred against the customer.

The customer.customerId parameters has to be send if customer specific are details required with a POST request over HTTPS to the /transactionServices/REST/v1/getCardsAndAccounts .


Sample Request


Sample Response


Hashing Rule

is supporting MD5 Cryptographic Hash for the authenticity of payment request send to the server.


Below is the description of fields use for generating checksum:
  • memberId <Merchant ID as shared by >
  • secureKey <Secure Key that can be generated through 's dashboard>
  • merchantTransactionId <Unique transaction ID provided by merchant>
  • amount <Amount of transaction>
  • cardNumber/bic <Card number or bic through which you want to register>
  • amount <Amount of transactions>
  • customerId <Customer's ID generated against the card or account>
  • givenName <First name of a Merchant>
  • surname <Last name of a Merchant>
  • partner's secureKey <Partner secure key that can be generated through 's dashboard >
  • merchant's secureKey <Merchant secure key that can be generated through 's dashboard >
  • registrationId <Generated after Card Registration>

How to generate Checksum?

A checksum has to be calculated with following combination & need to be send along with the authentication parameters in each server-to-server request:

Store the data during a payment:
<memberId>|<secureKey>|<merchantTransactionId>|<amount>

Store the data as stand-alone:
<memberId>|<secureKey>|<cardNumber>/<bic>

Using the stored payment data:
<memberId>|<secureKey>|<registrationId>|<amount>

Deleting the stored payment data:
<memberId>|<secureKey>|<registrationId>

Customer registration by Merchant:
<merchantId>|<Merchant's secureKey>|<givenName>|<surname>|<email>

Customer registration by Partner:
<partnerId>|<Partner's secureKey>|<givenName>|<surname>|<email>

Getting list of cards and accounts by Merchant:
<merchantId>|<Merchant's secureKey>

Getting list of cards and accounts by Partner:
<partnerId>|<Partner's secureKey>

Getting list of Installment with Token:
<memberid>|<secureKey>|<registrationId>

  The Secure key varies, If the request is come from Partner then it must contain the Partner's secure key otherwise it will consider the Merchant's key.

Sample Code