Overview

With PayU, you will quickly activate payments on your website or mobile device.

We provide a full set of endpoints which allow you to create, capture, cancel and retrieve orders, perform payouts or download reports.

To simplify the integration, you can simply use one of our plugins or our PHP SDK.

Last but not least, many shopping platforms offer an in-built integration with PayU. If this is the case, follow the instructions of how to configure payments via PayU.

For starters, you definitely need a PayU account. It may be a production PayU account (register or contact a PayU partner or sales representative) or a sandbox account (register).

After you have logged in to the panel, create a Shop and POS of REST API type.

Note: in case you decided to use a production account to test your integration, your account will not be fully active until we verify you.

Before you start, it is important to choose the right integration model. There are several options available. The service you need to integrate and the configuration of your account may depend on the following:

Will you fullfil each order paid via PayU?

If no, you should disable "automatic collection" on your POS and make separate API-calls to create an order and capture or cancel it aferwards.

Are you selling more expensive goods or services?

If yes, boost your sales with PayU | Installments.

Will you process a lot of refunds?

If yes, you definitely should consider implementing API calls to facilitate refunds programatically, instead of performing them via the Panel.

Would you like to enable the payers to choose a payment method on your website?

If yes, go for "transparent" integration.

Will you create user accounts for your customers?

If yes, implement Card tokenization service and PayU will securely store card data, so your returning customers do not have to provide them each time and will be able to pay with a single click.

Will you charge your customers on a recurring basis (e.g. monthly)?

If yes, use the recurring payment service.

Are you a billing your customers by issuing an invoice connected with a specific bank account?

If yes, use the Mass Collect service.

Will you need to collect funds from customers and later distribute them to your subcontractors?

If yes, use the Payout API to streamline funding of your business partners.

Check our commercial offer for more details.

Feel free to contact us - by fiiling the form here.

In case you want them to check on a specific API call you made, provide the value of Correlation-Id header returned in the response from PayU.

PayU hosted payment page

Click the button – it will redirect you to a PayU hosted payment page.

The working example above shows the most basic integration - a payment form implementing REST API protocol. To make your integration easier to enhance in the future, consider using JSON requests.

Secure Form

Click the button - it will show a Secure Form which you may use to securely capture card data. The Secure Form can be also displayed inline.

To check all card payment processing options refer to the card forms section.

Public point of sale test data:

                
                POS ID (pos_id):                    145227
                Second key (MD5):                   13a980d4f851f3d9a1cfc792fb1f5e50
                OAuth protocol - client_id:         145227
                OAuth protocol - client_secret:     12f071174cb7eb79d4aac5bc2f07563f
                
            

Below is a list of test cases for your integration - check how your website handles the following:

1. Is your user correctly redirected to PayU when PayU responds with a HTTP 302 for the POST method calls you make to /api/v2_1/orders endpoint?
2. Do you receive and parse the notification from PayU and respond with a HTTP 200?
3. Do you correctly establish order status during its lifecycle? Mind, order status is only provided via notifications, the statuses returned in the response from PayU apply to the request itself and to the order(!).
4. Do you provide a continueUrl parameter? Is the customer redirected to this URL correctly after the payment process is completed?
5. Are you prepared to handle the error message passed in the query string added to the continueUrl?
6. In case of a PayU|Express integration - is your website ready to handle all the payment authorization scenarios?

Options 1 and 2 above can be performed either via the Panel or programatically via API.

Below is a list of test cases for your integration - check how your website handles the following:

1. Is your user correctly redirected to PayU when PayU responds with a HTTP 302 for the POST method calls you make to /api/v2_1/orders endpoint?
2. Do you receive and parse the notification from PayU and respond with a HTTP 200?
3. Do you correctly establish order status during its lifecycle? Mind, order status is only provided via notifications, the statuses returned in the response from PayU apply to the request itself and to the order(!).
4. Do you provide a continueUrl parameter? Is the customer redirected to this URL correctly after the payment process is completed?
5. Are you prepared to handle the error message passed in the query string added to the continueUrl?
6. In case of a PayU|Express integration - is your website ready to handle all the payment authorization scenarios?

Options 1 and 2 above can be performed either via the Panel or programatically via API.

Sandbox is an almost identical copy of PayU production system. It can be used for integration and testing purposes. To use the sandbox you need a register separately in one quick step. After you are registered, you can set up own companies / shops / point of sale.

Use the following links:

• registration
• login page

Read the instruction if you do not know how to register or set up a new store in your Sandbox account.

In order to test card payments on sandbox, please use the following credentials.

All test cards support authentication by means of 3DS 2 protocol and the result is, unless stated otherwise, a successful frictionless authentication.

In practice this means that all orders with card token or card number in plain text as a payment method will return WARNING_CONTINUE_3DS status, unless the order is out of scope of SCA (like recurring payments or MOTO).

NOTE - due to SCA/PSD2 requirements, test cards with default 3DS result cannot be used to store the card/token.

OneClick payments with the test cards require a CVV unless specified otherwise in the Behavior column.

Functionalities available on sandbox:

• Pay-by-link payments:
  • Polish PBLs - mTransfer - mBank (m), Płać z iPKO (p), Pekao24Przelew - BankPekao (o);
  • Czech PBLs - Česká spořitelna (cs), Komerční banka (kb);
  • Slovak PBLs - (besteron) Tatra banka, a. s. (tatra), Slovenská sporiteľňa, a. s. (sporo);
  • Additional (random) data about buyer (to retrieve with TransactionRetrieveRequest) are available only for methods:
    • Pekao24Przelew - Bank Pekao (o) (the next day)
    • Komerční banka (kb) (instantly)
• Apple Pay,
• BLIK,
• Google Pay,
• Mass Collect,
• Recurring payments,
• Installments and Pay Later,
• Pay in installments with Mastercard,
• Visa Checkout,
• PayU|Mobile (Android and iOS),
• Payouts (Panel, API),
• Statements,
• Refunds (Panel, API).

Below is a full list of payment methods available from PayU. To ensure that your customer pays only by currently available payment methods, it is strongly recommended to take advantage of automatic payment methods retrieval:

• If you are using PayU hosted payment page (payMethod PAYMENT_WALL or none), we take care of everything, including logotypes which are updated automatically.
• If you have implemented the payment methods on your own in your e-shop, you can follow these instructions.
• If you are still using Classic API (NewPayment) and you don't plan to upgrade to REST API soon, then please follow these instructions.

Thanks to this service our 24/7 monitoring takes care of the channel deactivation, if it is planned maintenance break or unexpected outage. If something as such would happen, the consumer can, e.g. pay by credit card if his bank does not handle the transfer at that point in time.

Automatic cancellation of transactions

Payment methods details

PayU | Installments is available only on PL market (read more).

Twisto | PayU Pay Later is available on PL market (read more).

PayPo | PayU Pay Later is available on PL market (read more).

Pay Later with Twisto is available on CZ market (read more).

Automatic cancellation of transactions

Payment methods details

Automatic cancellation of transactions

For Polish transfers, the automatic cancellation time for unpaid transactions is 5 days, and for transactions in the status "Waiting to be received": 10 days. The exception is the "Przelew bankowy" method, for which the automatic cancellation time is 10 days in both cases.

Payment methods details

(*) Between 23:45 and 3:15 daily cut-off operations are run which can cause breaks in payment processing.

Automatic cancellation of transactions

Payment methods details

Automatic cancellation of transactions

For Slovak transfers, the time for automatic cancellation of unpaid transactions and transactions in the status "Waiting to be received" is the same and is 10 days.

Payment methods details

Automatic cancellation of transactions

For international transfers, the automatic cancellation time for unpaid transactions and transactions in the status "Waiting to be received" is the same and is 10 days. The exception is the GiroPay (gp) method, for which the automatic cancellation time for unpaid transactions is 5 days and the automatic cancellation time for transactions in the status "Waiting to be received" is 10 days.

Payment methods details

In PayU it is possible to set two types of currency at the level of a single shop: transaction currency and billing currency.

The transaction currency determines in which currency the payer can make their payments. It also affects the availability of payment methods – payments with cards are available in any currency, and other methods (e.g. quick transfer) are only in CZK, EUR and PLN.

Billing currency determines in which currency the funds will be transferred to the merchant’s account. By default, PayU settles with the merchant in the same currency in which the transaction was processed (1:1).

Depending on the selected billing currency there may be additional fees and restrictions in payout frequency.

Below table shows the list of the transaction currencies in which PayU can settle with the merchant (1:1).

There is also available an additional ICP functionality. It allows to automatically convert transaction currency into, selected by the merchant, billing currency (currently only USD and EUR). In order to obtain further information, please contact your sales representative or get in touch with us through our contact form.

Below language parameters can be provided as language parameter in the <Buyer> object.

The table details language support in terms of paywall (a page hosted by PayU where the payer can choose from all payment methods configured on your POS), card form and email with payment-related information sent to the payer.

Host addresses

Production:

https://secure.payu.com/

Sandbox:

https://secure.snd.payu.com/

Endpoint paths

Lack of support for older protocols is for security reasons. The TLS 1.2 protocol is the best transmission encryption method compliant with the highest security standard PCI DSS 3.2.

The change applies to all transmission via HTTPS, therefore it includes all REST API and Classic API endpoints.

Majority of e-commerce solutions and hosting providers make sure that their software is up-to-date. Therefore, if your site is using such a provider, most probably you have nothing to worry about. You can contact your service providers and ask whether they have updated their software.

If your site is a custom-built solution, make sure that it uses the latest version of the protocol. The following information could be useful:

JAVA

Java 1.5 and below does not support TLS 1.2 In Java 1.6, TLS 1.2 is not supported in Oracle public updates. It is supported in the business edition starting Oracle java version 6u115 b32.

In Java 1.7, TLS1.2 is supported. But it needs to be explicitly enabled by selecting the enabled protocols while creating the SSLSocket & SSLEngine instances.

Please refer to: https://blogs.oracle.com/java-platform-group/jdk-8-will-use-tls-12-as-default for more details.

cURL

Curl supports TLS1.2 starting 7.34.0. Please use the following command to test the connection.

Note: you may use any PayU endpoint - see endpoint reference for REST API and Classic API.

curl --tlsv1.2 https://secure.payu.com/api/v2_1/orders

cURL+PHP

                    php -r '$ch = curl_init(); 
                    curl_setopt($ch, CURLOPT_URL, "https://secure.payu.com/api/v2_1/orders"); 
                    curl_setopt ($ch, CURLOPT_SSLVERSION, 6); 
                    var_dump(curl_exec($ch)); 
                    var_dump(curl_error($ch));'