Skip to main content

List of Payments Webhook Events

The table below lists the webhook events available for payments.

Webhook Event | Description

payment.authorized | Triggered when a payment is authorised.

payment.captured | Triggered when a payment is successfully captured.

payment.failed | Triggered when a payment fails.
Handy Tips
  • The payload for a Webhook is a snapshot of the entity when the event occurred. For example, when a customer makes a payment, its status changes to authorized. It can then immediately move to the captured state.
  • The payment can be in the captured state when the payment.authorized Webhook is fired. However, the payload for the payment.authorized event contains details of the events when the payment was authorised, not when it was captured.
  • In case of network tokenised cards, the last 4 digits will be of the tokenised card and not the actual card.
  • The field flow is present only in the case of Turbo UPI Payments.

Comparison: payment.captured vs order.paid

Orders and payments go hand-in-hand. Once a payment is captured, the order is marked paid. This is reflected in the order.paid and payment.captured webhook events as well. These events are triggered when the payment associated with the order is captured.

payment.captured Webhook Event | order.paid Webhook Event

This event is triggered when the payment is successfully captured. | This event is triggered when a customer completes the checkout process and the order’s status changes to paid.

This payload only contains the payment entity, providing details specific to the transaction, such as the amount, currency, and payment method. | This payload includes both order and payment entities, making all relevant information available in a single payload.

Sample Payloads

Given below are the sample payloads for payments webhook events.

Payment Authorised

Netbanking

Payment Captured

Netbanking
Watch Out!You may occasionally observe a payment.failed webhook followed by a payment.captured webhook for the same transaction. While late authorisation is a known reason for this, user-initiated retries, particularly with UPI transactions, also cause this sequence.Here is a common scenario:A customer attempts a UPI payment via their Third-Party Application Provider (TPAP) such as PhonePe or Google Pay. The initial attempt fails, perhaps due to an incorrect PIN or insufficient balance.Most UPI TPAPs offer an immediate option to retry the payment directly within their app. When a customer retries, here is how our system responds:
1

We **trigger and send a `payment.failed` webhook** to your configur...

We trigger and send a payment.failed webhook to your configured endpoint, indicating the initial payment failure.
2

If the customer retries the payment and successfully completes it (...

If the customer retries the payment and successfully completes it (for example, by entering the correct PIN), the transaction concludes.
3

Subsequently, we **send a `payment.captured` webhook**, confirming...

Subsequently, we send a payment.captured webhook, confirming the successful capture of funds for that same transaction.
This sequence is expected behaviour. It allows customers to correct errors and complete their transactions without having to start a new payment process.

Payment Failed

Netbanking
Watch Out!
  • Do not hardcode the vpa parameter in the integration. If a UPI Intent payment fails, the vpa parameter may not get displayed at times.
  • The webhook sequence is not fixed in the JSON payload for payment events.
  • payment.failed is not triggered if the payment fails during authorisation (while making the first payment).

Payments Downtime

Downtime is a period during which one or more payment options underperform, leading to considerable delays in payment processing. These downtimes are due to technical issues or outages at Razorpay’s partner or issuing banks side. Razorpay informs you about the downtime to communicate it to your customers.

List of Payments Downtime Webhook Events

The table below lists the webhook events available for payments downtime.

Webhook Event | Description

payment.downtime.started | Triggered at the beginning of the downtime.

payment.downtime.resolved | Triggered when a downtime is resolved.

payment.downtime.updated | Triggered when a downtime is updated.

Payment Downtime Started

Netbanking

Payment Downtime Resolved

Netbanking

Payment Downtime Updated

Netbanking
Watch Out!
  • If you have changed your webhook secret, remember to use the old secret for webhook signature validation while retrying older requests. Using the new secret will lead to a signature mismatch.
  • While generating a signature at your end, ensure that the webhook body is passed as an argument in the raw webhook request body. Do not parse or cast the webhook request body.