Skip to main content

Recurring Payments

Recurring payments refer to regular and automatic transactions where a predetermined amount is charged to a customer's card at specified intervals.

Service Description

The recurring payments service is built on a white label integration, enabling you to accept card payments without redirecting users to a third-party provider's page. This approach maintains security standards, reduces PCI DSS compliance efforts, offers greater flexibility, and enhances conversion rates by providing more control over the payment process.

The payment flow consists of two steps:

  1. Securely capturing card credentials (front-end process).
  2. Charging the card through payment transaction creation (back-end process).

Card credentials are returned in the form of a token and a masked card number, ensuring that full card details are never exposed. The back-end processing is facilitated by the OpenPayU protocol, and integration is made more convenient through the use of available SDKs.

Recurring payments are processed with multi-use tokens. All transactions, except of the first one, are not initiated by the cardholder. They can be performed by a scheduler on your side at any time, even at night. Therefore, neither 3DS nor CVV authentication is required.


Before you begin integrating the recurring payments service, make sure to contact PayU via your account manager or our contact form for necessary configuration operations.

On the Sandbox environment, REST API points of sale will be configured automatically, and you'll be able to test this functionality within 90 minutes of creation.

Security Requirements and Recommendations

Before integrating the service, make sure to review the requirements and recommendations provided by our security experts. This will help you safeguard against potential fraud.

Service Integration

The recurring payments service relies on tokenization. To learn more about managing tokens, refer to the linked pages:

If you want to know more about tokenization flows and general requirements, please refer to the Card Tokenization page.

Capturing Card Credentials


For capturing card credentials, please use Secure Form.

Please remember to display all the necessary information to the payer and the approval for recurring payments as outlined in "Requirements and recommendations relating to Recurring Payments".

Integrating back-end

Standard order request should be extended by the payMethods.payMethod section and the recurring parameter, which indicates the type of recurring payment.

The recurring parameter can take two values:

  • FIRST - first payment recurring payment.
  • STANDARD - for subsequent recurring payments (user is not present).

Additionally, because each initial payment requires 3DS authentication, it is suggested to include data required by 3DS, especially recurring object in the threeDsAuthentication section. You will find more information in the section dedicated to the fields required in the 3DS standard.

Below are presented request examples for FIRST and subsequent (STANDARD) recurring payments.

curl -v -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer 3e5cac39-7e38-4139-8fd6-30adc06a61bd" \
-d '{
"recurring": "FIRST",
"buyer": {
"email": "",
"firstName": "John",
"lastName": "Doe",
"language": "en"
"payMethods": {
"payMethod": {
"value": "TOK_1JQMSW8MILUV69k0TVFZV593Riw2",
"type": "CARD_TOKEN"
"threeDsAuthentication": {
"recurring": {
"frequency": "30",
"expiry": "2025-12-31T00:00:00Z"
recurring Object

Highlighted in the above examples is the recurring object in the threeDsAuthentication section. The data provided within the recurring object will help in assigning the appropriate authentication indicator to the transaction during 3DS processing. While this object is not mandatory, we strongly recommend including it in your recurring transaction request for optimal processing.

Highlighted recurring object is different entity than recurring parameter described earlier on this page!

The POS used in examples does not have the tokenization switched on.

For details on parameters, please refer to the Create an Order section in our API Reference.

Example responses for submitting these requests are demonstrated below.

"orderId": "ORDER_ID",
"payMethods": {
"payMethod": {
"card": {
"number": "424242******4242",
"expirationMonth": "12",
"expirationYear": "2017"
"type": "CARD_TOKEN",
"status": {
"statusCode": "SUCCESS",
"statusDesc": "Request successful"

Plain Card Data Integration

Plain Card Data Integration

The description of how to create an order with plain card data can be found in the Card Data in Text Form section.