Order Status API
This is a Server-to-Server API that returns the status of the order along with other details in encrypted format.
Please ensure that you validate the amount and status of the order before fulfilling the order at your end.
For information on different order status and handling, refer here
Consists of two parts.
Username: API Key obtained from Juspay dashboard
Password: Empty string
Example:-
MUQ2QUZEQzhFQTY0OUU5QTIxQzNFNTQwNkFDMEZCOg==
Merchant ID provided by Juspay
Example:-
merchant-id
application/x-www-form-urlencoded
We recommend passing the customer_id as the x-routing-id. If the customer is checking out as a guest, you can pass an alternative ID that helps track the payment session lifecycle. For example, this could be an Order ID or Cart ID.
This ID is associated with the customer. It plays a key role in ensuring consistency and maintaining connections across different systems. If you fail to pass the same x-routing-id for the same customer in all related API calls, it could lead to issues with API functionality. Therefore, it’s crucial that you use the same x-routing-id for all requests tied to the same customer.
Example:- customer_1122
Order Id of the order for which you want to check the status
Example:- JP1636474794
You may include this query param set as true to receive the complete response as received from the payment gateway.
Unique ID generated by JusPay for the given order
OrderId provided in the request
Status of the order. For information on different order status and handling, refer here
Status ID is a numeric id corresponding to the status value
The order amount
Order creation timestamp in UTC
Example: 2021-11-09T16:19:55Z
The email Id of the customer provided during order creation
The phone number of the customer provided during order creation
The customer id provided during order creation
The merchant id provided by Juspay
The currency provided during order creation.
Default: INR
The return url provided during order creation
The product_id provided during order creation
The user defined fields passed during order creation. Empty in case not passed
Transaction ID for the payment attempt. Can be used as an identifier at PG end and will be present in reconciliation report. In case of Debit + ENach, it will be part of txn_list
The payment method type used for transaction. Possible values are CARD, NB, WALLET, UPI, CONSUMER_FINANCE
The payment method used for the transaction
Possible values THREE_DS, OTP, VIES
true if the order has been completely refunded
false for partial refunds or if the order doesn't have any refunds
Amount which has been refunded so far for the given order
The refund block with the details of refund initiated for the given order.
The unique request id provided during refund initiation
The status of the refund initiated. Initial status will always be PENDING
Example:- Values can be SUCCESS, FAILURE, PENDING, MANUAL_REVIEW
The flag denotes if the refund was initiated to gateway. The initial status is always false, as refunds are queued at juspay for a period of 15 minutes
The type of refund. Values can be STANDARD, INSTANT
The name of gateway from which amount is refunded
The refund id provided by the PG
The source of initiation
The reference id provided by PG, if not available then its mapped to unique request id.
The refund amount passed in the request
The timestamp of refund creation
The unique id generated by Juspay for a particular transaction. Can be used as an identifier in case of UPI transaction
The json object with the details of the transaction
This field details the amount charged to the payer, broken down into "BASE" and/or "ADD_ON" / "OFFER" / "SURCHARGE" / "TAX_ON_SURCHARGE" components (as applicable). Each component outlines the sequence and type of operations applied to the “BASE” amount.
Name of the component.
Example:- "BASE" and/or "ADD_ON" / "OFFER" / "SURCHARGE" / "TAX_ON_SURCHARGE"
Value or amount of the component.
Sequence number of the operation of the component
Example:- For the BASE component, sno will be 1, increasing per component.
"ADD" if component is to be added, "SUB" if component is to be subtracted.
Example:- "ADD" or "SUB"
This will be present only for custom add on amounts defined by the merchant, which must be added or subtracted from the order amount. Value will be the name assigned by you while creating the order with add_on_amount_rules.
The json object with the details receive from PG
The response code provided by the gateway
The bank reference number provided by the gateway
The transaction creation timestamp
Transaction Id from the underlying gateway
Auth code provided by the gateway for the transaction.
Transaction Id for the payment attempt
The response message provided by the gateway
The type of offer applied provided by the gateway( available only if offers are applied)
true if the offer is applied at the payment gateway. Else it will be false ( available only if offers are applied)
The discount amount provided by the gateway for the availed offer ( available only if offers are applied)
Gateway Id of the gateway used for performing this transactions (Refer here for mapping)
The gateway reference id used for the transaction
The json containing the details of the card used for the transaction
The expiry year of the card used for the transaction
A reference identifier for the card.
The expiry month of the card used for the transaction
true if card was saved to locker, else false
The name on card used for the transaction
Indicates the bank which issued the card
The last four digit of the card used
true if transaction was done via a saved card
false if transaction via new card/unsaved card
The unique identifier for the card
The first six digit of the card used for the transaction
Indicates if the card is either CREDIT or DEBIT
The provider of the card, can be VISA, RUPAY etc.
This will contain the authentication response which can be used to perform authorization directly. this will be available for 15 mins after user has completed the authentication.
Applicable for txn_type = AUTHENTICATION
{
"authentication": {
"eci": "",
"cavv": "",
"threeDSVersion": "",
"threeDSTransStatusReason": "",
"threeDSServerTransID": "",
"threeDSTransStatus": "",
"cavvAlgorithm": "",
"threeDSTransId": ""
}
}
Contains the json payload
contains the eci value
contains the cavv value
contains the threeDs version
contains the threeDs status reason
contains the threeDs Server Transaction ID
contains the threeDs transaction status
contains the cavv algorithm value
This block contains the authorization successful param which can be used to perform capture call. Applicable for txn_type: AUTHORIZATION, AUTHN_AUTHZ, CAPTURE, AUTHZ_CAPTURE
Auth Id Code to be used for performing capture
acquirer Bin details, if shared by PG
acquirer Mid details, if shared by PG
An array containing the details of individual transactions associated with the order. This is for Split payment flows
Example:- M-Ord_1484kmOH-1-1
Example:- NB
Example:- THREE_DS
Example:- NB_HDFC
Example:- false
Example:- 1
Example:- mozaPZxSa8dnGoe5Ubw
Example:- M-Ord_1484kmOH-1-1
Example:- Ord_1484kmOH
Example:- CHARGED
Example:- 1
Example:- 19
Example:- INR
Example:- PAYTM_V2
Example:- 2025-07-09T06:41:24Z
Example:- NET_BANKING
Example:- 01
Example:- 10100680908
Example:- 2025-07-09T06:41:42Z
Example:- 20250709211430000149678400718746052
Example:- Txn Success
Example:- M-Ord_1484kmOH-1-1
Example:- 19
Example:- CHARGED
Bad Request
Details of keys missing
Example:-
Mandatory fields are missing
Further Details of keys missing
error
access_denied
error
Internal server Error
API Latency Guideline
What is API Latency?
Time taken by the server to respond to the API request.
Average API Percentile Metrics and Recommended Timeout
TP50 (s): This means 50% of the requests have a latency less than or equal to this value. It represents the typical latency most users will experience.
TP90 (s): The latency at the 90th percentile. This indicates that 90% of the requests have a latency less than or equal to this value, with 10% experiencing higher latency.
TP99 (s): The latency at the 99th percentile. This indicates that 99% of the requests have a latency less than or equal to this value, with 1% experiencing higher latency.
TP99.9 (s): The latency at the 99.9th percentile. This is important for identifying edge cases, where 0.1% of the requests take significantly longer than the others.
TP99.99 (s): The latency at the 99.99th percentile. This captures extremely rare cases, where just 0.01% of the requests take longer than this time. Monitoring this helps in identifying and addressing the rarest and most severe performance issues.
|
Transaction Percentile
|
Latency (ms)
|
|---|---|
TP50 (ms)
| 0.0198
|
TP90 (ms)
| 55.71
|
TP99 (ms)
| 351.85
|
TP99.9 (ms)
| 594.42
|
Recommended Timeout
| 1000
|
The recommended timeouts are based on TP99.9 data, though edge cases (0.01% of requests) may still exceed these limits and are captured in the TP99.99 data as shown below.
|
Transaction Percentile
|
Latency (ms)
|
|---|---|
TP99.99 (ms)
| 1431.42
|
Recommended Timeout
| 2000
|