Test Order Creation

Available in🇮🇳 India

Every payment on Razorpay starts with an order created on your server. This page holds every order scenario: creating orders, the order lifecycle, idempotent retries and request validation. Method pages link here instead of repeating them. Start with the overview for test keys and webhook setup.

1. Test Mode Coverage

Test your order integration with test keys. There are no special test credentials: the outcome depends on the request you send. Start from the request in the test kit, then change one field at a time using the triggers in Simulate Failures.

Area	What you can test	Test mode	How it works in test mode
Create and fetch	Create an order, fetch it and fetch its payments	Available	Test orders exist only in test mode. Use the Fetch an Order API (`GET /v1/orders/:id`) with your test keys.
Request validation	Every `input_validation_failed` and `extra_field_sent` error	Available	Same validation as live mode. Trigger each error by sending the bad input in its Trigger column in Simulate Failures.
Maximum amount	Amount above your account’s limit	Available	Same check as live mode, using your account settings for test mode: the higher of your maximum transaction amount and your international maximum (₹5,00,000 when no international maximum is set). An amount in another currency is converted to your account currency first.
Currencies	Orders in your account currency, and others if international payments are enabled	Available	Same rule as live mode. Activate international payments on the Dashboard (Account & Settings → International payments); this updates your account for both live and test mode. See supported currencies.
Idempotency	`unique_receipt`	Available	See ORD-05.
Lifecycle	`created` → `attempted` → `paid`, the `order.paid` webhook, paying a paid order	Available	Use a payment method’s test triggers to make payments fail or succeed.
Partial payments	`partial_payment`, `first_payment_min_amount`	Available	—
Server errors (5xx)	Retry with exponential backoff	Available in live mode only	Cannot be triggered in test mode.
Account activation and IP whitelisting	Authentication failed (account not activated), Access Denied (IP not whitelisted)	Available in live mode only	Do not apply to test keys.

2. Test Kit

There are no special test credentials: the outcome depends on the request you send. Start from this valid request, then change one field at a time using the triggers in Simulate Failures.

curl -u [YOUR_TEST_KEY_ID]:[YOUR_TEST_KEY_SECRET] \
-X POST https://api.razorpay.com/v1/orders \
-H "content-type: application/json" \
-d '{
  "amount": 5000,
  "currency": "INR",
  "receipt": "receipt#1",
  "unique_receipt": false,
  "notes": { "key1": "value3" },
  "partial_payment": false,
  "customer_id": "cust_4xbQrmEoA5WJ01",
  "description": "Order for receipt#1"
}'

Parameter	Required	Rules to test
`amount`	Yes	Whole number in the smallest sub-unit; not negative; at least `100` (₹1.00) for INR; at most your account’s maximum
`currency`	Yes	Three-letter supported ISO code; your account currency unless international is enabled
`receipt`	No	Up to 56 characters; no emoji; unique only with `unique_receipt: true`
`unique_receipt`	No	`true` / `false`; needs `receipt`
`notes`	No	JSON object up to 20 KB; no emoji; no `<script>`
`partial_payment`, `first_payment_min_amount`	No	Boolean; whole number ≥ 0
`customer_id`	No	`cust_` + 14 characters, created on your account
`description`	No	Up to 255 characters

3. Scenarios to Test Your Integration

25 scenarios · 21 available in test mode.

Scenario ID	Type	Scenario	Trigger	Steps to follow	Test mode
ORD-01	Create	Create an order	`amount: 100`, `currency: "INR"`, a `receipt`	`POST /v1/orders` with test keys. Confirm `status: created`, `amount_due = amount`, `attempts: 0`. Store `id` against your own receipt or cart.	Supported
ORD-02	Lifecycle	Order moves to `paid` after a payment	ORD-01 + a method success trigger (for example, UPI `amount: 100`)	Create an order. Pay it with a method’s success trigger. Confirm `order.paid`, `status: paid`, `amount_paid = amount`.	Supported
ORD-03	Lifecycle	Failed attempt, then a successful retry	A method failure trigger, then a success trigger	Create an order and fail a payment on it. Confirm `status: attempted`, `attempts: 1`. Retry and confirm the order ends `paid`.	Supported
ORD-04	Signature	Verify the payment signature against the order	Callback from ORD-02	Compute HMAC-SHA256 of order_id``razorpay_payment_id with your key secret. Confirm it matches `razorpay_signature`; reject a tampered value.	Supported
ORD-05	Idempotency	Retry create without a duplicate order	`unique_receipt: true` + the same `receipt` twice	Create an order with `unique_receipt: true`. Send the same request again. Confirm you get the same order ID back, not a second order.	Supported
ORD-06	Fetch	Fetch the order and its payments	Order from ORD-02	`GET /v1/orders/:id` and `GET /v1/orders/:id/payments`. Confirm status and payments match the webhooks.	Supported
ORD-07	Lifecycle	Pay an order that is already paid	Order from ORD-02 + another payment	Start a second payment on the paid order. Confirm `order_already_paid` and that you create a new order instead.	Supported
ORD-08	Validation	Amount errors	`amount` missing, `100.5`, `"100.0"`, `-100`, `0`, `99`	Send each bad `amount`. Confirm HTTP 400 and `input_validation_failed`. Confirm your code logs it and does not show it to the payer as a payment failure.	Supported
ORD-09	Validation	Currency errors	`currency` missing, `"IN"`, `"ABC"`, a non-account currency	Send each bad `currency`. Confirm HTTP 400 with the matching description.	Supported
ORD-10	Validation	Receipt, notes and description limits	57-char `receipt`, emoji, `notes` over 20 KB, `<script>` in `notes`, 256-char `description`	Send each oversized or invalid field. Confirm HTTP 400. Sanitise these fields before you call the API.	Supported
ORD-11	Validation	Malformed request	Invalid JSON, wrong types (`"currency": 1`, `"notes": "text"`, `"partial_payment": "yes"`)	Send each malformed body. Confirm HTTP 400.	Supported
ORD-12	Auth	Missing or wrong API keys	No Basic Auth; wrong key secret; live key in test mode	Call without auth and with a wrong secret. Confirm HTTP 401 and no order is created.	Supported
ORD-13	Errors	Server error and retry	—	On 5xx, retry with exponential back-off. Use `unique_receipt` so a retry cannot create a duplicate order.	Supported in live mode only
ORD-14	Validation	Customer ID errors	`"customer_id": "cust_123"`; a 19-character ID that does not exist	Send each bad `customer_id`. Confirm HTTP 400.	Supported
ORD-15	Validation	Parameter not enabled for your account	e.g. transfers without Route	Send a feature-gated parameter. Confirm `extra_field_sent`.	Supported
ORD-16	Partial payments	Pay an order in parts	`partial_payment: true`, `first_payment_min_amount`	Create a partial-payment order. Pay less than the full amount, then the rest. Confirm `amount_paid` / `amount_due` after each payment and `order.paid` at the end.	Supported
ORD-17	Account	Account not activated or IP not whitelisted	—	Live-mode conditions: Authentication failed (account not activated) and Access Denied (IP not whitelisted). Check before go-live.	Supported in live mode only
ORD-18	Mandate	Create a mandate authorisation order	`method: "upi"` + token object	Create an order with a token object (`max_amount`, `frequency`). Used to register a UPI Autopay mandate.	Supported
ORD-19	Mandate	Mandate order errors	Bad token object	Send invalid token fields. Confirm HTTP 400.	Supported
ORD-20	Card recurring	Card mandate authorisation order	`customer_id` + a token object for cards	Create the authorisation order for a card mandate. Confirm `status: created`.	Supported
ORD-21	Card recurring	Card mandate order errors	`token.first_payment_amount` set for cards; invalid `auth_type`; `max_amount: 0`; invalid `frequency`; `expire_at` in the past; token without `customer_id`	Send each bad request. Confirm the error below.	Supported
ORD-22	Debit	A new order per subsequent debit	A confirmed token	Create a fresh order for each recurring debit. Confirm each maps to one debit.	Supported
ORD-23	Debit	Decoupled debit order	Order with a `notification` object	Create a debit order with the `notification` object to send a pre-debit notification first.	Supported
ORD-24	Validation	INR only for UPI	`currency` other than `INR`	Confirm UPI orders are rejected for non-INR currencies.	Supported
ORD-25	Fetch	Webhook is late: fetch before you act	Order from ORD-02, with your `order.paid` handler paused	Pay an order but do not process the `order.paid` webhook. Call `GET /v1/orders/:id` and `GET /v1/orders/:id/payments`. Confirm `status: paid` and the captured payment, and fulfil from the fetch result. Resume the handler and confirm the late webhook does not fulfil the order a second time.	Supported

4. Scenario Details

ORD-01 Create an order

Before you start Test keys. How to test Send the request in the test kit with amount: 100. Expected result HTTP 200 with id (order_…), status: created, amount_due = amount, amount_paid: 0, attempts: 0. Webhooks None. Orders fire order.paid only when paid. Your integration should Create the order on your server, store id against your own receipt, and pass only the order_id to the client.

ORD-02 · ORD-03 Order lifecycle

Before you start An order from ORD-01 and a method page’s test triggers. How to test

Fail one payment on the order using a method’s failure trigger.
Fetch the order: status: attempted, attempts: 1.
Pay successfully using a method’s success trigger.
Fetch the order: status: paid, amount_paid = amount.

Expected result created → attempted → paid. The order stays paid even after a refund. Webhooks payment.failed, then payment.captured and order.paid. Your integration should Fulfil on order.paid or payment.captured, never on the checkout callback alone. Watch out Reuse the order ID when the same cart is retried after a payment failure. Order IDs should be unique for each checkout session: create a new order only for a new checkout session, such as a new cart.

ORD-05 Idempotent create with `unique_receipt`

Before you start Test keys. How to test Send unique_receipt: true with receipt: "r-123" twice. Expected result Both calls return the same order ID. Your integration should Use unique_receipt whenever you might retry a create (timeouts, 5xx), so a retry cannot create two orders for one cart. How receipt uniqueness works

Razorpay checks that receipt is unique only when you send unique_receipt: true, or when Razorpay has turned on receipt uniqueness for your account.
With unique_receipt: true, a receipt you already used returns the existing order with HTTP 200. Retrying a create is safe.
If uniqueness is on for your account and you do not send unique_receipt: true, a receipt you already used fails with HTTP 400 Order receipt should be unique., and metadata.order_id holds the existing order’s ID.
Only orders created while uniqueness was on are checked, and only for 180 days. A receipt used on an order created without it does not count. Test mode and live mode are checked separately.
Two creates with the same receipt at the same moment are handled one at a time. The second can fail with Another request in progress for the same process.; retry it and you get the existing order back.

ORD-07 Pay an order that is already paid

Before you start A paid order from ORD-02. How to test Start another payment with the same order_id. Expected result The payment is declined with order_already_paid: “Your payment has been declined as the order is already paid. Please initiate the payment with a new order.” Your integration should Check the order status before showing checkout again. Create a new order for a new purchase.

ORD-18 · ORD-19 UPI Autopay authorisation order (registration)

Before you start A customer (POST /v1/customers). How to test Create the order with amount: 100, currency: "INR", method: "upi", customer_id and token: {max_amount, frequency, expire_at}. Then send each bad token below. Expected result The valid order is created. Each bad request fails with the error below. Your integration should Validate max_amount against your MCC limit and keep frequency to how you really bill before calling the API. Errors to test

Trigger	`error.reason`	`error.source`	`error.step`	`error.description`
Leave out `token.max_amount`	`input_validation_failed`	customer	—	the max_amount field is mandatory for UPI mandate creation
`token.max_amount` below ₹1	`input_validation_failed`	business	payment_initiation	Max amount for UPI recurring payment cannot be less than ₹1.00
`token.max_amount` above your MCC limit	`input_validation_failed`	customer	—	max amount for UPI recurring payment for this merchant category code cannot be greater than ₹N.00
`token.frequency` set to a value outside the UPI frequency enum	`input_validation_failed`	business	payment_initiation	The selected frequency is invalid.
`token.expire_at` in the past	`input_validation_failed`	business	payment_initiation	expire_at cannot be less than current time
`token.expire_at` 31 years out	`input_validation_failed`	customer	—	expire_at cannot be more than 30 years for upi
`recurring_type` without `recurring_value`	`input_validation_failed`	customer	—	recurring_type or recurring_value is missing, send both the values for successful registration
Mismatched `recurring_type` / `recurring_value`	`input_validation_failed`	customer	—	recurring type and recurring value mismatch
`token` sent without `customer_id`	`input_validation_failed`	business	payment_initiation	customer_id: cannot be blank.
Order `amount` above `token.max_amount`	`input_validation_failed`	business	payment_initiation	The order amount cannot be greater than the mandate max amount.
`token.recurring_type: "bogus"`	`input_validation_failed`	business	payment_initiation	invalid recurring type
`token.recurring_value` outside the range for the frequency (for example, 8 on weekly)	`input_validation_failed`	business	payment_initiation	recurring value should be between 1 and 7 for weekly frequency
`token.start_at` in the past	`input_validation_failed`	business	payment_initiation	end time must be after start time

ORD-20 · ORD-21 Card mandate authorisation order

Before you start A customer. How to test Create the authorisation order for a card mandate with customer_id and a token object, then send each bad request below. Expected result The valid order is created. Each bad request fails with the error below. Errors to test

Trigger	`error.reason`	`error.source`	`error.step`	`error.description`
`token.first_payment_amount` set with `method: "card"`	`input_validation_failed`	business	payment_initiation	token.first_payment_amount should be “null” for method = “card”
`token.auth_type: "xyz"`	`input_validation_failed`	business	payment_initiation	The selected auth type is invalid.
`token.max_amount: 0`	`input_validation_failed`	business	payment_initiation	The max amount should be greater than zero.
`token.frequency: "as_presen"`	`input_validation_failed`	business	payment_initiation	The selected frequency is invalid.
`token.expire_at` in the past	`input_validation_failed`	business	payment_initiation	expire_at cannot be less than current time
`token` sent without `customer_id`	`input_validation_failed`	business	payment_initiation	Customer Id is required with token field
A non-card token on a card order	`input_validation_failed`	business	payment_initiation	Not a card mandate token

ORD-22 · ORD-23 Debit orders (subsequent debits)

Before you start A confirmed token. How to test

Create a new order for each debit, with its own receipt.
Reuse a paid debit order.
Debit twice in one billing cycle.
UPI decoupled: add notification: {token_id, payment_after} and try to debit early, or above the notified amount.

Expected result Each new order debits once. The other attempts fail with the errors below. Your integration should Create one order per charge. Check the token is confirmed before creating the order. Errors to test

Trigger	`error.reason`	`error.source`	`error.step`	`error.description`
Reuse a paid debit order	`order_already_paid`	business	payment_initiation	Your payment has been declined as the order is already paid. Please initiate the payment with a new order.
Second debit in the same cycle	`duplicate_request`	business	payment_response	This payment has already been processed for the current cycle. No further executions are permitted.
Debit on a token that isn’t confirmed	`token_not_eligible`	business	payment_initiation	Token is not confirmed for recurring payments
UPI decoupled: debit before `payment_after`	`invalid_request`	internal	payment_initiation	Debit can be attempted 25 hours after sending the pre-debit notification
UPI decoupled: debit above the notified amount	`pre_debit_notification_request_amount_validation_failed`	internal	payment_debit_request	Payment amount exceeds the maximum amount allowed.
Debit within 26 hours of mandate expiry	`input_validation_failed`	customer	—	You cannot initiate subsequent payments within 26 hours of expiration of the mandate

The 25-hour pre-debit-notification-to-debit window is enforced in test mode — it is a hardcoded NPCI rule, so a decoupled debit created inside the window is rejected. The 26-hour mandate-expiry rule is live-only.

5. Common Integration Gaps to Avoid

These are the mistakes that most often cause failed payments, missed debits or double charges after go-live.

Webhook and token updates

Gap	What goes wrong in production	What to do	Test with
Fulfilling on the checkout callback	The customer closes the page after paying; the callback never reaches you and a paid order looks unpaid.	Fulfil on `order.paid` or `payment.captured`. Map `order_id` to your own receipt so the webhook finds the right cart.	ORD-02
Amount set by the client	A tampered client changes the amount it sends you.	Create the order on your server from your own cart total; pass only the `order_id` to the client.	ORD-01
Partial payments treated as paid	You fulfil after the first part-payment.	Fulfil only when `amount_due` is `0` / `order.paid` fires.	ORD-16

Error handling and messaging to the payer

Gap	What goes wrong in production	What to do	Test with
Order errors shown to the payer	The customer sees “amount: must be no less than 100” and leaves.	Order errors are your request’s problem: log and alert on them, and show the payer a generic “try again”.	ORD-08
Retrying 4xx errors	The same bad request fails forever and fills your logs.	Fix 4xx requests; retry only 5xx, with back-off.	ORD-08, ORD-13
Matching on description text	A wording change breaks your error handling.	Branch on `reason` (and `field` when present).	ORD-08

Fetch API when webhooks are late

Gap	What goes wrong in production	What to do	Test with
Duplicate orders after a timeout	The create call times out, you retry, and the cart now has two orders.	Send `unique_receipt: true`, or fetch by receipt before creating again.	ORD-05
Order status assumed from the last attempt	A late success or a second attempt changes the order after you decided.	Fetch `GET /v1/orders/:id` and `/payments` before acting when a webhook is late.	ORD-06, ORD-25

6. Best integration practices

These apply to every Razorpay integration. “On this method” says what each one means here; “Test it” links to where it is tested once for every method.

Topic	What to know	On this method	Test it	Read more
Difference between order and payment	An order is what you want to collect. A payment is one attempt to pay it. One order can have many attempts but only one captured payment. Create the order on your server so the amount cannot be tampered with.	This page. Create one order per purchase on your server; each payment attempt is a payment on it.	BP-24, BP-25	Difference between order and payment
Order states	Orders move `created` → `attempted` → `paid`. An order stays `attempted` through failed attempts, and stays `paid` even after a refund. Handle Orders API errors (for example an invalid amount or currency) when you create the order.	Test every state with ORD-02 and ORD-03, and the error codes in Simulate Failures.	Payment states · Orders errors	Order states, Orders API error codes
Late authorisation	A payment with no bank response is marked `failed` after 10 minutes, but Razorpay keeps polling the bank for 3 days. If the bank confirms, the payment becomes `authorized` (under 0.5% of payments). Listen for `payment.authorized` and capture it, or let it auto-refund.	A late-authorised payment on an order that is already paid is auto-refunded.	BP-06	Late authorisation
Capture settings	Choose auto-capture or manual capture and set the timeouts. An authorised payment you do not capture in time is auto-refunded. You can set capture behaviour per order through the Orders API.	Capture behaviour can be set per order through the Orders API.	BP-14	Capture settings
Multiple payments on the same order	Once an order is `paid`, no more payments are accepted on it. While a payment on the order is `authorized`, a new attempt is not allowed. An attempt that authorises late on a paid order is auto-refunded.	Retry on the same order so a customer cannot pay twice.	BP-09 · BP-08	Multiple payments on the same order

7. Simulate Failures

To test request validation, send the valid request from the test kit and change one field at a time to an invalid value (see the rules column). Each invalid request returns HTTP 400 with an error object.

Branch your handling on error.reason and error.source, never on the description text.
Sanitise receipt, notes and description before you call the API.
Log validation errors — do not surface them to the payer as a payment failure.

How to read an error

reason tells you what went wrong. Build your error handling on it; it is stable.
description is a human-readable message. It can change, so do not match on its text in code.
source tells you who needs to act: business means your request needs fixing; internal means a problem at Razorpay, so retry.
step tells you where in the flow the error happened.
field, when present, names the request parameter that caused the error.
The HTTP status tells you whether to retry: 4xx means fix the request first (retrying the same request fails again); 5xx means retry with exponential backoff.

How to find and fix an error

Take the reason from the error response and find it in the tables below.
To reproduce it in test mode, send the input in the Trigger column with test keys.
Fix the field named in error.field, when present, and retry.

Errors available in test mode (34 triggers → 7 distinct `error.reason` values)

Send the input in the Trigger column with test keys. Every one fails before an order is created, so nothing reaches the payer: log it and fix the request. Retrying the same request fails again.

Trigger	`error.code`	`error.source`	`error.step`	`error.reason`	`error.description`
`"amount": 99` with `"currency": "INR"`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	amount: must be no less than 100. (HTTP 400)
A parameter your account does not support, e.g. transfers without Route	BAD_REQUEST_ERROR	business	payment_initiation	extra_field_sent	`<field>` is/are not required and should not be sent (HTTP 400)
Reuse a receipt already on your account	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	Order receipt should be unique. (HTTP 400)
`"amount": 100.5`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	The amount must be an integer. (HTTP 400)
`"currency": 1`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	expected string but provided `<value>` (HTTP 400)
Leave out `amount`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	amount: is required. (HTTP 400)
`"amount": -100`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	amount: must be no less than 0. (HTTP 400)
Leave out `currency`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	currency: cannot be blank. (HTTP 400)
An emoji in `notes`	BAD_REQUEST_ERROR	business	order_creation	input_validation_failed	The notes field should contain valid UTF-8 encoded characters. (HTTP 400)
`"currency": "IN"`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	currency: the length must be exactly 3. (HTTP 400)
`"amount": "100.0"`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	The amount must be a valid integer. (HTTP 400)
`"amount": ""`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	amount: cannot be blank. (HTTP 400)
A 19-character `customer_id` that does not exist	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	customer_id: The id provided does not exist. (HTTP 400)
A body that is not valid JSON	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	`<JSON parse error>` but provided `<value>` (HTTP 400)
Leave out `amount` and `currency`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	amount: is required; currency: cannot be blank. (HTTP 400)
A 57-character `receipt`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	receipt: the length must be no more than 56. (HTTP 400)
A currency other than your account currency, without international payments enabled	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	Order Currency is not supported (HTTP 400)
`"currency": "ABC"`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	currency: validation_failure: BAD_REQUEST_INVALID_CURRENCY. (HTTP 400)
`notes` larger than 20 KB	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	notes exceeded max size of 20KB (HTTP 400)
A `<script>` tag in `notes`	BAD_REQUEST_ERROR	business	order_creation	input_validation_failed	notes must be valid key-value pairs of strings (HTTP 400)
`"notes": "text"`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	Field should be of type list or map. (HTTP 400)
An emoji in `receipt`	BAD_REQUEST_ERROR	business	order_creation	input_validation_failed	The receipt field should contain valid UTF-8 encoded characters. (HTTP 400)
A 256-character `description`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	description: the length must be no more than 256. (HTTP 400)
`"amount": 0`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	amount: must be no less than 1. (HTTP 400)
`"partial_payment": "yes"`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	Boolean field must be either true or false. (HTTP 400)
`"customer_id": "cust_123"`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	customer_id: the length must be exactly 19. (HTTP 400)
Leave out `currency` and send `"method": "xyz"`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	currency: cannot be blank; method: must be a valid value. (HTTP 400)
`"amount": -1` and no `currency`	BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	amount: must be no less than 0; currency: cannot be blank. (HTTP 400)
An amount above your account’s maximum transaction amount	BAD_REQUEST_ERROR	business	order_creation	invalid_amount	Amount exceeds maximum amount allowed. (HTTP 400)
`"currency": "XYZ"`	BAD_REQUEST_ERROR	business	order_creation	invalid_currency	Currency is not supported (HTTP 400)
Call without HTTP Basic Auth	BAD_REQUEST_ERROR	business	order_creation	—	Please provide the Username or Password (HTTP 401)
Two parallel creates with the same receipt	BAD_REQUEST_ERROR	business	order_creation	—	Another request in progress for the same process. (HTTP 400)

Errors not available in test mode (15 rows → 8 distinct `error.reason` values)

These come from Razorpay’s side or from live-account conditions. On 5xx, retry with exponential back-off; with unique_receipt a retry will not create a duplicate order.

`error.code`	`error.source`	`error.step`	`error.reason`	`error.description`
BAD_REQUEST_ERROR	business	payment_initiation	input_validation_failed	Order receipt should be unique. (HTTP 500)
BAD_REQUEST_ERROR	business	order_creation	merchant_not_activated	Authentication failed (HTTP 401)
BAD_REQUEST_ERROR	business	order_creation	—	Access Denied (HTTP 400)
BAD_REQUEST_ERROR	business	order_creation	—	Passport validation failed (HTTP 401)
SERVER_ERROR	internal	payment_initiation	server_error	We are facing some trouble completing your request at the moment. Please try again shortly. (HTTP 502)
SERVER_ERROR	internal	payment_initiation	server_error	We are facing some trouble completing your request at the moment. Please try again shortly. (HTTP 500)
SERVER_ERROR	internal	NA	server_error	We are facing some trouble completing your request at the moment. Please try again shortly. (HTTP 500)
SERVER_ERROR	internal	payment_initiation	server_error	We are facing some trouble completing your request at the moment. Please try again shortly. (HTTP 400)
SERVER_ERROR	internal	NA	server_error	We are facing some trouble completing your request at the moment. Please try again shortly. (HTTP 504)
SERVER_ERROR	internal	payment_authorization	server_error	We are facing some trouble completing your request at the moment. Please try again shortly. (HTTP 500)
SERVER_ERROR	internal	payment_validate	server_error	We are facing some trouble completing your request at the moment. Please try again shortly. (HTTP 400)
BAD_REQUEST_ERROR	internal	order_creation	server_error	DCS Fetch Feature Failure (HTTP 400)
SERVER_ERROR	asv_server	—	request_failure	unexpected error received from account service (HTTP 500)
SERVER_ERROR	—	—	—	The server encountered an error. The incident has been reported to admins. (HTTP 400)

1. Build Integration

2. Test S2S Integration

3. Go Live Checklist

Features

Test Order Creation

1. Test Mode Coverage

2. Test Kit

3. Scenarios to Test Your Integration

4. Scenario Details

ORD-01 Create an order

ORD-02 · ORD-03 Order lifecycle

ORD-05 Idempotent create with `unique_receipt`

ORD-07 Pay an order that is already paid

ORD-18 · ORD-19 UPI Autopay authorisation order (registration)

ORD-20 · ORD-21 Card mandate authorisation order

ORD-22 · ORD-23 Debit orders (subsequent debits)

5. Common Integration Gaps to Avoid

Webhook and token updates

Error handling and messaging to the payer

Fetch API when webhooks are late

6. Best integration practices

7. Simulate Failures

Errors available in test mode (34 triggers → 7 distinct `error.reason` values)

Errors not available in test mode (15 rows → 8 distinct `error.reason` values)

1. Test Mode Coverage

2. Test Kit

3. Scenarios to Test Your Integration

4. Scenario Details

ORD-01 Create an order

ORD-02 · ORD-03 Order lifecycle

ORD-05 Idempotent create with unique_receipt

ORD-07 Pay an order that is already paid

ORD-18 · ORD-19 UPI Autopay authorisation order (registration)

ORD-20 · ORD-21 Card mandate authorisation order

ORD-22 · ORD-23 Debit orders (subsequent debits)

5. Common Integration Gaps to Avoid

Webhook and token updates

Error handling and messaging to the payer

Fetch API when webhooks are late

6. Best integration practices

7. Simulate Failures

Errors available in test mode (34 triggers → 7 distinct error.reason values)

Errors not available in test mode (15 rows → 8 distinct error.reason values)

Related Information

ORD-05 Idempotent create with `unique_receipt`

Errors available in test mode (34 triggers → 7 distinct `error.reason` values)

Errors not available in test mode (15 rows → 8 distinct `error.reason` values)