Skip to the tool
MoveAheadPayments Toolbox
Webhook capture

Razorpay error code: GATEWAY_ERROR

The request could not be completed because of an error at the payment gateway or the downstream bank. It is not your request that is wrong — something further along the chain failed, and Razorpay's guidance is to retry with the same idempotency key and request body.

GATEWAY_ERRORRetryable

The same request can succeed later. Retry with backoff.

What it means

Razorpay sits in front of banks, card networks and UPI, and a GATEWAY_ERROR reports a failure at one of those rather than in your call. That distinction matters for how you respond: a BAD_REQUEST_ERROR needs your code changed, whereas a GATEWAY_ERROR often needs nothing more than a retry. Razorpay's own documented remedy is to retry using the same idempotency key and the same body, which is what makes the retry safe.

Common causes

  • A downstream bank or issuer is unavailable or timing out — common during bank maintenance windows.
  • A UPI or netbanking outage at a specific bank, so failures cluster on one handle or one bank rather than across all traffic.
  • A transient failure inside the gateway itself.
  • A payment method temporarily disabled upstream.

How to fix it

  1. Retry with the same idempotency key and the same request body, exactly as Razorpay's documentation prescribes. The key is what stops a retry becoming a second payment.
  2. Back off between attempts and cap them. A downstream bank outage is not resolved by retrying harder.
  3. Check whether failures cluster on one bank or payment method. If they do, it is that bank's outage and there is nothing on your side to change.
  4. Never mark the payment failed in your own records without confirming its status with Razorpay first — a gateway error is exactly the situation where your view and theirs can diverge.

Tools that help

Frequently asked questions

Was the customer charged?
You cannot assume either way, which is why the idempotency key matters. A gateway error can occur after a downstream bank has debited the customer but before the result reached Razorpay. Fetch the payment's current status from the API rather than inferring it from the error, and reconcile before showing the customer a failure.
Why is there no HTTP status listed for this code?
Because Razorpay does not document one on the pages this entry was checked against, and this dictionary does not fill gaps with plausible-looking guesses. If you need the status for your error handling, log what your own client actually receives rather than trusting a number from a third-party summary.