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.
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.
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
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.
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
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
INITIALfor an initial payment
- Use the value
REPEATEDfor 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
/transactionServices/REST/v1/registrations endpoint. Use the HTTP
POST method against the
The list of registration IDs
To get the list of registration IDs which registred against the customer.
customerId has to be send with a POST request over HTTPS to the
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:
Store the data as stand-alone:
Deleting the stored payment data:
Customer registration by Merchant:
Customer registration by Partner:
Getting list of cards and accounts by Merchant:
Getting list of cards and accounts by Partner: