PayU Chile

Follow the standard PaymentsOS integration procedure, and then apply the relevant extra specifications in this section to integrate with PayU Chile.

API Version

Minimum required API version: 1.2.0

Payment Methods

The following table lists all supported payment methods.

Payment MethodPayment Method Type
American ExpressCards
MASTERCARDCards
MULTICAJACash
RedcompraDebit Redirect
VISACards

Currencies

CLP

Features

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

FeatureSupportedNotes
3DS 2.0 ExternalNo
3DS 2.0 PaymentsOS-handledYesSupported flow type: Provider-handled Flow. For more information, see 3DS 2 PaymentsOS-handled Flow.
3DS 2.0 Provider-handledNo
3DS 2.0 Self-handledNo
InstallmentsYes
Level 2 and 3 DataNo
Multi-seller PaymentsNo
Network TokensNo
Payment FacilitatorNo
PayU RiskYes
Pre-authorizationNo
Retrieve Supported Payment MethodsNo
Retrieve Supported PlansNo
Statement Soft DescriptorYes
Stored Credentials FlagNo
Transaction Processing without CVVYes

Requests

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

Supported requests for card transactions.
RequestPartial/MultipleModeNotes
AuthorizePartial and multiple are not supportedAsynchronous or Synchronous
Capture Both partial and multiple are supportedAsynchronous or Synchronous
Charge Not ApplicableAsynchronous or SynchronousThe request can be synchronous or asynchronous, depending on your setup.
Refund Partial is supportedAsynchronous
Void Not ApplicableAsynchronousThe minimum time to send a void is three (3) hours after the authorization and the maximum is seven (7) days. If no void or capture is sent after this time, the transaction is auto-voided.
Supported requests for debit redirect transactions.
RequestPartial/MultipleMode
Charge Not ApplicableAsynchronous
Supported requests for cash transactions.
RequestPartial/MultipleMode
Charge Not ApplicableAsynchronous

Setup Procedures

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

ConfigurationRequired/Optional
In the PaymentsOS Control Center, configure the following credentials:
  • apiLogin: The user name supplied by PayU Chile
  • apiKey: The password name supplied by PayU Chile
  • accountId: The identifier of the account in PayU Chile
  • paymentCountry: CHL
  • merchantId: The merchant ID in PayU Chile
When creating a new provider configuration in the PaymentsOS Control Center, select PayU Latam as the provider.
Required
In the PaymentsOS Control Center, create webhooks to be notified when a transaction changes its status.

Notes:
  • Make sure to configure webhook notifications for refunds as well.
  • Some API requests in the payment flow may remain in a pending status for some time.
Required
In your PayU Chile account, enable the validate unique. This will validate that each payment reference sent to the PayU Latam system is unique.Required
In your PayU Chile account, enable asynchronous refunds (refunds will initially have a status of pending)Required
In your PayU Chile account, enable refund notifications. Make sure to include the transaction_type field in the notification (this step is required for PaymentsOS to remain in sync with the refund status).Required
Contact PayU Latam Support to get a list of the minimum payment amounts required by the payment methods that you intend to use.

To avoid unnecessary request failures, we recommend that you include some 'minimum value' validation for the transaction payment.amount in your system.
Optional

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.

Configuring Multiple Partial Captures

Suppose your acquirer does not support multiple partial captures, yet your business model requires you to invoke multiple capture requests for a single transaction. You can configure this functionality via your PaymentsOS account (Account > Providers) and choose ‘true’ from the drop-down menu of the ‘multiCapture’ field, like so:

Configuring Multiple Partial Captures

After activating this functionality, you will need to invoke separate capture request for every partial-capture you perform or separate void requests in case an item is out of the stock. We will submit a final capture request on your behalf for the sum of all of these partial captures when the total sum of your partial captures and voids reaches the full authorization amount, or if the capture time frame has timed out.

A few things to note:

  • A transaction’s initial status will always be pending and will remain pending until we invoke the final capture request. The transaction status will change according to the provider’s response, to reflect its new status (i.e., it will change to either succeed or failed).
  • When a transaction status changes to either succeed or failed, you will receive webhook notifications with the final statuses of each of the partial capture requests or partial void requests you invoked (e.g., if you invoked five capture requests, you will receive five webhooks).
  • Time limitation: Acquirers limit the time allotted to invoke a final capture request. We send the final capture request after five days to comply with these limitations.
  • If the total amount of the partial captures you invoked doesn’t equal the original authorization amount, we pass the partial amount for the acquirer’s approval after five days.
  • When you send a void request with no previous capture requests - though the sum still equals the original authorization amount - we call the provider with a void request to release the money back to the shopper’s account.

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:

Card Number
VISA Credit Card 4938590000000017
MASTER Credit Card 5435630000000008
AMEX Credit Card 377825000000005
DINERS Credit Card 36525200000002
Last modified September 19, 2022