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.
Registering the payment data
You have two opportunities to create a token.
- Store the data during a payment
- Store the data as stand-alone
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>