¶ PayU - online payments and PayPo (REST API 2.1)
PayU in Hummerce is an online payment configured through REST API 2.1 - with data pulled directly from the store's PayU panel. The integration also supports the deferred payment PayPo, available only in this newer API version, and syncs the payment methods offered by PayU on its own.
As of Hummerce version 2.35.65, last updated 2026-10-07.
¶ Benefits and use cases
- Online payment compliant with PayU's current interface - REST API 2.1.
- Support for the deferred payment PayPo - available only through REST API, not through the older Classic API module.
- Automatic sync of payment methods with PayU - new methods appear in the store panel on their own, and methods disabled in PayU disappear from the cart, while payments without a specific method are left untouched.
- Method preselection - a customer who picks a specific PayU method in the cart (e.g. BLIK) goes straight to that method's payment page, without choosing the method again at PayU.
- Secure verification of payment notifications thanks to a signature from the second key (
OpenPayu-Signature). - Separate test (Sandbox) and production environments - the payment can be checked before going live.
- The PayU payment point can have additional methods enabled - installments or BLIK (a Polish mobile payment method), depending on the store's PayU account settings.
¶ What it looks like
¶ How it works
¶ Two integration versions
- Up to version 2.33, the PayU Classic API module was used.
- In newer stores, we use PayU REST API 2.1.
- PayPo payment is supported only through REST API - Classic API doesn't support it directly.
¶ Payment methods sync
- The store periodically (every 24 hours by default) fetches the list of payment methods available for the store's PayU payment point.
- The sync covers payments that have Online payment type: PayU REST API set in the panel. The last field of this setting points to the specific PayU method (e.g. BLIK, Google Pay).
- New method in PayU - the store creates it as a sub-payment of the main PayU payment, inactive and hidden, with its name and logo from PayU. Enabling it in the cart is always the administrator's decision.
- Method disabled in PayU or no longer offered by PayU - the store disables the matching payment (inactive and hidden). This applies only to payments bound to a specific PayU method.
- A payment without a specific method (the main payment, or a general one where the customer picks a bank on the PayU page) and methods on the ignore list are not changed by the sync - they stay as the administrator set them.
- The sync doesn't enable payments and doesn't overwrite a name or logo set manually in the panel.
- When PayU is temporarily unavailable or returns an empty list, the store changes nothing.
¶ Main PayU payment
- The main payment (grouping PayU methods, e.g. a bank transfer with bank selection on the PayU page) must have the symbol
payuRest. - A payment with the PayU REST API type that points to a specific PayU method is disabled during sync when PayU stops offering that method. A payment with this type that has no method specified (e.g. a general one with bank selection on the PayU page) isn't disabled.
- The specific PayU method set on a payment also works as a preselection: after choosing such a payment in the cart, the customer is redirected straight to that method in PayU (from version 2.35.23). A payment without a method shows the customer the method chooser on the PayU page.
- Without the main
payuRestpayment, the store doesn't create new methods - it only updates and disables existing ones.
¶ Data needed for configuration
- The customer gets all the data from the PayU panel (test environment: Sandbox), in My store -> Payment points -> Configuration keys: the payment point identifier (POS ID), OAuth protocol data (Client ID and Client Secret), and a second (MD5) key to verify notification signatures.
- Also needed: the public address of the production store's admin panel (the store sends it to PayU as the notification address with each transaction, so it doesn't need to be set in the PayU panel), currencies supported by the payment point (PLN by default), and whether the payment point has PayPo, installments, or BLIK enabled.
- Test and production environment keys are different - for a multi-stage implementation, it's worth asking the customer for both sets at once.
¶ Version
- Up to version 2.33 - integration through PayU Classic API.
- In newer implementations - integration through PayU REST API 2.1, the only one supporting PayPo payment.
- From version 2.35.22 - automatic sync of payment methods with PayU.
- From version 2.35.23 - preselection of the PayU payment method based on the payment chosen in the cart.
- From version 2.35.24 - the main
payuRestpayment isn't disabled by the sync. - From version 2.35.65 - the sync disables only payments bound to a specific PayU method that PayU no longer offers; payments without a method and methods on the ignore list stay unchanged.
¶ Dependencies
- An account and payment point (POS) set up in the store's PayU panel - set up and configured by the store on its own.
- OAuth protocol data (Client ID, Client Secret) and a second (MD5) key from the PayU panel.
- The production store's admin panel reachable from the internet - PayU sends payment notifications to its address.
- Currencies supported by the payment point in PayU (PLN by default).
- For payment methods sync - a main payment with the symbol
payuRestin the store panel.
¶ Implementation
- Requires implementation - the payment doesn't launch itself; it requires entering data from the PayU panel (POS ID, Client ID, Client Secret, second key) and selecting the environment (Sandbox or Production).
- Minimum estimated time: no minimum time - to be filled in.
- What the time depends on:
- the number of currencies and additional methods (PayPo, installments, BLIK) to test on the payment point,
- whether the customer provides the full set of test and production data right away,
- when moving from the old PayU module - the number of existing PayU payments to tidy up before enabling the sync (main payment symbol, payment type and PayU method for the others, removing unused ones),
- the store's version - older than required for REST API 2.1 needs updating first (quoted separately).
¶ Limitations
- PayU Classic API (older stores, up to version 2.33) doesn't support PayPo payment directly - it requires REST API 2.1.
- The sync only disables payments and creates new ones as inactive - enabling a method in the cart, ordering, and grouping are set by the administrator.
- The sync disables only payments with a specific PayU method that PayU no longer offers. Methods that should stay enabled despite changes on the PayU side can be added to the ignore list.
- We do not verify the task for legal compliance - terms of service and payment information are the store's responsibility.
¶ Frequently asked questions
Does PayU support PayPo payment?
Partially. PayPo only works through the REST API 2.1 integration - the older Classic API module doesn't support it.
Will a new PayU payment method appear in the store automatically?
Yes, in the store panel - as inactive and hidden. It appears in the cart only after the administrator enables it.
Why did a PayU payment disable itself?
The sync disables it when PayU reports the method as inactive or no longer offers it for the store's payment point. Only payments bound to a specific PayU method are disabled - the main payment and a payment without a specified method (with bank selection on the PayU page) are not, nor are methods on the ignore list. Check the Online payment type setting and the specified method, then enable the payment again.
How often does the store sync payment methods with PayU?
Every 24 hours by default. The interval is set in the module configuration, and 0 turns the sync off.
Can a customer go straight to a chosen PayU method, e.g. BLIK?
Yes, from version 2.35.23. If the payment in the cart points to a specific PayU method, the customer goes straight to that method after choosing it, without choosing again at PayU.
Where do I get the data to configure PayU?
From the PayU panel, in the My store -> Payment points -> Configuration keys section.
Do I need to set the notification URL in the PayU panel?
No. The store passes the notification address to PayU with each transaction - the store's admin panel just needs to be reachable from the internet.
Are PayU's test and production environment data the same?
No. Sandbox and production keys are different - both sets need to be provided for the implementation.
Does Hummerce still support the older PayU integration (Classic API)?
Yes, stores from before version 2.34 can keep using it, but it supports neither PayPo payment nor payment methods sync.
How long does implementing PayU payment take?
We determine the implementation time individually after analyzing the scope.
¶ Related
- Payments - overview
- PayPal, Przelewy24 and BLIK - other online payments in the Hummerce standard.
- On hummerce.com: PayU integration (in Polish), B2C platform (in Polish).
Want to see how PayU payment could work in your store? Book a free demo (in Polish).
¶ Configuration details
¶ Parameters
| Field in the PayU panel | Store parameter | Description |
|---|---|---|
| POS ID / Payment point ID | merchantPosId |
Public POS identifier |
| OAuth protocol - Client ID | clientId |
Usually equal to POS ID |
| OAuth protocol - Client Secret | clientSecret |
OAuth 2.0 secret (not to be confused with the "MD5 key" from the old API) |
| Second key (MD5) | secondKey |
Used to verify the OpenPayu-Signature notification signature |
| Environment | mode |
PROD or SANDBOX |
¶ Payment methods sync
| Store parameter | Default | Description |
|---|---|---|
syncIntervalHours |
24 | How often (in hours) the store fetches payment methods from PayU; 0 turns the sync off |
ignoreValues |
empty | Comma-separated list of PayU method codes (e.g. blik,mtex) that the sync doesn't create, update or disable |
syncBrandImages |
off | When on, the payment logo is updated to the PayU logo (overwrites a logo uploaded manually) |