Foreign-market payments in Hummerce are a set of modules for local payment providers - PayU Classic, TrustPay, Paysera, mobilPay, Payline and Ingenico (Barclaycard ePDQ) - that let a store accept payments popular outside Poland, for example in the Czech Republic, Slovakia, Lithuania, Romania, France, Belgium and the Netherlands. Each module redirects the customer to the provider's page, then receives the result and sets the order's payment status.
Last updated: 2026-10-16.
¶ Benefits and use cases
- Local payment methods in the target market - customers pay the way they are used to paying in their country: by transfer through their own bank, by card or by instant bank transfer.
- One payment logic for all markets - the modules work in the same mechanism as other Hummerce payments: assigned to views, with their own messages, retry and payment change. The mechanism is described on the Payments - overview page.
- Separate terms in each market - each market can have its own agreement with the provider, its own payment and its own store views.
- Automatic statuses - when the payment ends, the module sets the order's payment status (paid, not paid, partially paid, canceled), so store staff don't reconcile payments by hand.
- Test mode - each module can first be run against the provider's test environment (for providers that offer one).
| Provider |
Market |
Payment methods |
What the integration does |
| PayU Classic |
Czech Republic, Slovakia, Lithuania |
card, bank transfers (each bank as a separate payment), other methods offered by PayU |
redirect to the PayU page, receiving the status, payment statuses, test mode |
| TrustPay |
Slovakia |
bank transfer, TrustPay internal transfer, Paysafecard, card |
redirect, receiving the notification, statuses, amount check |
| Paysera |
Lithuania |
bank transfers chosen on the Paysera page |
redirect, receiving the notification, statuses, amount check |
| mobilPay |
Romania |
card |
redirect to the provider's page, receiving the confirmation, statuses |
| Payline |
France |
payment on the Payline page |
redirect, receiving the result, statuses |
| Ingenico (Barclaycard ePDQ) |
Belgium, the Netherlands |
methods enabled in the provider's account |
redirect, signed request and response, statuses |
In every module, refunding money to the customer is done in the provider's panel - the module does not order a refund from the store.
¶ A separate payment point per market and currency
Each integration has one set of access data for the provider (an account, project or point of sale). If a store sells in several markets or currencies and wants to settle them separately, we set up a separate payment point with the provider and a separate payment in the store, assigned to the right views. The payment currency comes from the order currency.
- An older PayU integration - the classic API, in which the customer returns to the store after finishing the payment on the PayU page. The current REST integration is described on the PayU page.
- Each bank or payment method is a separate payment in the store, mapped in the configuration to a PayU method.
- Payment statuses: prepared, verified, finished, canceled, denied, pending, error - with a separate set for test mode.
- One PayU account works in one store; another market needs a separate payment point and a separate configuration.
- Each TrustPay method (bank transfer, internal transfer, Paysafecard, card) is a separate payment in the store with the TrustPay payment type set.
- TrustPay statuses are mapped to store statuses (paid, not paid); when the amount in the confirmation differs from the order amount, the payment gets the Partially paid status.
- The configuration covers the countries, languages and currencies the payment is available in, and the payment description passed to the provider.
- There is one Paysera payment in the store; the customer chooses the bank after the redirect, on the provider's page.
- Paysera statuses are mapped to store statuses; when the amount in the notification differs from the order amount, the payment gets the Partially paid status.
- The configuration covers the default language and country, the list of allowed countries, the payment message and test mode.
- The provider verifies the project before production payments are switched on.
- Supports card payment only - the store sends a signed request to the provider and receives a confirmation.
- Statuses in the confirmation are grouped into paid, canceled and pending; assigning values to the groups is a module setting.
- Payer data (first name, last name, address, e-mail, phone) is passed from the order.
- The customer is redirected to the Payline payment page, and when it ends the store checks the transaction result.
- A payment counts as successful when its result code is on the list set in the Paid status codes setting.
- The configuration covers the merchant ID, the access key and test mode.
- The customer is redirected to the Ingenico payment page, where they choose the method and enter the payment details; the request and the response are signed.
- Payment statuses reflect the provider's status: authorised, paid, refused, processing, canceled by the customer, unknown.
- With the order, the store saves, among other things, the transaction ID, the card brand and the error code returned by the provider.
The modules come from older platform versions and have worked for a long time - no newer changes are recorded in version announcements. The current PayU, Przelewy24 and PayPal integrations on newer APIs are described on their own pages.
- An agreement and access data with each provider - arranged by the store directly with the provider, separately for each market.
- The payment set up on the store's payment list and assigned to the right views and delivery methods (Delivery methods - overview).
- The provider's return and notification addresses - we supply them during implementation.
- Requires implementation - no module turns on by itself. Scope: entering the access data and choosing test or production mode (some settings in the panel, some in the store's configuration files), setting up the payment on the payment list and assigning it to views, setting the messages, adapting the payment pages in the template, testing on the provider's test environment.
- The Bootstrap 4 and Bootstrap 5 templates have ready-made payment pages for PayU Classic, TrustPay, Paysera and Ingenico.
- Minimum estimated time: from 20 h per provider, not counting time waiting for the agreement and verification on the provider's side.
- What the time depends on:
- the number of providers, markets and currencies (each market settled separately means a separate payment point and a separate configuration),
- the number of payment methods at one provider (e.g. each bank as a separate payment),
- how much the look of the payment pages and the messages need to be adapted in the template, and the number of languages,
- the time it takes to activate the account or project on the provider's side,
- the store version - an older version needs an update first (quoted separately).
- Each provider requires a separate agreement and access data, and some providers verify the project before production payments are switched on.
- One set of access data per module - another market or a currency settled separately is handled by a separate payment point and a separate payment in the store.
- The module does not refund money - refunds are made in the provider's panel.
- mobilPay supports card payment only.
- The modules come from older platform versions - before launch we check with the provider that the interface and certificates are still current.
- We do not verify the task for legal compliance (e.g. the store's terms, payment information and data protection in a given market).
- Refunding money to the customer from the order in the store, without going to the provider's panel.
- Moving selected markets to the providers' newer integrations, where the provider offers them.
Does Hummerce support local payments outside Poland?
Yes. The platform has modules for PayU Classic (Czech Republic, Slovakia, Lithuania), TrustPay (Slovakia), Paysera (Lithuania), mobilPay (Romania), Payline (France) and Ingenico (Belgium, the Netherlands).
Can one payment serve several markets or currencies?
No. Each module has one set of access data, so each market settled separately has its own payment point with the provider and its own payment in the store, assigned to its own views.
Does the store refund money to the customer from the order?
No. Refunds are made in the provider's panel, and the store only receives the payment status.
Does every provider have a test mode?
The modules have a switch between test and production mode. Whether a test environment exists depends on the provider - we check this during implementation.
How long does it take to launch a foreign-market payment?
From 20 h per provider, not counting time waiting for the agreement and verification on the provider's side. The exact time depends on the number of markets, methods and how much the template is adapted.
What limitation do customers most often overlook?
Each market settled separately needs its own agreement and its own access data with the provider - it is not enough to add a country to an existing payment.
Want to see how foreign-market payments could work in your store? Contact the Hummerce team (in Polish).
- Configuration -> Payments - setting up the payment for a given provider, assigning it to views, linked delivery methods, payment messages.
- Module settings in the panel, in the groups: PayU, Paysera, Payment MobilPay, Payline, Trust Pay. Ingenico is configured by the implementer in the store's configuration files.
The modules save information about the payment on the order, visible in the order details:
| Provider |
Data saved |
| TrustPay |
payment status, payment type, transaction type, transaction ID |
| Paysera |
payment type, payment status, error code |
| mobilPay |
error code and message |
| Ingenico |
acceptance, transaction ID, card brand, transaction date, error code, payment status |