Confirmation Page

This page, invisible to customers, receives data via HTTP POST. Notably, if a payer attempts payment retries, a confirmation is generated for each transaction, regardless of whether it’s approved or rejected.

As this page is intended solely for system updates and is not customer-facing, it should not contain any HTML code. While its implementation is optional, it is highly recommended for ensuring your system accurately reflects transaction outcomes.

Upon completion of a transaction (whether approved, rejected, or canceled), our platform transmits relevant variables to your confirmation page URL using the HTTP POST method, requiring you to implement server-side logic to capture and process this data according to your chosen programming language.

Considerations

• Disable Authentication: If your site employs basic access authentication or similar security measures, ensure these are disabled for the confirmation page URL to allow access from PayU.
• Public IP Address: The IP address associated with your confirmation page URL must be public. Avoid using URLs accessible only from an intranet or localhost.
• Valid HTTPS Certificate: If you are using HTTPS for your confirmation page, you must employ a valid SSL/TLS certificate.
• Content Type: The confirmation page must be configured to handle data in x-www-form-urlencoded format.
• Avoid Specific Security Configurations: Do not use elliptic curve security certificates or those with the TLS_ECDHE_ECDSA_WITH_RC4_128_SHA encryption suite for your confirmation page.
• Final Transaction Status Reporting: PayU will only trigger the confirmation page once a transaction reaches a final status (e.g., approved, rejected, or expired). You will not receive reports for transactions that are still in progress (waiting for payment or analysis).

Whitelist of IP Addresses for PayU Servers

To ensure that your server receives requests and notifications from PayU Latam, it is necessary to whitelist our IP addresses. This is especially important if your server is protected by a firewall. All webhook requests and communication from PayU servers will originate from the IP addresses listed below.

Production Environment

• 198.61.156.98
• 190.216.203.233
• 34.233.144.154

Sandbox Environment

• 50.56.9.170
• 74.205.10.14
• 54.158.171.129

Parameters

The confirmation page transmits the following parameters via HTTP POST to your server:

POST Request Example for the Confirmation Page

The following example shows how our system sends parameters to your confirmation page using an HTTP POST request:

response_code_pol=5
phone=
additional_value=0.00
test=1
transaction_date=2015-05-27 13:07:35
cc_number=************0004
cc_holder=test_buyer
error_code_bank=
billing_country=CO
bank_referenced_name=
description=test_payu_01
administrative_fee_tax=0.00
value=100.00
administrative_fee=0.00
payment_method_type=2
office_phone=
email_buyer=test@payulatam.com
response_message_pol=ENTITY_DECLINED
error_message_bank=
shipping_city=
transaction_id=f5e668f1-7ecc-4b83-a4d1-0aaa68260862
sign=e1b0939bbdc99ea84387bee9b90e4f5c
tax=0.00
payment_method=10
billing_address=cll 93
payment_method_name=VISA
pse_bank=
state_pol=6
date=2015.05.27 01:07:35
nickname_buyer=
reference_pol=7069375
currency=USD
risk=1.0
shipping_address=
bank_id=10
payment_request_state=R
customer_number=
administrative_fee_base=0.00
attempts=1
merchant_id=508029
exchange_rate=2541.15
shipping_country=
installments_number=1
franchise=VISA
payment_method_id=2
extra1=
extra2=
antifraudMerchantId=
extra3=
nickname_seller=
ip=190.242.116.98
airline_code=
billing_city=Bogota
pse_reference1=
reference_sale=2015-05-27 13:04:37
pse_reference3=
pse_reference2=

Signature Validation

Signature validation ensures the integrity of the data received on your confirmation page. You must generate the signature using the parameters that PayU provided and compare it with the sign parameter sent in the HTTP POST request.

Important Considerations

• If the second decimal of the value is zero, format the new_value using one decimal place (e.g., 150.00 → 150.0).
• If the second decimal is not zero, retain two decimal places in the new_value (e.g., 150.25 → 150.25).
• Always use the values from the confirmation page (merchant_id, reference_sale, value, currency, and state_pol) to generate the signature. Do not use values from your own database.
• Store your API key securely.
• Construct the signature string in the following format:

apiKey~merchant_id~reference_sale~new_value~currency~state_pol

Signature Examples

The following examples illustrate how to generate a signature, in this case, using HMAC-SHA256.

Signature with One Decimal

Use this example when the second decimal of the value is 0. In this case, format the value with only one decimal place.

Signature with Two Decimals

Use the following example when the second decimal of the value is not 0. Format the value with two decimal places.

Validate Your Signature

Use this generator to create a signature with any of the available encryption methods. This functionality assists you in verifying the sign value that PayU sends to your confirmation page.

Payment Retries

When a transaction is rejected, the payer has the option to retry the payment using the same or a different payment method. Keep in mind that for each attempt, PayU sends a request to the confirmation page with the corresponding transaction status.

Each of these requests uses the same payment reference (reference_sale) and order identifier (reference_pol), but includes a different transaction identifier (transaction_id). As a result, you may receive multiple calls to the confirmation page for the same sale.

Below is an example showing a rejected attempt followed by an approved retry:

reference_sale=2015-05-27 13:04:37
reference_pol=7069375
transaction_id=f5e668f1-7ecc-4b83-a4d1-0aaa68260862
state_pol=6

reference_sale=2015-05-27 13:04:37
reference_pol=7069375
transaction_id=01cfdce8-68d5-4a4c-aabf-d89370a0b92f
state_pol=4