PayU Costa Rica
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.
|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||No|
The following table lists all supported requests for card-based transactions.
Use the bodybuilder to create a sample request body for each request type.
|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|
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 Costa Rica account, enable the validate unique. This will validate that each payment reference sent to the PayU Latam system is unique.||Required|
|In your PayU Costa Rica account, enable asynchronous refunds (refunds will initially have a status of pending)||Required|
|In your PayU Costa Rica 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
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.