PayU India

Adapter 0.1.0, documentation reviewed 2026-10-25. Overall status: limited.

Capabilities

Error decoding	supported
API response parsing	limited
Webhook / notification parsing	limited
Timeline	limited
Event correlation	limited
Diagnostic rules	limited

Supported input

Format	Description	Status
`payu_india.payment_response`	Form-encoded payment response posted to surl, furl or curl and the Successful / Failed payment webhook, which share one field set (mihpayid, txnid, status, unmappedstatus, error, error_Message, field7, field8, field9, bank_ref_num, hash)	limited
`payu_india.verify_payment`	Verify Payment API JSON (status 0/1, msg, transaction_details keyed by txnid)	limited
`payu_india.command_response`	Command API JSON envelope (status 0/1, msg, mihpayid, request_id, error_code) of refund, capture and cancel requests; error_code is decoded only for refund requests	experimental
`payu_india.refund_webhook`	Refund webhook and refund status callback JSON; recognized, not analyzed	unsupported
`payu_india.dispute_webhook`	Dispute (chargeback) webhook JSON; recognized, not analyzed	unsupported
`payu_india.s2s_response`	S2S interim payment response (metaData, result, binData); recognized, not analyzed	unsupported
`payu_india.transaction_details`	Date-range transaction listing (Transaction_details array); recognized, not analyzed	unsupported
`payu_india.settlement`	Settlement and chargeback REST APIs, Payment Links, subscriptions and payouts	unsupported

Notification delivery

Repeated deliveries are recognized by no documented key: payment webhooks carry no event or delivery id, so repeated deliveries are not recognized; PayU India documents that notifications can be delivered more than once.
Delivery order: not documented by the provider.
PayU asks merchants to handle duplicate webhook events idempotently. Key your handler on mihpayid and the status, never fulfil an order while status is pending, and confirm the state with the Verify Payment API before acting. Retry schedule and ordering of webhooks are not documented.

Known limitations

The browser post to surl, furl or curl and the payment webhook use the same fields, so a pasted record cannot be attributed to one of them. PayU calls the server-to-server webhook the primary source of truth.
Payment webhooks have no event or delivery id, retry schedule or ordering rule. No delivery key is set, so a repeated delivery appears as a separate event and is not reported as a duplicate.
status pending (UPI, net banking, wallets and corporate banking that complete later) stays pending. PayU says only success is a successful payment and a pending payment must be resolved with the Verify Payment API or a later webhook. The length of the pending window is not documented.
The payment response and Verify Payment output carry no currency field, so amounts are shown as the decimal strings PayU sends (amount, net_amount_debit, amt) and are not converted to minor units.
addedon has no documented time zone. It is shown as supplied and is not used as an event time, so events are ordered as they appear in the input.
Codes are decoded from the main payment error table, the EX table, the subscription and Alt ID tables, and the AuthN/AuthZ mapping tables (possible confidence). The UPI error table disagrees with the main table for 67 of its 210 rows and is not used.
E307, E9251, E9252, E9254, EX151, EX306, EX307 and EX401 have several rows with different texts; all meanings are shown with possible confidence. Thirteen codes from the AuthN/AuthZ mapping tables have no meaning and are shown as unknown.
E4936 appears in a Verify Payment example but in no code table; it and any other unlisted code are shown as unknown with insufficient confidence.
PayU says error reasons come from banks and can differ between transactions. field8 (the bank's raw reason) and field9 (PayU's translation) are shown as text after removing identifier-like values; they are not decoded. Field7 is read as the execution stage; seven Field7 values used only in the AuthN mapping table are not described and are not interpreted.
The issuer response code table (67 codes mapped to PayU codes) is kept as reference data only: no payload field is documented to carry the issuer code. field5 looks like that code in card samples, but the docs do not say so, so it is not read.
error_code of the command API is decoded with the refund initiation table only when the msg shows a refund request, because the capture table reuses the same numbers with other meanings. A queued refund (status 1, error_code 102) is shown as pending, not as a completed refund. Refund status codes (R000-R501) are kept as reference data because the docs do not say which field carries them. Command API bodies printed as PHP arrays or PHP-serialized strings are not parsed.
Refund webhooks, refund ARN callbacks, dispute webhooks, S2S interim responses and the transaction listing are recognized but not analyzed. Settlement and chargeback APIs, Payment Links, subscriptions (SI, e-NACH, UPI Autopay), payouts and PayU platforms outside India are not analyzed.
Events are linked only by mihpayid (PayU's transaction id). txnid is shown as the merchant reference and not used for linking. A Verify Payment entry that PayU reports as Not Found has no mihpayid and stays on its own.
The response hash is a SHA-512 over the merchant salt and payment fields. It is never verified or copied; only its presence and length are reported. The merchant key, udf1-udf10, card, UPI (VPA), account, phone, email, name, address and PAN fields are never copied.
Field names drift between APIs and pages (error_Message and error_message, bank_ref_num and bank_ref_no, userCancelled and usercancelled, success and failed). The documented variants are accepted; status values are matched without regard to case.
Category and retry guidance per code are PandaPayLens suggestions; where PayU gives advice it is reflected.

Examples

PayU India: card declined webhook: A declined card payment with the failure stage and the bank's own reason.
PayU India: UPI payment pending: A UPI payment that is still pending at redirect.

Provider documentation

PandaPayLens is not affiliated with PayU India. Pasted notifications are never treated as verified: PandaPayLens does not check webhook signatures.