Transaction Status
There are 2 ways to fetch payment status: -
1. Order Status Function: SmartGateway provides a server-to-server mechanism of verifying the Order Status.
2. Webhooks: After the completion of every payment/refund, SmartGateway will provide direct notification to your server regarding the event. These are called Webhooks. You must configure a valid HTTPS endpoint that is reachable from our servers to consume these notifications. Our servers will push data using HTTP POST calls to your endpoint. Click for Detailed Webhook Specifications
Q: Why should I use the Order Status Function?
As best practices, we recommend to use Order Status function for two reasons:
Reliability: While our webhooks are delivered instantly, it also depends on multiple other stakeholders in the payments ecosystem delivering Webhooks in a timely manner to SmartGateway Servers (Bank, Payment aggregators etc.). Hence, for business critical events such as communicating payment status to your customers, it is recommended to use the Order status function.
Fraud prevention: Under rare scenarios, it may be possible that fraudulent users try to tamper transaction processing by exploiting payment offers or tamper transaction amounts during various stages of a transaction. Such incidents could potentially lead to financial loss. Hence, the Order Status function is recommended as a secure channel to re-verify the Order ID and Actual Amount before fulfilling the product/service to your customers.
Best Practices
The following figure is a workflow of how you can handle the order status:
Step 1 - User redirected to your App / Website: After completion of a payment session the user will be automatically redirected to your app / website
Step 2 - Display Order Confirmation Page: From your server, use the Order Status function to verify the status of payment. Please ensure that the order ID and amount transaction are verified. If the order has reached the terminal status, please display the order confirmation page to your customer
Step 3 - Managing Webhooks: Asynchronously your server shall listen to the Webhooks events posted by SmartGateway Servers. Please refer here for Webhook specifications
Step 4 - Handling Transaction Status scenarios: Handle the transaction status scenarios (received via Webhooks/ Order Status) as recommended below
|
Status ID
|
Status
|
Description
|
Actionables
|
|---|---|---|---|
10
| NEW
| Newly created order. This is the status if transaction is not triggered for an order
| N/A
|
23
| PENDING_VBV
| Authentication is in progress
| This is a non-terminal transaction status. Show pending screen to your customers and in background keep polling order-status Function till you get Charged or Failed; or till the time your order fulfilment window (a specified duration post which payments will not be accepted against the order) is active.
|
21
| CHARGED
| Successful transaction
| Display order confirmation page to the user and fulfill the order.
|
25
| AUTHORIZED
| Pre-Auth Transaction. Used only for Auth&Capture Flows
| Call Capture API post order fulfilment.
|
22
| JUSPAY_DECLINED
| The transaction failed due to failure of generation of ALT_ID in case of CARD Payment Mode.
| Display failure message and ask the user to retry
|
26
| AUTHENTICATION_FAILED
| User did not complete authentication
| Display transaction failure status to the user along with the failure reason provided in the order status function response. Allow user to retry payment.
|
27
| AUTHORIZATION_FAILED
| User completed authentication, but the bank refused the transaction.
| Display transaction failure status to the user along with the failure reason provided in the order status function response. Allow user to retry payment.
|
28
| AUTHORIZING
| Transaction status is pending from bank
| This is a non-terminal transaction status. Show pending screen to your customers and in background keep polling order-status function till you get Charged or Failed; or till the time your order fulfilment window (a specified duration post which payments will not be accepted against the order) is active.
|
31
| VOIDED
| Void Transaction. Used only for Auth&Capture Flows
| Call Void API in order to unblock the amount
|
32
| VOID_INITIATED
| Void pending for the pre-authorized transaction. Used only for Auth&Capture Flows
| N/A
|
35
| VOID_FAILED
| Void failed for the Pre-Authorized transaction. Used only for Auth&Capture Flows
| N/A
|
20
| STARTED
| Transaction is pending. SmarteGateway system isn't able to find a gateway to process a transaction
| This scenario is an integration error. Reach out to us with order ID details for clarification.
|
36
| AUTO_REFUNDED
| Transaction is automatically refunded
| Display the refund status to the user and in background keep polling order-status function till you get Success or Failure.
|
33
| CAPTURE_INITIATED
| Capture pending for the pre-authorized transaction.Used only for Auth&Capture Flows
| N/A
|
34
| CAPTURE_FAILED
| Capture failed for the pre-authorized transaction.Used only for Auth&Capture Flows
| N/A
|
Handling delayed status updates
Occasionally it may be possible that the payment status does not get updated immediately due to delays across payment processing systems (of Banks and Aggregators). In such cases, it is recommended to continuously use the Order Status function to poll and verify status.
Your business policy might have a predefined order timeouts (a specified duration post which payments will not be accepted against the order). This may range from few minutes to a few days depending on the type of product/ service offered by your business
Before declaring an order as timed-out, please use order status function to check the final status of the order. In case the order has reached terminal status, please fulfill the order
In case the order status has not reached a terminal status, assure your customers that the “Order fulfillment has failed, and any amount deducted will be automatically refunded”
In case you want to process refund for delayed success orders, you can either do a Manual Refund or Auto-Refund. Refer here for more details
Q: Is there a recommended order status polling logic?
In order to optimise the number of order status function calls, post payment completion you should call the function at below time intervals upto your order fulfilment window (a specified duration post which payments will not be accepted against the order). Polling should be stopped once terminal status is received for the order
This is only a recommended logic and can be customised as per your business use case
|
Time post payment redirection
|
Polling Logic
|
|---|---|
t=0 to t=90 secs
| Poll every 15 seconds
|
t>90 secs and t<=2 minutes
| Poll at 2nd Minute
|
t>2 minutes and t<=5 minutes
| Poll at 5th Minute
|
t>5 minutes and t<=10 minutes
| Poll at 10th Minute
|
t>10 minutes and t<=20 minutes
| Poll at 20th Minute
|
t>20 minutes and t<=1 hour
| Poll at 1 hour
|
t>1 hours and t<=24 hours
| Poll at 2nd hour, 6th hour, 12th hour and 24th hours
|