PayU Chile

Follow the standard PaymentsOS integration procedure, and then apply the relevant extra specifications described below.

• API Version
• Payment Methods
• Currencies
• Features
• Requests
• Setup Procedures
• Integration Procedures
• Errors in a Redirection Flow
• Testing

API Version

Minimum required API version: 1.2.0

Payment Methods

The following table lists all supported payment methods.

Currencies

CLP

Features

The following table provides an overview of all supported and non-supported features.

Feature	Supported
3DS 1.0 External	No
3DS 1.0 Internal	No
3DS 2.0 External	No
3DS 2.0 Internal	No
End-to-End Encryption (E2EE)	No
Installments	Yes
Level 2 and 3 Data	No
Network Tokens	No
Payment Facilitator	No
Pre-authorization	No
Retrieve Supported Payment Methods	No
Retrieve Supported Plans	No
Statement Soft Descriptor	Yes
Stored Credentials Flag	No
Transaction Processing without CVV	No

Requests

The following table lists all supported requests. Use the bodybuilder to create a sample request body for each request type.

Setup Procedures

The following table lists the setup procedures that are specific to this provider.

Integration Procedures

The following sections list the integration procedures that are specific to this provider.

Handling the Charge Request Response for Cash Transactions

When you send a post charge request, we will return a charge resource containing a charge.redirection.url, and a status of 'pending'. Redirect your customer to this URL (the MULTICAJA site). Then follow the steps below:

1. Once your customer finishes their interaction with the MULTICAJA site, we'll redirect your customer's browser back to your site, using the merchant_site_url (that you provided in the post charge request). We've included the following URL parameters in the merchant_site_url, to provide you with the context of the page that you'll need to load: payment_id, charge_id, and status (of the charge).

   Example - Charge request Pending:

    <merchant_site_url>
     ?payment_id=dd1fbe34-4636-4a61-8cb1-27ac8a175284
     &charge_id=aec1c306-e0f7-452b-8fb5-5b34489e9d10
     &status=Pending
   

   The status of your charge request may still be 'pending' when we redirect your customer back to your site (while the provider is processing the request).

   Example - Charge request Failed:

    <merchant_site_url>
     ?payment_id=dd1fbe34-4636-4a61-8cb1-27ac8a175284
     &charge_id=aec1c306-e0f7-452b-8fb5-5b34489e9d10
     &error=provider_error
   

2. Your customer should choose one of the payment options:

   • Pay at a MULTICAJA office. Your customer should print the "payment coupon", or copy coupon code, and go to any MULTICAJA office to pay for their purchase, before the expiration date.

   • Pay online with an electronic bank transfer. This option is only available in the live environment.

3. When the provider notifies us that your customer has paid, we will update the transaction status. If no payment notification is received by the expiration date, then the transaction will be considered as failed.

Errors in a Redirection Flow

In a redirection flow, customers finalize a transaction on a third-party site and are then directed back to your web page (the merchant_site_url) where you inform them of the status of their payment. Of course, there’s always a chance of an unexpected error (such as a provider communication timeout) in this process. If an error does occur, we’ll let you know about it by appending the type of error (api_error or provider_error) to the merchant_site_url. If available, we will also include the ID of the original payment request and related transaction request (action).

Here’s an example.

<merchant_site_url>?error=api_error&payment_id=dd1fbe34-4636-4a61-8cb1-27ac8a175284
&action_id=f7cdc75d-68d3-4a0b-b6ae-39c5a9a2cbcb/

Testing

Follow the steps in the PayU integration testing page.

To test requests in the PayU Latam sandbox environment, make sure your account has been configured to operate in test mode. You can then simulate specific response statuses for each request type, as listed below.

For Authorization and Charge Requests:

• To simulate a status of Succeed, pass in "holder_name": "APPROVED" in the Create Token request.

• To simulate a status of Pending, pass in "holder_name": "PENDING_TRANSACTION_REVIEW" in the Create Token request.

• To simulate a status of Failed, pass in "holder_name": "REJECTED" in the Create Token request.

For Capture, Refund and Void requests:

• To simulate a successful Capture request, first initiate a successful Authorization request.

• To simulate a successful Refund request, first initiate a successful Charge or Capture request.

• To simulate a successful Void request, first initiate a successful Authorization request.

Simulating a Request Timeout

To simulate a request timeout, invoke the Create Token request and pass an expiration_date with a format of MM/2022, where MM is the delay in seconds. The month (MM) can be any value between 01 (10 seconds) and 05 (50 seconds).

Test Cards

You can use the following cards for testing: