3D Flow
In a 3D workflow the account holder has to verify the payment. Once the account holder verifies the payment he/she is redirected back to the merchantRedirectUrl. The merchant then 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.
Workflow
1. Send a 3D Payment
After you send the request parameters server-to-server you receive the redirected information with all the parameters for ACS check.
2. Redirect the customer
Redirect the consumer to the ACS page with provided parameters.
3. Get the payment status
Now you can check if the payment was successful.
1. Send a 3D 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.
<memberId>|<secureKey>|<paymentId>
Standard Notification/ Callback
Checksum has to be calculated with following combination.
<paymentId>|<merchantTransactionId>|<amount>|<short status of transaction>|<secret key>
Example :
77251|011E1D8A5C034|156.00|N|<merchant secret key>
Sample Code
Payment Modes and Brands
Below are the list of payment brands for asynchronous workflow which requires the payment data.