Integration



80%

Recurring


In order to perform recurring payments, you need to add the parameter recurringType to the payment request.

There are two possible workflows for recurring:


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

Initial Payment with Transaction:

For this step it is important to know that the customer is present. To authenticate the customer, you should use parameters like card.cvv for card payments.

The initial payment should contain the parameter recurringType with the value INITIAL.

recurringType=INITIAL

In both, synchronous & asynchronous workflows, you have the option to add the parameter recurringType to the initial payments request.

The request has to be sent to our REST endpoint i.e. /transactionServices/REST/v1/payments using POST method

Sample Request

Sample Response

Initial Recurring Payments using the stored payment data:

The second option is used 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.

To mark this as a first transaction, you can add the parameter recurringType=INITIAL in the same way.

The Tokenization tutorial provides you with further information about options.

Sample Request

Sample Response

Repeat recurring payment with registrationId

For a payment request you have to use the parameter recurringType with the value REPEATED. And also here the payment system needs parameters like card.cvv or the 3D authentication.

recurringType=REPEATED

Sample Request

Sample Response

Repeat recurring payment with payment ID

After sending the first payment request, the user is not present in this case. That means that parameters like card.cvv or the 3D authentication are not in need. To show the system that this is a repeated recurring payment you need the parameter recurringType with the value REPEATED.

Sample Request

Sample Response

Hashing Rule

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


Below are the description of fields used 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 transactions>
  • registrationId <ID returned after registering the card/account details>
  • paymentId <ID returned after successful transaction>

How to generate Checksum?

Checksum has to be calculated with following combination & needs to be send along with the authentication parameters in each server-to-server request:

The initial payment request:
<memberId>|<secureKey>|<merchantTransactionId>|<amount>

The initial & subsequent payment request with registrationId:
<memberId>|<secureKey>|<registrationId>|<amount>

Subsequent payment requests with paymentId:
<memberId>|<secureKey>|<paymentId>|<amount>

Sample Code