You can process the result code by identifying the result.code, action, and status.

Begin

It is suggested to identify if the response body contains an action object first.

If the action object exists, it means the transaction is under processing, and you have to use this object to process a future action to complete the transaction.

Identification

Processing

A processing payment has the following characteristics:

result.code = S0000
payment.status = Authorised, Pending, Verifying, Verified

A processing refund has the following characteristics:

result.code = S0000
refund.status = Received

A processing cancellation has the following characteristics:

result.code = S0000
cancel.status = Received

You need to conduct the corresponding request to a processing payment following the action object or query or cancel the transaction.

If action.type is redirectUser, you need to redirect the customer to the action.redirectData.url according to the specified HTTP method to complete the subsequent operation. The payment result will be notified either in direct response or an indirect notification.
If action.type is redirectInIframe, you need to perform the same action as the one of redirectUser, but in an iframe. The suggestion iframe size is 200*200px.
If action.type is presentQRCode, you need to check the action.qrData and show the QR code to the customer.
If action.type is invokeWallet, you need to use action.walletData.paymentString to invoke the SDK of the corresponding payment method and enable the customer to complete the payment within the mobile App.
If action.type is threeDSRedirect, you need to redirect the customer to the action.threeDSData.url according to the specified HTTP method to complete the subsequent operation. After receiving the payment result either in direct response or an indirect notification, you can send another request with PUT method to complete the payment.
If action.type is threeDSIdentify, you need to send the request in frontend page and set up the returnURL to receive the result. It is suggested to include the order number in the returnURL. Then you can send another request with PUT method to complete the payment.
If action.type is threeDSChallenge, you need to create an iframe in the current page, submit the creq data, and receive the cres in the returnURL. Then you can send another request with PUT method to complete the payment.
If action.type is inputMobilePhone, you need to send authentication.securePlus.mobilePhone in another request with PUT method and proceed inputSMSCode later. This only occurs in the integration with the UPI payment method.
If action.type is inputSMSCode, you need to send the mobile verification code in another request with PUT method to complete the payment. This only occurs in the integration with the UPI payment method.
If action.type is resendSMSCode, you need to resend the mobile verification code in another request with PUT method to complete the payment. This only occurs in the integration with the UPI payment method.

If you receive the action object with no processable value, you can wait for the notification or query the transaction by using GET method. The query interval is suggested to be no shorter than 6 seconds, with a maximum attempt of 10.

Success

A successful payment has the following characteristics:

result.code = S0000
payment.status = Captured

A successful refund has the following characteristics:

result.code = S0000
refund.status = Success

A successful cancellation has the following characteristics:

result.code = S0000
cancel.status = Success

Fail

If the result.code is not S0000, it means the transaction fails, with a status of Failed.

Query

The result.code of the query response means the processing result of the query request, not the transaction result of the query transaction.

The transaction result shall follow the status of the object of the corresponding transaction type.

If the query transaction is a refund or a cancellation transaction, the main transaction status includes

Success
Received
Failed

If the query transaction is a payment, the possible transaction status includes:

Verifying: used for card transaction authentication, which means authentication is in processing
Verified: used for authentication-only transactions, which means the authentication is successfully completed
Pending: used for e-wallet transactions, which means the transaction is waiting to pay; or for card transactions, which means authorization is in processing (the merchant can submit a query or cancel the transaction)
Authorised: used for card transactions, which means the transaction authorization is successfully completed and pending for Capture (merchant can cancel the transaction)
Cancelling: meaning EVONET received and processed the cancellation, but pending for PSP confirmation
Cancelled: meaning EVONET received and processed the cancellation and also completed the cancellation with PSP successfully
Capturing: used for card transactions, which means the capture is in processing
Captured: used for card transactions, which means transaction authorization and capture are successfully completed; or for e-wallet transactions, which means the transaction is successfully completed
Refunding: meaning the refund for this transaction is in processing
Refunded: meaning the transaction is refunded in full successfully
Partial Refunded: meaning the transaction is refunded in partial successfully
Failed: used for both card and e-wallet transactions, means the transaction fails

📘
If the query status of the object of the corresponding transaction type is Failed, you can check the failure reason through the failureCode and failureReason in the object of the corresponding transaction type.

Notification

You will receive an asynchronous notification if the transaction is not confirmed immediately.

You can use eventCode to identify the notification type. The eventCode includes:

PaymentMethod
Payment
Capture
Cancel
Refund

Follow the status of the object of the corresponding transaction type to get the transaction status. If the query status of the object of the corresponding transaction type is Failed, you can check the failure reason through the failureCode and failureReason in the object of the corresponding transaction type.

No Response

If you don't receive a response from EVONET, it is suggested to set up a maximum timeout of 45 seconds and query the transaction after the timeout.

Recommendation Handling

In some cases, you will receive a special result.code which indicates the transaction cannot be conducted successfully, usually taking place in card transactions. Here is some summary of the recommendation to handle these special result.code.

P0005/I0014

Invalid card number.

Recommended solution: Check the card number to see if it is correct or not.

P0006

No such issuer.

Recommended solution: Check the card number to see if it is correct or not.

I0054

Expired card.

Recommended solution: Check the card expiry date and ensure the entering expiry date is correct.

I00N7

Decline for CVV2 failure.

Recommended solution: Check the card verification code and ensure the entering verification code is correct.

P0012

Insufficient funds.

Recommended solution: Top up the card or change the payment card and retry the transaction.

I0051

Not sufficient funds/over credit limit.

Recommended solution: Top up the card or change the payment card and retry the transaction.

P0008

Re-enter transaction.

Recommended solution: Retry the transaction.

I001A

Additional customer authentication required.

Recommended solution: Retry the transaction with 3DS authentication.

I0059

Suspected fraud.

Recommended solution: Change the payment card and retry the transaction.

P0016

Exceeds amount limit.

Recommended solution: Change the payment card or change the card limitation on the payment amount and retry the transaction.

I0062

Restricted card.

Recommended solution: Change the payment card and retry the transaction.

The following result.code indicates the transaction is refused by the issuing bank. It is suggested to ask the customer to change the payment card and retry.

🚧
It is suggested to pay attention to those customers who always have these kinds of result.code.

I0004

Pick-up

I0007

Pick up card, special condition

P0003

Invalid transaction

I0041

Lost card

I0043

Stolen card

I0046

Closed account

I0057

Transaction not permitted to cardholder

P0035

Stop payment order

P0036

Revocation of authorization order

P0037

Revocation of all authorizations order

Result Code Handling

Begin

Identification

Query

📘
If the query status of the object of the corresponding transaction type is Failed, you can check the failure reason through the failureCode and failureReason in the object of the corresponding transaction type.

Notification

No Response

Recommendation Handling

🚧
It is suggested to pay attention to those customers who always have these kinds of result.code.

Begin

Identification

Query

📘If the query status of the object of the corresponding transaction type is Failed, you can check the failure reason through the failureCode and failureReason in the object of the corresponding transaction type.

Notification

No Response

Recommendation Handling

🚧It is suggested to pay attention to those customers who always have these kinds of result.code.

📘
If the query status of the object of the corresponding transaction type is Failed, you can check the failure reason through the failureCode and failureReason in the object of the corresponding transaction type.

🚧
It is suggested to pay attention to those customers who always have these kinds of result.code.