Payment gateways
PayU Europe Hosted Payments — setup and reference
Configure the exact merchant fields, payment confirmation, currencies, callbacks and recovery for PayU Europe Hosted Payments.
About 4 min read
Module and release scope
This guide covers PayU Europe Hosted Payments 1.0.0, Extension API 1, from the reviewed product source. Its declared core range is 1.3.6–1.3.99. Use the matching released core and signed provider package; a version label alone does not install the required contracts. Source availability does not mean the module is bundled in every currently downloadable product, installed on your server, enabled or certified for your merchant/server account. Nothing in this guide enables a provider or changes your existing connections.
Open System → Payment gateways (newer source may group these as Payments, Domain services or Hosting services). Install the reviewed signed package through Modules & addons or the integration workspace's Install tab, enable the module separately, add an account/connection, save its own credentials, run its stated Test and explicitly enable the connection. Saving or retesting disables the connection until you enable it again. Start with the provider's test environment where supported; otherwise use an isolated account or server.
Exact connection fields
These are the fields declared by this module. Secret values are entered privately and encrypted by the application. Defaults are configuration hints, not approved live merchant settings. Internal fields are populated by the module and are not operator-editable.
| Key / label | Type | Required | Default / guidance |
|---|---|---|---|
mode — Environment |
select | Yes | Default: "sandbox" Choices: sandbox = Sandbox, live = Live |
pos_id — POS / OAuth client ID |
text | Yes | Use the account-specific value described below. |
client_secret — OAuth client secret |
secret | Yes | Use the account-specific value described below. |
second_key — Second key for notification verification |
secret | Yes | The notification signature key from the REST API POS configuration. |
This module is for PayU GPO Europe REST API 2.1, not the incompatible PayU India or Latin America APIs. Create a REST POS and supply its POS/OAuth client ID, OAuth client secret and second key (notification verification). Sandbox and live use different endpoints/accounts. Test requests only a client-credentials OAuth token.
Supported two-decimal currencies: PLN EUR USD GBP CZK RON CHF DKK NOK SEK, subject to POS approval. The real payer network address is sent; no dummy address is invented.
The module submits notifyUrl and signed continueUrl for each order. PayU notifications use OpenPayu-Signature with the POS second key per its official MD5 protocol. Notifications trigger an authenticated order read; status COMPLETED, full capturedAmount and correct POS/currency/reference are required. Refund records are checked before settlement. Browser return/reconciliation uses the server-stored order ID.
Sources: https://developers.payu.com/europe/api/ https://developers.payu.com/europe/docs/payment-flows/auth-and-order/ https://developers.payu.com/europe/docs/payment-flows/statuses/ https://github.com/PayU-EMEA/openpayu_php
Install and configure
This is an API 1 payment module for the current product source (core 1.3.6). It installs disabled and contains no account credentials. In Payments → Available, open this provider, enable its module after reviewing it, then add a merchant account. Save credentials, run Test and explicitly enable the account. Merchant onboarding and payment-method approval remain with the provider.
Only the listed invoice currencies are supported, using exact two-decimal amounts. Domain/storefront currency is not silently converted. The hosted provider page chooses methods available for the merchant, payer and country. The application never collects a card number or CVV.
The account’s full webhook URL is shown after saving. Register that one HTTPS URL for every storefront sharing the account. Browser success messages never mark an invoice paid. Pending, declined, partly paid, authorization-only and refunded payments require their actual provider state; no automatic refund is requested. Test uses authentication/read-only metadata, never a charge. API diagnostics are redacted.