django-payments-payu 2.1.1

PayU payments provider for django-payments

NOTE: This project is still in development, so use with extreme caution.

PayU payments provider for django-payments. Uses the new PayU REST API. Supports normal, express and recurring payments.

Documentation

The full documentation is at https://django-payments-payu.readthedocs.io.

Quickstart

Install django-payments and set up PayU payment provider backend according to django-payments documentation:

This backend implements payments using PayU.com.

Set up the payment provider:

Example:

# use sandbox
PAYMENT_VARIANTS = {
    'payu': ('payments_payu.provider.PayuProvider', {
        'pos_id': '123456',
        'second_key': 'iseedeadpeople',
        'client_secret': 'peopleiseedead',
        'sandbox': True,
        'capture': False,
        'get_refund_description': lambda payment, amount: 'My refund',
        'get_refund_ext_id': lambda payment, amount: str(uuid.uuid4()),
        'get_buyer_language': lambda payment: 'cs',
    }),
}

Here are valid parameters for the provider:

client_secret:

PayU OAuth protocol client secret

pos_id:

PayU POS ID

second_key:

PayU second key (MD5)

shop_name:

Name of the shop send to the API

sandbox:

if True, set the endpoint to sandbox

endpoint:

endpoint URL, if not set, the will be automatically set based on sandbox settings

recurring_payments:

enable recurring payments, only valid with express_payments=True, see bellow for additional setup, that is needed

express_payments:

use PayU express form

widget_branding:

tell express form to show PayU branding

store_card:

(default: False) whether PayU should store the card

get_refund_description:

An optional callable that is called with two keyword arguments payment and amount in order to get the string description of the particular refund whenever provider.refund(payment, amount) is called. The callable is optional because of backwards compatibility. However, if it is not set, an attempt to refund raises an exception. A default value of get_refund_description is deprecated.

get_refund_ext_id:

An optional callable that is called with two keyword arguments payment and amount in order to get the External string refund ID of the particular refund whenever provider.refund(payment, amount) is called. If None is returned, no External refund ID is set. An External refund ID is not necessary if partial refunds won’t be performed more than once per second. Otherwise, a unique ID is recommended since PayuProvider.refund is idempotent and if exactly same data will be provided, it will return the result of the already previously performed refund instead of performing a new refund. Defaults to a random UUID version 4 in the standard form.

get_buyer_language:

An optional callable that is called with with the keyword argument payment in order to get the language for the hosted payment page and e-mail messages sent from PayU to the payer. Consult the documentation for an up-to-date list of supported language codes and their capabilities. When not set, a default value of en will be used.

NOTE: notifications about the payment status from PayU are requested to be sent to django-payments process_payment url. The request from PayU can fail for several reasons (i.e. it can be blocked by proxy). Use “Show reports” page in PayU administration to get more information about the requests.

Recurring payments:

If recurring payments are enabled, the PayU card token needs to be stored in your application for usage in next payments. The next payments can be either initiated by user through (user will be prompted only for payment confirmation by the express form) or by server. To enable recurring payments, you will need to set additional things:

NOTE: Recurring payments are not enabled by default even in Sandbox, you sould consult their helpdesk to enable this.

• In order to make payments recurring, the card token needs to be stored for the Payment’s user (not just the payment itself). Implement the Payment.set_renew_token() and Payment.get_renew_token().

• Implement Payment.get_payment_url().

• For the server initiated recurring payments you will need to create the new payment and then call payment.autocomplete_with_wallet().

  • The method returns either string ‘success’ or url where the user can provide his CVV2 or 3D secure information.

  • The 'success' string means, that the payment is waiting for notification from PayU, but no further user action is required.

Example of triggering recurring payment:

payment = Payment.objects.create(...)
redirect_url = payment.autocomplete_with_wallet()
if redirect_url != 'success':
    send_mail(
        'Recurring payment - action required',
        'Please renew your CVV2/3DS at %s' % redirect_url,
        '[e-mail]',
        [user.email],
        fail_silently=False,
    )

Running Tests

Does the code actually work?

source <YOURVIRTUALENV>/bin/activate
(myenv) $ pip install tox
(myenv) $ tox

Credits

Tools used in rendering this package:

• Cookiecutter

• cookiecutter-djangopackage

History

2.1.1 (2026-05-07)

• fix create_order demoting an already CONFIRMED payment to ERROR when PayU rejects a duplicate request (e.g. the user’s browser POSTs to the process URL again after 3DS while a parallel webhook has already confirmed the payment). The existing narrow guard for ERROR_ORDER_NOT_UNIQUE is generalised to keep CONFIRMED state regardless of PayU’s rejection reason.

2.1.0 (2026-01-24)

• add optional get_buyer_language argument to PayuProvider

2.0.0 (2025-05-29)

• implement the wallet logic

• change extra_data with atomic operations to reduce concurrent problems

• support Django 5.2

• drop support for Python 3.7

• log error if the payment is switching status out from confirmed

• fix log warning if the payment is switching status out from confirmed

1.5.0 (2024-08-16)

• log warning when status changes out from confirmed

• fix problem with form in Django 5.0

• support Django 5.1

1.4.6 (2024-07-23)

• remove debug code committed by mistake

1.4.5 (2024-07-23)

• fix safestring in Django 5.0

1.4.4 (2024-06-27)

• fix PayuApiError: invalid response to refund

1.4.3 (2024-05-15)

• fix “AttributeError: Manager isn’t accessible via Payment instances” introduced in 1.4.1

1.4.2 (2024-05-14)

• fix multiple deduction of the refund amount from payment.captured_amount

• change statuses of payments refunded with an amount greater than payment.captured_amount to REFUNDED instead of just deducing captured_amount

1.4.1 (2024-05-14)

• fix captured_amount not being saved when processing data

1.4.0 (2024-04-12)

• fix backward compatibility by making PayuProvider’s get_refund_description argument optional

• add renewal_triggered_by parameter to payment.set_renew_token

• make PayuProvider.refund fail if get_refund_description is not provided

• make PayuProvider.refund raise PayuApiError if an unexpected response is received

• deprecate the default value of get_refund_description; set it to a callable instead

• deprecate automatic_renewal parameter of payment.set_renew_token; use renewal_triggered_by parameter instead

• deprecate None value of renewal_triggered_by parameter of payment.set_renew_token; set “user”/”task”/”other” instead

1.3.1 (2024-03-19)

• Fix description on PyPI

1.3.0 (2024-03-19)

• add get_refund_description and get_refund_ext_id arguments to PayuProvider

• add PayuProvider.refund

• update payment.captured_amount only when order is completed

• subtract refunds from payment.captured_amount rather than from payment.total

• rename PayuProvider.payu_api_order_url to payu_api_orders_url

• tests for Django 2.2-5.0 Python 3.7-3.12

1.2.4 (2022-03-17)

• treat partial refunds

• tests for Django 2.2-4.0 Python 3.7-3.10

1.2.3 (2022-01-25)

• better distinct PayU API errors

1.2.2 (2021-11-30)

• solve the duplicate order case that errored already confirmed payment

1.2.1 (2021-10-29)

• set fraud status if PayU anti-froud error

• store PayU error on payment

1.2.0 (2021-10-11)

• user Payment.billing_* correctly - the functions like get_user or get_user_email, get_user_first_name and get_user_last_name were redundant and are not called anymore.

• Shop name is taken from provider configuration variable shop_name

1.1.0 (2021-10-05)

• redirect to payment.get_failure_url() after API error, log the error

1.0.0 (2020-10-21)

• first major release

• many fixes

• recurring payments working

• proved by production environment

0.3.0 (2020-05-30)

• fix amount quantization

• add store_card parameter

• fix base url parameter for express form

0.2.0 (2020-04-13)

• Second release

• Fixed testing matrix

0.1.0 (2020-04-06)

• First release on PyPI.

• Still in development.