BazPay for OpenCart 4

Install the extension

Five screens, about half an hour including the test order. OpenCart splits installing an extension from enabling it, and the permissions step in the middle is the one that trips people up.

1. Upload the ocmod

   Extensions → Installer, then upload bazpay.ocmod.zip. Wait for the progress bar to finish rather than navigating away; OpenCart writes files during that step.

2. Grant permissions

   System → Users → User Groups, edit your administrator group and tick both access and modify for the BazPay payment route. Skipping this produces a permission error at the next step that looks like a broken install but is not.

3. Enable the payment method

   Extensions → Extensions → Payments, find BazPay, press the install button, then edit it. Paste the sandbox keys and set the status to Enabled.

4. Map the statuses

   Still on the edit screen. The four select boxes decide what an order looks like at each stage — see the next section for what to choose and why the defaults are not always right.

5. Place a test order

   Use a card from the testing guide. The order should reach your success status without any action from you. If it does not, probe the webhook route with the listing below.

# the webhook is a normal front-end routecurl -i 'https://shop.example/index.php\  ?route=extension/bazpay/payment/bazpay.webhook'​# healthy: the route exists and refuses an unsigned requestHTTP/2 401content-type: application/json​# a redirect to the storefront means the route is not registered:# reinstall the ocmod and refresh the modification cache

Run this from outside the server. A 401 is the healthy answer here — it means the route exists and is correctly refusing an unsigned request.

Map the order statuses

OpenCart lets you decide which of your own statuses each payment outcome produces, which is more flexible than the fixed mapping other carts use and easier to get subtly wrong.

What this build does not do

Published here rather than in a footnote, because finding a limit after installing is worse than finding it before. Everything below is available through the API — the extension simply does not put a control in the OpenCart admin for it.

• Partial refunds The admin button refunds in full. Partials go through the API, or through us.
• Delayed capture Payments are captured at authorisation. There is no authorise-now, capture-on-shipment mode in this build.
• Stored credentials No vaulting UI and no subscription support. Tokenised repeat billing is API-only on OpenCart.
• Apple Pay On the 4.1 branch, in testing. Google Pay is available now.
• Per-store method mix Keys are per store, but the enabled method list is shared across the storefronts.
• Dispute handling in the admin Chargebacks arrive by email and appear in the dashboard, not in the OpenCart order view.

If two or more of those are things you do weekly, the honest recommendation is to drive payments from your own tooling against the API rather than to fight the extension. The custom stack guide covers what that costs in engineering days.

Themes and custom checkouts

The extension registers through OpenCart's standard payment route, so any checkout that asks OpenCart for the available methods will display it. Commercial themes that replace the checkout entirely sometimes build that list themselves, and then two things are needed.

• Our script include added to the theme's checkout template, so hosted fields can mount.
• The payment route called through OpenCart's method list rather than a hard-coded array.

Both are small changes and any theme developer will recognise the request. If you are choosing a theme now, prefer one that leaves the checkout controller alone — it will save you this conversation with every extension you ever install, not just this one.

Going live

Swap the sandbox keys for live ones and change the environment setting. Nothing else needs to move: the status mapping, the enabled methods and the webhook registration all carry over.

• Place one real low-value order and refund it, to prove both directions on live keys.
• Confirm the descriptor on the statement is the shop name a customer will recognise.
• Check the failed-order status is not in any fulfilment report you run.
• Turn debug logging off once the first day of real orders looks correct.

The full pre-launch list, including the underwriting documents and the twelve technical checks, is in the go-live guide.

Common questions

Why is this connector smaller than the others?

Because the stores that run OpenCart are usually smaller too, and a build that mirrors the Magento feature set would mean more settings to misconfigure for capabilities most of these merchants will never switch on. Everything left out is still reachable through the API, and the limits are listed on this page rather than discovered later.

Can I take partial refunds at all?

Yes, through the API or by asking support, but not from a button in the OpenCart admin. The admin refund control sends a full refund only. If partial refunds are part of your everyday workflow, that is a genuine reason to weigh a different platform or to drive refunds from your own back-office tooling.

Does it work with Journal or another commercial theme?

In most cases yes, because the extension registers through the standard payment route. Themes that replace the checkout with their own one-page version sometimes build the payment list by hand, and then our script include has to be added to that template — a five-minute job for whoever maintains the theme.

Which methods can an OpenCart store offer?

Cards, iDEAL, Bancontact, BLIK, Przelewy24, EPS, Google Pay and SEPA Direct Debit as a one-off collection. Apple Pay needs the 4.1 branch, which is in testing. The full matrix, with markets and refund behaviour, is on the method reference page.