Payment Status Sync for OpenCart — match pending orders with the bank: LiqPay, monobank, WayForPay, Portmone

Payment Status Sync for OpenCart is a module for stores that take card payments. It happens: the buyer paid, the bank took the money, and the order in the admin is still waiting for payment. The paid status is set by the notification the bank sends to the site. If it never arrived (the site was down, the notification URL changed, a firewall cut the request), the order keeps waiting. Nobody ships it, the buyer writes to support, and a manager opens the bank dashboard to match payments by hand.

The module asks the bank about every order waiting for payment through the official payment status APIs of LiqPay, monobank (Mono Acquiring), WayForPay and Portmone, and shows the orders that are actually paid, with an Apply payment button. The check relies only on the status the bank returns: the module guesses nothing from the cart, e-mails or timing. Short payments, payments in another currency, holds and refunds are shown, but the order status is not changed.

It works with our payment modules for OpenCart: LiqPay, Mono Acquiring (monobank), WayForPay and Portmone. The keys are read from their settings, so you do not enter them twice.

Running WooCommerce? There is a separate plugin for it — Payment Status Sync for WooCommerce: LiqPay, monobank, WayForPay and Portmone (our gateways), plus Stripe and PayPal.

What the buyer sees

Nothing changes in the storefront or the checkout: the module adds no scripts and makes no requests from store pages. The buyer only notices the result: a paid order does not get stuck waiting for payment, it gets shipped, and nobody asks for a receipt. If Notify the customer is on in the settings, the buyer gets the usual OpenCart status e-mail.

What the admin gets

Menu item Sales > Payment Status Sync with a counter of orders that need attention, and the Monitor, Payment methods, Log and Settings pages.

• Tiles: how many orders need attention, how many wait for payment, how many were fixed in 7 days and when the last check ran.
• Payment module cards: for LiqPay, monobank, WayForPay and Portmone, whether the module is installed, whether keys are saved, test mode, two-step payments.
• Needs attention: paid at the bank while the order waits, a short payment, money on hold, an API error. Waiting means not paid yet. Closed means fixed or moved to a new status some other way.
• Buttons: Check all now, Check for one order, Apply payment (the bank is asked once more) and Dismiss, which only removes the row from the list and leaves the order itself as it is.

The line on the order page

Orders paid with one of the four modules show at the top what the bank said last and when, with the Ask the bank now and Apply payment buttons. The line can be switched off in the settings.

Payment methods

• The paid share of orders for every payment method of the store, not only the four banks but also, for example, cash on delivery, over the last 24 hours against the 14 days before.
• Dropped means the share fell by 25 points or more with at least 5 orders in the window. A sudden drop usually means the bank stopped confirming payments (expired keys, a changed notification URL, a broken checkout), not that buyers changed their minds. All thresholds can be changed in the settings.

Pro: automation and alerts

• Automatic apply: when the bank confirms the full amount in the order currency, the order gets the paid status without a click, including a lost order with no status that the order list does not show.
• Alerts to up to 5 e-mail addresses through the store mail settings and to Telegram (bot token and chat ID): one message per run with what was fixed, what needs a person (short payments, holds), API errors (at most once every 6 hours per bank) and payment method drops (once every 12 hours).
• Failed status, optional: when the checks have ended and the last word of the bank was declined or expired, the order moves from the payment module’s waiting status to its failed status. Off by default.
• Log CSV: UTF-8 with BOM, opens in Excel.

How it works, step by step

1. The module takes orders paid with one of the four payment modules whose payment log is still unpaid: orders with no status (lost), in the payment module’s waiting status, in the store’s new order status or in statuses you picked yourself. Paid and complete orders are never checked.
2. The first request goes 15 minutes after the last status change, then less and less often, up to once every 12 hours. After 72 hours the module stops asking.
3. The status request follows the bank documentation: LiqPay action=status, monobank invoice status with the merchant token, WayForPay CHECK_STATUS with the response signature checked, Portmone method=result. Keys and secrets come from the payment module settings and are decrypted the same way that module does it.
4. When the bank confirms the full amount in the order currency, the module re-reads the order and the payment log under a lock, writes the payment into the payment module log and sets the paid status through the standard OpenCart order history, just as the bank notification would: stock, coupons and e-mails work as usual.
5. A short payment, another currency, a hold or a refund only makes an entry in the monitor and the log (and an alert in Pro). If the bank does not answer or limits the request rate, the order is asked again later and nothing changes.

Under the hood

• No core edits. No OCMOD patches. The menu item and the order page line use OpenCart events. One class library is identical in the three builds, and the code is compatible with PHP 7.0.
• Own tables oc_cc_paysync_check (check state of each order) and oc_cc_paysync_log (event log). Core tables are not changed. In the payment module log only the row of the paid order is updated, with a conditional query, so a parallel bank notification is never overwritten.
• Banks in turn. A run shares the request limit between the banks and ends within 35 s even when a bank answers slowly. HTTP 429 from a bank pauses that bank until the end of the run without counting the attempt.
• Check URL index.php?route=extension/cc_paysync/cron.cron&key=… (on 3.x and 2.3: extension/module/cc_paysync_cron/cron). Without the key it returns 403. The admin buttons call the same URL.
• The licence lives in a separate settings group, so Save does not touch it.
• Uninstall removes the events and (OpenCart 4) the scheduler task and keeps the log and the check state, so a new install sees them. For a full removal, drop the oc_cc_paysync_* tables by hand.

How to install

1. OpenCart 4: Extensions > Installer > upload cc_paysync.ocmod.zip (keep the file name) and press Install. OpenCart 3: Extensions > Installer > cc_paysync-oc3.ocmod.zip. OpenCart 2.3: upload the contents of upload/ from cc_paysync-oc2.ocmod.zip to the store root (FTP or the hosting file manager). The 2.3 Installer does not copy files without a configured FTP.
2. Extensions > Extensions > Modules > CatCode Payment Status Sync > Install.
3. Sales > Payment Status Sync. The payment module cards should say checked. Press Check all now.
4. On the Schedule tab, copy the line for the hosting cron (every 5 to 10 minutes). On OpenCart 4 the check also runs every hour without it.
5. For Pro: paste the licence key from the e-mail after payment or press Try Pro for 7 days on the Licence tab.