Follow the standard PaymentsOS integration procedure, and then apply the relevant extra specifications described below.
- API Version
- Payment Methods
- Setup Procedures
- Integration Procedures
- Errors in a Redirection Flow
Minimum required API version: 1.2.0
The following table lists all supported payment methods.
|Payment Method||Payment Method Type|
The following table provides an overview of all supported and non-supported features.
The PaymentsOS test environment does not support charge and refund requests listed (this is a limitation of the PayU Latam sandbox environment).
The following table lists all supported requests. Use the bodybuilder to create a sample request body for each request type.
|Authorize||Partial and multiple are not supported||Asynchronous or Synchronous|
|Capture||Partial is supported||Asynchronous or Synchronous|
|Charge||Not Applicable||Asynchronous or Synchronous||The request can be synchronous or asynchronous, depending on your setup.|
|Refund||Partial is supported||Asynchronous|
Creating a Provider Configuration
When creating a new provider configuration in the PaymentsOS Control Center, select PayU Latam as the provider.
The following table lists the setup procedures that are specific to this provider.
|In the PaymentsOS Control Center, configure the following credentials: ||Required|
|In the PaymentsOS Control Center, register webhooks to be notified when a transaction changes its status.|
|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
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:
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 chargerequest). 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:
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
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.
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
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 (
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.
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.
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.
Not passing a CVV code?
If do not pass a CVV code in the request (
provider_specific_data.payu_latam.process_without_cvv2: true), then you also need to pass an expiration date where MM <= 06 and YYYY != 2022 to simulate a status of
Succeed, in addition to the
holder_name values listed above. When simulating a status of
Failed, MM must be > 07.
Simulating a Request Timeout
You can only simulate a timeout request, if you do not pass a CVV code in the request (
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).
You can use the following cards for testing:
|VISA Credit Card||4938590000000017|
|MASTER Credit Card||5435630000000008|
|AMEX Credit Card||377825000000005|
|DINERS Credit Card||36525200000002|