PayU Panama

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

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

API Version

Minimum required API version: 1.0.0

Payment Methods

The following table lists all supported payment methods.

Payment Method	Payment Method Type
MASTERCARD	Cards
VISA	Cards

Currencies

USD

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 for card-based transactions. Use the bodybuilder to create a sample request body for each request type.

Request	Partial/Multiple	Mode	Notes
Authorize	Partial and multiple are not supported	Asynchronous or Synchronous
Capture	Partial and multiple are not supported	Asynchronous or Synchronous
Charge	Not Applicable	Asynchronous or Synchronous	The request can be synchronous or asynchronous, depending on your setup.
Refund	Partial and multiple are not supported	Asynchronous

Setup Procedures

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.

Configuration	Required/Optional
In the PaymentsOS Control Center, configure the following credentials: apiLogin: The user name supplied by PayU Panama apiKey: undefined accountId: The identifier of the account in PayU Panama paymentCountry: PAN merchantId: The merchant ID in PayU Panama When creating a new provider configuration in the PaymentsOS Control Center, select PayU Latam as the provider.	Required
In the PaymentsOS Control Center, register 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 Panama account, enable the validate unique. This will validate that each payment reference sent to the PayU Latam system is unique.	Required
In your PayU Panama account, enable asynchronous refunds (refunds will initially have a status of pending)	Required
In your PayU Panama 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

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.

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.

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

Note

You can only simulate a timeout request, if you do not pass a CVV code in the request (provider_specific_data.payu_latam.process_without_cvv2: true)

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
MASTER Credit Card	5455040000000005
VISA Credit Card	4723030000000005