Asynchronous


In an asynchronous workflow the account holder has to verify the payment. Once the account holder verifies the account he/she is redirected back to the merchantRedirectUrl. The merchant than can query the status of payment.

The initial request must contain all the required information:

  • - authentication credentials
  • - mode, brand , type and amount of transaction
  • - merchantRedirectUrl

You can perform the following types of initial payments using our Asynchronous Workflow REST API.


Preauthorization (PA):

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

The paymentType for this request will be PA.

You can also place a capture transaction request against a successful PA using our Backoffice APIs.


Debit (DB):

With the DB request a successfully authorized transaction gets captured immediately.

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

The paymentType for this request will be DB.



In our API Specifications you can find a full list of parameters that can be sent in the initial request.


   Merchant needs to set Authentication token in header while posting request. To generate authentication token, please refer Auth token API.

Workflow


1. Send an Initial Payment

After you send the request parameters server-to-server you receive the redirected information.

2. Redirect the customer

Redirect the consumer to the checkout page.

3. Get the payment status

Now you can check if the payment was successful.


1. Send an Initial Payment

To start the process, the merchant has to send a server-to-server initial payment request. Here merchantRedirectUrl has to be url-encoded.


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 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 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:
<memberId>|<secureKey>|<merchantTransactionId>|<amount>


Sample Code


2. Redirect the Customer

The account holder has to be redirected to redirect.url received in the initial payment response. If any parameters are present in the initial payment response than they should be POST in the redirect. If not, it’s enough to forward it straight to the redirect.url.

Once the payment has been processed, the customer is redirected to your merchantRedirectUrl along with a POST parameter resourcePath.


Sample Request


Sample response


3. Get Payment Status

To get the status of the payment you have to use a GET request. The request goes to the baseUrl + resourcePath and includes the authentication parameters.

resourcePath example:

resourcePath=/transactionServices/REST/v1/payments/{id}

Sample Request


Sample Response


Hashing Rule for Get Status

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>
  • paymentId <Id of previous 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:
<memberId>|<secureKey>|<paymentId>


Sample Code


Payment Modes and Brands

Below are the list of payment brands for asynchronous workflow which requires the payment data.

Show all modes & brands

Copyright © . All Rights Reserved