PayU Guatemala

API Version

Minimum required API version: 1.2.0

Payment Methods

The following table lists all supported payment methods.

Currencies

GTM

Features

The following table provides an overview of all supported and non-supported features.

Feature	Supported	Notes
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	Yes
3DS 2.0 Self-handled	Yes
Installments	Yes
Level 2 and 3 Data	No
Network Tokens	No
Payment Facilitator	No
PayU Risk	Yes
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.

• Cards
• Payment Page

Setup Procedures

The following table lists the setup procedures that are specific to this provider.

Integration Procedures

The following sections list the integration procedures that are specific to this provider.

Enabling 3DS

For more information on implementing 3DS authentication flows, see the Provider-handled Flow documentation. Merchants using PayU Latam can implement 3D Secure authentication to verify shoppers' identities and reduce fraudulent transactions. To indicate that a 3DS flow should be invoked, include a provider_specific_data object with an is3ds value in your Create Authorization or Create Charge API requests.

"merchant_site_url": "http://www.abc.com/return-url",
"provider_specific_data": {
    "payulatam": {
      "additional_details": {
        "is3ds": "true"
      }
    }
  }

You can pass one of the following is3ds values:

• "true": 3DS will always be invoked

• "false": 3DS will never be invoked

• "": If you leave this field empty PayU Latam will determine whether to invoke 3DS based on your account configuration and fraud analysis results.

When implementing 3DS, you must include a merchant_site_url in your Create Authorization or Create Charge request. When the shopper completes the 3DS authentication, they will be redirected to this URL with additional parameters containing transaction information. When a 3DS flow is initiated, the response will include:

• A provider_data object with the 3DS response_code and description

• A redirection object with the link to the bank site where the shopper will complete the 3DS authentication

{
 "provider_data": { 
        "provider_name": "PayULatam",
        "response_code": "PENDING_THREEDS_CALLBACK",
        "description": "Awaiting 3DS callback",
        "raw_response": "{}" 
 },
 "redirection": {
        "created": "1739446823717",
        "merchant_site_url": "http://www.abc.com/return-url",
        "url": "https:gotothebank/redirectPost.do?PayUReference=44469235032811"
 }
}

When redirecting the shopper back to the merchant’s site, PaymentsOS will extend the merchant_site_url with the following parameters: payment_id, authorization_id or charge_id, and the authorization status:

<merchant_site_url>?payment_id=dd1fbe34-4636-4a61-8cb1-27ac8a175284&authorization_id=aec1c306-e0f7-452b-8fb5-5b34489e9d10&status=Succeed

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/