Confirmation Page

The confirmation page lets you update the databases in your system; hence, this page should not include HTML code as it’s not visible to the buyer. This page is optional; when a transaction is complete (i.e., when approved, rejected, or when canceled) our platform sends the variables via the HTTP POST method.

In the confirmation page, you must capture the data you want to store in the database. This capture depends on the programming language you use.

Considerations

• If your site is restricted with basic access authentication or similar, disable it for the confirmation URL.
• The IP associated with the confirmation URL should be public; do not use URL accessible from intranet or localhost.
• If you’re using HTTPS, you must have a valid certificate.
• The format of your confirmation page must be x-www-form-urlencoded.
• Do not use security certificates elliptic curve or those who have the suite of encryption TLS_ECDHE_ECDSA_WITH_RC4_128_SHA on your confirmation page.
• PayU reports the confirmation page once the transaction has a final status for example, when approved, rejected or expired. If a transaction is in progress (waiting for payment or analysis), PayU does not report until the transaction has a final status.

Whitelist of IP Addresses for PayU Latam Servers

To ensure seamless communication between your server and PayU Latam servers, 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

By whitelisting these addresses, you can ensure that requests and notifications from PayU are properly received.

Variables sent with the confirmation page

POST example send to the confirmation page

The following is a basic example of the variables sent to the confirmation page via POST:

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

The signature validation allows you to check the data integrity, you must generate the signature with the information you find in the confirmation page and compare it with the information from the signature parameter.

To validate the signature in the confirmation page, you should consider:

• If the second decimal is zero, the new_value to generate the signature must have one decimal. Example (150.00 -> 150.0).
• If the second decimal is not zero, the new_value to generate the signature must keep the same two decimals. Example (150.26 -> 150.26).
• Get the parameters to generate the signature (merchant_id, reference_sale, value, currency, and state_pol) from the confirmation page, do not get them from your database.
• You must store your ApiKey safely.
• Create the signature as follows:

"ApiKey~merchant_id~reference_sale~new_value~currency~state_pol"

Example

With one decimal

Your apiKey: 4Vj8eK4rloUd272L48hsrarnUA 
Parameters obtained from the confirmation page
- merchant_id = 508029
- reference_sale = TestPayU04
- value = 150.00
- currency = USD
- state_pol = 6

The signature is generated in the following way: 
MD5(4Vj8eK4rloUd272L48hsrarnUA~508029~TestPayU04~150.0~USD~6) = b607a2c2fa100e0947b206d41864fb86

sign = b607a2c2fa100e0947b206d41864fb86

With two decimals

Your apiKey: 4Vj8eK4rloUd272L48hsrarnUA 
Parameters obtained from the confirmation page:
- merchant_id = 508029
- reference_sale = TestPayU05
- value = 150.26
- currency = USD
- state_pol = 4

The signature is generated in the following way: 
MD5(4Vj8eK4rloUd272L48hsrarnUA~508029~TestPayU05~150.26~USD~4) = 1d95778a651e11a0ab93c2169a519cd6

sign = 1d95778a651e11a0ab93c2169a519cd6 

Compare your signature

This calculator lets you generate the signature using any of the available encryption methods.

Payment retries

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

Each of these calls are made with the same payment reference (reference_sale), the same order identifier (reference_pol) but with different transaction identifier (transaction_id). Therefore, you can receive several calls to the confirmation page for the same sale.

Below, you find an example of a rejected attempt and its 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

Note that if one of those calls to the confirmation page indicates that a payment reference (reference_sale) was approved, you can be certain that you will not receive any report to the same reference.