's Tutorials



80%

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.

Data storing during a payment:

While sending a POST request to the /api/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 /api/REST/v1/registrations endpoint. What means that you directly receive a registration object in the ID field.

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.

Delete the Stored Data

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

Sample Request

Sample Response

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

The list of registration IDs

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

The customerId has to be send with a POST request over HTTPS to the /api/REST/v1/getCardsAndAccounts endpoint.

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 >

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>|<paymentBrand>

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>|<customerId>|<Merchant's secureKey>

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

  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