1. Home
  2. Docs
  3. Developers Guide
  4. Integration APIs
  5. Webhooks


Webhooks are user-defined HTTP callbacks or messages, operating at the server to server (S2S) communication levels. Certain instances or events trigger them. The following document attempts a complete overview of how PayU uses the technology to develop a secure and accountable architecture for the payment workflows between the merchant’s servers and its own.

PayU Webhooks

PayU provides for both PayU Hosted and Merchant Hosted integration with the merchant’s system. These payment workflows are triggered through a browser call and operate at the browser level itself. It involves switching the user between the merchant, PayU, and the bank’s website environments and redirecting them to the success or failure URLs on a case-to-case basis. In this browser redirection approach, it may be technically challenging for the merchant to ascertain the integrity of responses every time, affecting end-user experience.

Webhook is a server-to-server callback. Once this feature is activated for merchants, PayU would send an S2S response, in addition to Browser redirection, to the merchant. It is recommended for the merchant to process the transaction order status – based upon the S2S response and not via the Browser Redirection response to ensure optimum translation outcomes.

Why PayU uses Webhook?

The S2S callback is a useful and recommendable feature for merchants while integrating with PayU. PayU sends the final transaction response to the merchant via browser redirection. However, due to network issues or other technical lags, this browser redirection may not be successful and the transaction may get dropped (between PayU and Merchant). In such events, the merchant will not be able to complete the processing of the order at their end. For such cases, this callback feature can be used effectively.

How Can The Merchant Use Webhooks?

Step 1: The merchants need to create a server URL (Ex: www.test.payu.in/success/response) from their business server landscape and share it with PayU, along with its server IP address. It is the URL at which the transaction response from PayU will hit.

Step2: PayU will configure the merchant’s server URL at its backend, mapping it against the MID and key of that particular merchant.

Step3: To establish the connection, PayU will Whitelist the webhook URL provided by merchant in its systems. And, the merchant also needs to whitelist the following IP address at their firewall side to receive a response from the PayUBiz servers:

Step 4: PayU will send an S2S response to the merchant’s server URL. The response will always be sent as the key-value pair separated by ‘&’ character or HashMap formats, and the merchant’s server URL should be capable of handling the following content types:

● FormData

● application/x-www-form-urlencode

So while creating the server URL, the merchant needs to ensure that it can accept the data in the above content formats.

Below is a sample response from PayU to the merchant:

unmappedstatus=success&phone=9999999999&txnid=FCDA1R100870163781&hash=84e335094bbcb2ddaa0f9a488eb338e143b273765d89c9dfa502402562d0b6f3c7935e28194ca92f7380be7c84c3695415b106dcf52cb016a15fcf6adc98d724&status=success&curl=https://www.abc.in/payment/handlepayuresposne&firstname=NA&card_no=519619XXXXXX5049&furl=https://www.abc.in/payment/handlepayuresposne&productinfo=2&mode=DC&amount=800.00&field4=6807112311042810&field3=6807112311042810&field2=838264&field9=SUCCESS&email=NA&mihpayid=175477248&surl=https://www.ABC.in/payment/handlepayuresposne&card_hash=9e88cb0573d4a826b61d808c0a870ed4a990682459b0ec9e95ea421e8e47b e8c&field1=42812

The parameters used in generating the above response block are similar to those that the merchant has shared with PayU while triggering the transaction.

In case a parameter has not been consumed, PayU sends it back to the merchant with an empty string.

Step 5: As the PayU response hits the merchant’s server URL, it must confirm the receipt with the success status response code: 200 OK.

PayU will attempt three times to get a 200 OK response from the merchant’s servers before flagging the transaction as a timeout. Sometimes it may happen due to the wrong configuration of the merchant’s server URL. This makes it crucial for the URL to accept and process data in key-value pairs separated by ‘&’ character or HashMap formats and handle the content types mentioned above.