Typical picture: a customer placed an order, received payment details in response, and disappeared. Someone is too lazy to type in the IBAN manually, someone put off "I'll pay in the evening" and forgot. Or the other classic: cash on delivery, the package sits in the branch for a week, then goes back, and you pay for delivery both ways plus a COD fee. Both problems grow from the same root: the store doesn't have proper online card payment.
Standard OpenCart is no help here, and you'll see why in a moment. Let's figure out what payment methods the platform gives out of the box, what it lacks for Ukraine, and which payment modules solve this: NovaPay, LiqPay, MonoPay, and WayForPay for OpenCart 2.x and 3.x (some already support 4.x).
Payment methods in OpenCart out of the box
Open Extensions → Extensions → Payments in a clean OpenCart admin, and you'll see a list of about twenty methods: PayPal, Klarna, Authorize.Net, bank transfer, postal check, cash on delivery. The set is clearly not assembled for the Ukrainian market. There isn't a single Ukrainian payment system there: no LiqPay, no monobank, let alone NovaPay.
From the entire out-of-the-box list, only two methods really exist in Ukrainian conditions. "Cash on delivery" for COD and "Bank transfer" for payment by details, where you usually write an IBAN or card number in the description. Both are manual: you verify money with your eyes, change statuses by hand, and you can forget about instant payment confirmation. So accepting card payments online in OpenCart always means a third-party payment module.
Why transfers by details and pure COD lose money
The times of "send money to the manager's card" are gone along with financial monitoring and fiscalization, so a store has only two legal options left: an invoice by details or acquiring. And while a customer "pays the invoice in the evening," they have time to reconsider, find something cheaper, or simply forget. Every extra action between the "Checkout" button and money being debited cuts conversion, and a manual IBAN transfer is the worst option here: exit the store, open the banking app, copy the details, enter the amount and payment purpose. A buyer used to paying in one tap through Apple Pay will simply drop out at this stage.
The other side of the same problem: manual verification. Someone has to see the payment in the statement, find the order, and change the status by hand. By the time the manager gets to the statement, the customer has already called twice with "I paid, where's the package," and on weekends payments just hang until Monday. Acquiring closes this automatically: the payment system itself confirms the payment, the module itself changes the order status.
And third, which newcomers mention after their first losses: uncollected packages. Cash on delivery without prepayment means all logistics risk is on you. Prepayment of even 100–200 UAH sharply disciplines the buyer: someone calls for a package they've already paid for with completely different motivation.
Payment modules for OpenCart: what they have in common
All four modules were made by one developer (bogdan281989), so the logic is similar, and that's convenient: learn to work with one, you'll figure out the rest in five minutes. The common base is:
- HOLD (funds blocking). Money is blocked on the customer's card but not debited until the manager confirms payment from the admin. For stores that need to check product availability in stock or with a supplier first, this is a lifesaver: no product — just reject the payment, and the customer doesn't have to wait for a full refund procedure.
- Admin control. Confirmation, refunds, transaction list: everything in the OpenCart panel, without trips to the payment system's personal account.
- Flexible order statuses. Each event (successful payment, cancellation, refund) gets its own status from the System → Localization → Order Statuses list.
- Standard installation through "Extension Installer," without editing system files. After installation, don't forget to update modifiers. This is the step most often skipped, then people write to support "the module didn't appear."
- Test mode for checking integration without real debits.
Now an important technical detail that applies to all four: the modules are encoded with IonCube and activated with a license key for one domain. Before buying, check that IonCube Loader is enabled on your hosting for your PHP version: create a file with <?php phpinfo(); and search the page for the word ionCube. It's not there — contact your host or enable it in the panel. The declared PHP support is wide, from 5.6 to 8.2, but keeping a store on PHP lower than 7.4 in 2026 is a separate conversation, and not in favor of that solution.
Each module at the time of publication costs 15 USD, installation by the developer will cost another 10 USD. The license includes unlimited support. And one more detail worth knowing before payment: the WayForPay module's reseller doesn't provide license transfer to another domain, so specify the domain where the store will actually live when buying, and use a test subdomain that comes with it for development.
LiqPay: the widest functionality in the four
LiqPay API module is the most "packed" of the four. It's actually a package of three modules: main payment, separate prepayment method (fixed amount or percentage), and a copy of the main module with separate API keys for the eSupport program.
What the main module can do:
- Card payment, Apple Pay, Google Pay, Privat24, invoice to email, QR code.
- Two modes: classic redirect to liqpay.com or embedded widget, when the payment form appears right on the checkout page without switching to an external site. The widget for the cart works in a popup.
- Two-stage payment (Hold) with confirmation from the admin.
- Fiscalization: sending product data (object
rro_info) to LiqPay to form fiscal receipts, with choice of article (model, sku, ean, etc.). The developer honestly warns in the changelog: the feature is being tested, verify the fact of receipt issuing yourself. This is exactly the level of honesty you want to see more often. - Separate sections "Liqpay Transactions" and "Liqpay Products" appear in the admin under the "Sales" menu, and in the order card — a Liqpay button: view the transaction via API, generate a payment link, send it to the customer by email.
Current version 2.3.0 (June 2026) migrated to LiqPay API v7 with callback verification. Supported versions: OpenCart 2.1–2.3 (PHP 5.6–7.4) and OpenCart 3.x (PHP 7.3–8.2), with 4.1.0 mentioned in technical details.
MonoPay: monobank acquiring, including OpenCart 4.x
MonoPay module connects monobank internet acquiring through the official API. For the customer, it's the familiar mono payment interface, and trust in the payment form directly converts to completed payments.
Functionality: HOLD with confirmation or refund from admin, automatic order status changes for payment events, invoice creation from the admin panel, test mode. Compatibility: OpenCart 2.x, 3.x, and 4.x (4.1.0 is in the version list). If you've already moved or plan to move to the fourth branch, this is an important argument: far from all payment modules on the market have even seen version four. Current version 1.7.2.
NovaPay: Nova Poshta acquiring plus prepayment against uncollected packages
NovaPay module integrates Nova Poshta's acquiring into OpenCart 2.x–3.x. The logic is obvious: if 90% of your shipments go through Nova Poshta anyway, payment in the same ecosystem feels natural to the customer.
The module's main feature — a built-in prepayment plugin. You set a deposit with a fixed amount (say, 200 UAH) or a percentage of the order, and it's exactly what protects you from the scenario "package went back and forth on your dime." For stores with cheap goods and a high share of COD, this one plugin can pay for itself faster than everything else combined.
The rest of the set is standard for the line: HOLD, full or partial refund from admin, separate transaction list with detailed statuses, exclusion of certain cart totals from the payment amount, error page with retry, internal log for API diagnostics.
To get started, you need a sole proprietor or LLC and an acquiring agreement with NovaPay, then get API keys from the cabinet and enter them in the settings. This, by the way, applies to any official acquiring: no one will connect it to a private person.
WayForPay: two payment modes and invoices
WayForPay API module closes integration with the eponymous payment service for OpenCart 2.1–3.x (with 4.1.0 also mentioned in technical details). WayForPay is traditionally chosen when working with multiple banks and a large selection of payment instruments on the service's side.
From the module's capabilities:
- Two modes: redirect to the payment system's page or payment in an embedded widget without switching.
- Blocking funds until the manager manually confirms.
- Invoices: arbitrary invoice manually, automatic generation from order data, accepting prepayment for any order via invoice.
- List of transactions and details for a specific order right in the admin.
- Logging payment system responses. When a payment "doesn't arrive," the log answers the question in a minute instead of an hour of correspondence with payment support.
In terms of code openness, the situation here is best in the four: only one admin file is encoded with IonCube, the rest is open for editing. For a developer who needs to tweak something for a project, this is a notable advantage. Current version 2.1.1 (June 2026).
What to check before installation
A few things people stumble on most often:
IonCube Loader. Without it, modules won't run at all. Checked through phpinfo(), enabled on the hosting.
HTTPS and callback. The payment system confirms payment with a server request to your site. If the SSL certificate is expired or the callback address is blocked by a firewall or security module, orders will hang in "pending payment" status, even though money has already been debited. Recognizable symptom: customer calls "I paid," and there's silence in the admin.
Order statuses. Before configuring the module, think through your status scheme: what "paid" means, what "hold confirmed" or "refund" means. If you hang everything on the default Processing, you'll break your neck with reports later.
Test run. Each module has a test mode. Run through a full cycle: payment, callback, status change, letter to customer. Only then enable production keys.
Who doesn't need card payments in OpenCart
Honestly: not everyone. If you work exclusively B2B with payment by invoices through accounting, card acquiring won't give you anything. If a store has three orders a week, the acquiring commission and setup time will hardly pay off quickly: start with free bank transfer and return to modules when a flow appears. And if you don't have a sole proprietor or LLC — first registration, then acquiring, it won't work the other way around.
For everyone else, the math is simple: prepayment cuts uncollected packages, one-click payment cuts abandoned carts, and managing payments from the admin saves the manager an hour or two a day. Against this background, 673 UAH for a module is not the expense to economize on.
Online payment connection checklist
- Register a sole proprietor/LLC if you haven't already, and sign an acquiring agreement with your chosen payment system.
- Check IonCube Loader on your hosting through
phpinfo(). - Check your PHP version: for OpenCart 3.x the target range is 7.3–8.2.
- Make sure the SSL certificate is valid and won't expire soon.
- When buying a module, specify the correct production domain (especially for WayForPay, where license resale is not available).
- Install the module through "Extension Installer" and update modifiers.
- Create separate order statuses for payment events (System → Localization → Order Statuses).
- Get API keys from your payment system's account and enter them in the module settings.
- Run through a full cycle in test mode: payment → callback → status → customer email.
- If you work with cash on delivery, enable prepayment (NovaPay and LiqPay have separate modules for this included).
- After launch, watch the module log and transaction list for a week: discrepancies between payments and statuses show up right there.
