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.
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.