To accept crypto payments on OpenCart you need three things: a payment extension in your store, an API key from a gateway, and a webhook that tells OpenCart the money actually arrived. With Payora that adds up to a free drop-in module for OpenCart 2 and OpenCart 3 that creates an invoice for the order total, sends the buyer to a hosted checkout where they pick Bitcoin, USDT, TON or another coin, and flips the order to a paid status only when a signed callback confirms the payment on-chain. The coins settle straight into wallets you control, because Payora only ever holds your public key material.
Why OpenCart stores reach for crypto
OpenCart is usually run by people who own their stack: their own hosting, their own database, their own checkout. Crypto fits that crowd for three fairly unromantic reasons.
- International buyers who cannot pay you otherwise. A card issued in one country and a shop registered in another is a coin flip. USDT on Tron does not care where either of you lives.
- No chargebacks. An on-chain payment confirms and it is done. Nobody reverses it 90 days later over a "goods not received" claim, which is the single biggest reason digital-goods sellers look at this at all. We covered that dynamic in more depth in accepting payments without a merchant account.
- No merchant account. No underwriting call, no rolling reserve, no monthly minimum, no "your category is high risk" email six weeks in.
None of this makes crypto a replacement for cards. It makes it a second lane: keep your existing methods exactly where they are, and let crypto catch the orders you were previously losing.
How to accept crypto payments on OpenCart with the Payora module
The module is a normal OpenCart payment extension. It is free, we publish it ourselves alongside the rest of our drop-in CMS modules, and setting it up is four steps:
- Install the extension into your OpenCart 2 or OpenCart 3 store and enable it as a payment method.
- Paste your API key. Create a free account at Payora, generate a key, drop it into the module settings.
- Set the webhook URL. The module exposes a callback endpoint on your own domain. Point your Payora project at it so confirmed invoices call back into your store.
- Choose your coins. Enable only the assets you actually want to receive: BTC, USDT on Tron, TON, whatever fits your buyers. You do not have to turn on all 20+.
There is nothing exotic underneath. The module speaks the same plain-JSON REST API and one-file PHP SDK a custom integration would use; it just wires that into OpenCart's payment interface so you do not have to. If you also run a WordPress store, the WooCommerce module works on exactly the same principles.
One thing worth understanding before you install: your receive addresses are derived from an xPub, a master public key. Private keys never touch the server, and payouts are signed offline. If someone owned your OpenCart host tomorrow, they could vandalise your catalogue, but they could not move a satoshi of what you had taken.
What the buyer actually sees
From the shopper's side it is short and boring, which is the goal.
- They pick Pay with crypto at checkout and confirm the order. OpenCart creates the order in a pending state.
- They land on the hosted checkout, which shows the fiat total, say 120 EUR, and a list of coins.
- They choose one. TON, for example. The page shows an exact TON amount, an address, a QR code and a countdown.
- They pay from their wallet. The page tracks the transaction and waits for that coin's finality.
- Payora fires the signed webhook at your store, the module marks the order paid, and the buyer is bounced back to your success page.
If you want to see the checkout before installing anything, the live demo is the real thing.
The order status question
When you accept crypto payments on OpenCart, this is where integrations get sloppy, so it deserves its own section. OpenCart has a configurable list of order statuses, and you have to decide which one means "the money is here".
The mapping that works in practice:
| What happened | What the order should be |
|---|---|
| Buyer sent to checkout, nothing paid yet | A pending / awaiting-payment status |
| Payment seen on-chain, not yet final | Still pending, do not fulfil |
| Signed webhook says paid | Your processing / paid status. This is the trigger |
| Invoice window expired, nothing arrived | Expired or failed, or leave it pending and cancel by hand |
Pick the paid status deliberately. If it is a status that releases a downloadable product or fires an automatic email, it must be the one that only the webhook can set. Do not reuse a status your staff also set by hand for bank transfers, or you will lose the ability to tell the two apart when you audit.
Never mark an order paid on the browser redirect
When the buyer comes back to your success page, that redirect is a request from a browser. Browsers get closed. Connections drop on a train. And a success URL can be typed in by hand by someone who never paid a cent. If your store marks orders paid on the return URL, you have built a free-goods button.
The signed webhook is the source of truth. It is a server-to-server POST carrying an HMAC-SHA256 signature over the payload, a timestamp so old captures cannot be replayed, and an idempotency key so a retried delivery does not fulfil the order twice. Verify the signature, check the timestamp window, dedupe on the idempotency key, and only then move the status. The redirect exists to show the buyer a friendly page, nothing more. If a shopper closes the tab the moment they pay, the webhook still lands and the order still completes.
Pricing when the price moves
You do not price your catalogue in Bitcoin. You leave OpenCart exactly as it is, 120 EUR stays 120 EUR, and the invoice is created in fiat. At checkout Payora converts to the coin the buyer picked and locks that amount for the invoice window. If BTC moves 3% while they fish their phone out of a pocket, the quoted amount is still the amount.
Underpayment and overpayment are judged against that locked figure rather than a live ticker, which is what keeps the paid decision unambiguous. What Payora does not do, and what no honest gateway does, is protect you from what the coin is worth tomorrow. If you want fiat certainty, take stablecoins. USDT and USDC are available on every network that carries them, and for most OpenCart stores USDT on Tron is the pragmatic default.
The honest trade-offs
Three of them, and you should know all three before you accept crypto payments on OpenCart in production.
- No chargebacks cuts both ways. Nobody can claw a payment back from you, and you cannot claw one back either. A refund is a manual outbound payment to the customer's address: a real transaction you sign, not a button that unwinds history. Decide your refund policy before your first order, not during your first dispute.
- Network fees vary, a lot. The sender pays them, but they still shape behaviour. A 2 USD Bitcoin fee on a 15 USD order is a checkout your buyer abandons. Enabling a cheap network is the fix; arguing with physics is not.
- A slow chain means a slower paid status. Finality on Bitcoin is minutes, not milliseconds. If you sell digital goods that buyers expect instantly, lead with fast networks and let BTC be the option for the people who want it.
On cost: accepting is 0%. Fees apply only when you move money out — 1.5% on payouts, transfers and withdrawals on the Free plan (0.75% on Pro, 0.5% on Business), plus the coin’s network fee (minimum withdrawal $50) — plus the on-chain network fee, which the sender always pays. The full breakdown is on pricing.
If you run an OpenCart store and you have been quietly turning away buyers whose cards do not work with you, this is an afternoon's work. Create a free account, install the module, point the webhook at your store, and enable one coin to start.
Comments