Payments - Sample Payload
Sample payload for Payments
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.
The table below lists the Webhook events available for payments.
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 thecaptured
state. - The payment can be in the
captured
state when thepayment.authorized
Webhook is fired. However, the payload for thepayment.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.
Handy Tips
The field flow
is present only in the case of Turbo UPI Payments.
Handy Tips
The field flow
is present only in the case of Turbo UPI Payments.
Watch Out!
- Do not hardcode the
vpa
parameter in the integration. If a UPI Intent payment fails, thevpa
parameter may not get displayed at times. - The webhook sequence is not fixed in the JSON payload for payment events.
Handy Tips
The field flow
is present only in the case of Turbo UPI Payments.
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.
Do Not Parse or Cast the Webhook Request Body
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.
The table below lists the webhook events available for payments downtime.
Was this page helpful?