Minimum required API version: 1.1.0
The following table lists all supported payment methods.
|Payment Method||Payment Method Type||Notes|
|Argencard||Cards||This is a local card vendor.|
|Cabal||Cards||This is a local card vendor.|
|Cencosud||Cards||This is a local card vendor.|
|Naranja||Cards||This is a local card vendor.|
|Shopping||Cards||This is a local card vendor.|
The following table provides an overview of all supported and non-supported features.
|3DS 2.0 External||No|
|3DS 2.0 PaymentsOS-handled||Yes||Supported flow type: Provider-handled Flow. For more information, see 3DS 2 PaymentsOS-handled Flow.|
|3DS 2.0 Provider-handled||No|
|3DS 2.0 Self-handled||No|
|Level 2 and 3 Data||No|
|Retrieve Supported Payment Methods||No|
|Retrieve Supported Plans||No|
|Statement Soft Descriptor||Yes|
|Stored Credentials Flag||No|
|Transaction Processing without CVV||Yes|
NoteThe PaymentsOS test environment only supports Authorize and Capture requests (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||Both partial and multiple are 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||Partial refund is only supported for the following payment methods: VISA, MASTERCARD, AMEX, DINERS, Argencard|
|Void||Both partial and multiple are supported||Asynchronous||To support multiple and partial, you must enable multiple captures in your provider configuration. For more information, see Configuring Multiple Partial Captures.|
Partial Refund Limitations
While partial refunds are supported, the following limitations apply:
You can send any amount for the partial refund as long as the value doesn’t exceed the initial or actual amount.
You can send as many as partial refund request as you require. The sum of the partial refund amounts cannot not exceed the total value of the transaction.
A partial refund request will always get a status of
pendingin the response. Partial refunds are processed manually by a PayU representative. The refund may take 2 to 6 calendar days to be processed. Once done, depending on the acquirer, the amount will appear in the extract in the next 1 to 30 days after the partial refund is processed.
If a partial refund is pending or is being processed, you cannot send a new request until the last one is processed.
Creating a provider configurationWhen 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, create webhooks to be notified when a transaction changes its status.|
|In your PayU Argentina account, enable the validate unique. This will validate that each payment reference sent to the PayU Latam system is unique.||Required|
|In your PayU Argentina account, enable asynchronous refunds (refunds will initially have a status of pending)||Required|
|In your PayU Argentina 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|
|In your PayU Argentina account, enable processing with CVV, if desired.Contact PayU Argentina support for assistance.||Optional|
|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
|Enable multiple captures in your provider configuration. For more information, see Configuring Multiple Partial Captures.||Optional|
The following sections list the integration procedures that are specific to this provider.
Handling the Charge Request Response for Cash Transactions
If the charge request is successful, then the provider will return a charge response containing:
- The expiration date of the Payment Receipt.
provider_data.documentobject with href links to the Payment Receipt in HTML format and possibly the Payment Receipt in PDF format.
Note that the
provider_data.additional_information field may contain a barcode, for receipt tracking purposes.
Now direct your customer to one, or both of the transaction payment receipts, so that they can print the receipt. Your customer should then take the payment receipt to the relevant Payment Office and pay for their purchase, before the expiration date.
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:
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
pendingand will remain
pendinguntil 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
- When a transaction status changes to either
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 (
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.
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.
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_namevalues listed above. When simulating a status of
Failed, MM must be > 07.
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
NoteYou 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:
|AMEX Credit Card||376414000000009|
|ARGENCARD Credit Card||5011050000000001|
|CABAL Credit Card||5896570000000008|
|CENCOSUD Credit Card||6034930000000005 - 5197670000000002|
|MASTER Credit Card||5399090000000009|
|NARANJA Credit Card||5895620000000002|
|VISA Credit Card||4850110000000000 - 4036820000000001|
|VISA Debit Card||4517730000000000|