How to Accept Crypto Payments on Magento and PrestaShop

Magento and PrestaShop occupy a specific niche: merchants who self-host, want control over their stack, and have outgrown hosted platforms. That profile tends to hit the limits of conventional payment processing earlier than most – international customers, unusual product categories, and no appetite for a processor that can close the account.

Adding Magento crypto payment support, or the PrestaShop equivalent, is straightforward once the prerequisites are in order. This guide walks through both platforms, the wallet decisions that matter more than the installation, and the errors that surface during the first live orders.

Why Do These Platforms Need a Crypto Option?

Self-hosted stores share characteristics that make crypto unusually useful.

They are often international. Magento in particular is common among B2B and cross-border merchants, where card acceptance is inconsistent and conversion costs are high. A wallet address works identically everywhere.

They sell things processors dislike. Self-hosting is frequently a response to platform restrictions in the first place. Merchants in restricted categories benefit directly from a payment method with no category pricing.

Chargebacks hurt more. Magento and PrestaShop stores skew toward higher average order values. A single disputed $800 order costs considerably more than a $30 one, and for digital or made-to-order goods the merchant usually loses.

They have the technical capacity. Unlike a hosted-platform merchant, a self-hosted store already has someone who can install an extension, configure a callback URL and read a log. The setup effort that deters others is routine here.

• Works for customers whose cards fail on cross-border transactions
• No category-based pricing or rolling reserves
• Chargebacks eliminated on confirmed payments
• Settlement in seconds rather than a payout cycle
• Full control, consistent with why the store is self-hosted

What You Need Before Installing?

Preparing these four items first prevents most failed setups, on either platform.

A wallet you control. Create it, write the recovery phrase on paper, and test restoring from it before receiving anything real. This is the step people skip and the only one that cannot be fixed later.

An extended public key (xpub). The stronger approach is to let the gateway derive a fresh receiving address per order from your xpub. It can generate addresses but cannot produce the private keys that spend from them. The alternative – one static address for every order – works but makes reconciliation guesswork the moment two customers pay identical amounts.

API credentials from your gateway account, plus a webhook secret if the provider issues one.

A publicly reachable HTTPS callback URL. The gateway posts payment updates to your store. If the URL sits behind HTTP basic auth, an IP allowlist, a firewall rule or a staging password, callbacks will silently never arrive and orders will sit pending forever. This is the single most common cause of “the plugin doesn’t work.”

Also have a small amount of each chain’s native token available – useful for testing and necessary later for refunds.

Magento: Extension Setup Step by Step

Magento 2 handles payment methods through modules. The sequence:

1. Check version compatibility. Magento 2.4.x is current; confirm the extension supports your exact minor version before installing.
2. Install via Composer where the provider supports it – this is the maintainable route:

   composer require vendor/module-crypto-payments

3. Enable and register the module:

   bin/magento module:enable Vendor_CryptoPayments
   bin/magento setup:upgrade
   bin/magento setup:di:compile
   bin/magento cache:flush

4. Configure it under Stores → Configuration → Sales → Payment Methods. Enter your API key, connect your wallet or xpub, and enable the networks you want.
5. Map order statuses so fulfilment triggers only on a confirmed payment – never on pending.
6. Set the invoice expiry window, typically 15 to 60 minutes.
7. Clear caches and reindex if the method does not appear at checkout.
8. Place a real low-value test order on each enabled network.

If the payment method is missing from checkout after installation, the cause is almost always one of three things: caches not flushed, the method not enabled for the relevant website scope, or a currency or country restriction excluding it.

PrestaShop: Module Setup Step by Step

PrestaShop’s module system is simpler and mostly handled through the admin interface.

1. Confirm your version. PrestaShop 1.7 and 8.x differ enough that a module built for one may not work on the other.
2. Upload the module via Modules → Module Manager → Upload a module, using the provider’s ZIP file.
3. Install and configure it – enter the API key, connect your wallet or xpub, and select networks.
4. Enable the payment method for the relevant carriers, countries and currencies. PrestaShop restricts payment methods by these dimensions, and an unset restriction is a common reason the option does not show.
5. Set your order status mapping under Shop Parameters → Order Settings, so a confirmed crypto payment maps to the correct status.
6. Configure the callback URL if the module does not set it automatically.
7. Clear the cache under Advanced Parameters → Performance.
8. Run a live test order at low value on each network.

A PrestaShop-specific detail: if the module installs but produces a blank page or a 500 error at checkout, enable debug mode temporarily under Advanced Parameters → Performance to surface the actual error. It is usually a PHP version mismatch or a missing dependency rather than anything to do with the payment logic.

Connecting Your Wallet

The same on both platforms, and the decision that matters most.

In a custodial setup, customers pay into the provider’s wallet, your balance is an internal ledger entry, and you request withdrawals. That withdrawal step is where verification requests, holds and freezes occur.

In a non-custodial setup, each order is paid to an address derived from your own wallet. The funds are yours the moment the transaction confirms. There is no balance and no withdrawal.

A single question settles which you are looking at: between the customer paying and me spending, does anyone else control the money? If the answer involves a balance and a withdrawal request, it is custodial regardless of the marketing language.

The custodial vs non-custodial comparison covers the trade-offs, including the honest downside – with self-custody, no provider can restore a lost recovery phrase.

Bcon Global provides modules for e-commerce platforms with direct-to-wallet settlement: payments go straight to the merchant’s own wallet with no intermediary balance, no KYC requirement and a flat 1% fee, across Bitcoin, Ethereum, Solana, Tron and BNB Chain plus major stablecoins. The e-commerce plugin overview lists supported platforms, and the OpenCart guide covers a closely comparable setup if you also run that platform, using the OpenCart crypto payment plugin.

Choosing Networks and What They Cost

Which networks you enable affects conversion more than most merchants expect, and the current figures are not what older guides say.

Two points that reverse conventional advice. Ethereum is now cheap for token transfers – cents, not dollars. And Tron is now the most expensive major network for stablecoins, at roughly thirty times the Ethereum cost. Steering small orders to Tron, which many older integration guides recommend, now costs your customers money and costs you conversions.

Order Status Mapping

Correct status handling is what makes the integration reliable rather than merely functional.

Three rules apply on both platforms:

1. Fulfil only on confirmation. A transaction visible in the mempool can still be replaced or orphaned.
2. Allow statuses to move backwards. A chain reorganisation can orphan a block you already credited. A model where “paid” is terminal cannot represent that and drifts out of sync with the chain.
3. Make the callback handler idempotent. Gateways retry after timeouts, and one payment produces several status updates. Without a duplicate check, a single payment can trigger fulfillment twice.

Testing Before Go-Live

Sandbox testing is necessary but not sufficient. It does not reproduce real network fees, real confirmation timing, or the wrong-network mistakes actual customers make.

A complete pre-launch test:

1. Place a real order at minimum value on each enabled network.
2. Confirm the address displayed matches the network selected.
3. Pay from an external wallet, not one linked to the gateway account.
4. Verify the order status advances automatically without manual intervention.
5. Confirm funds arrive in your wallet, not a provider balance.
6. Deliberately underpay one test order and check the tolerance behaviour.
7. Let one invoice expire, then pay it, and confirm your handling.
8. Check the confirmation email shows the network name.

Troubleshooting Common Errors

The payment method does not appear at checkout. Magento: flush caches, recompile, check website-scope enablement and currency restrictions. PrestaShop: check carrier, country and currency restrictions in the module configuration.

Orders stay pending after payment. Callbacks are not reaching your store. Verify the URL is publicly reachable over HTTPS and look for the POST request in your server access log. If it is absent, the problem is network-level – a firewall, security module or staging password.

A 500 error or blank page at checkout. Usually a PHP version mismatch or missing dependency. Enable debug mode temporarily to surface the actual error.

The amount received does not match. The customer’s exchange deducted its withdrawal fee from the amount sent. Define a tolerance – auto-accepting shortfalls under 1% or under $1 removes most of these tickets.

Funds sent on the wrong network. The most expensive error, and common because Ethereum and BNB Smart Chain share identical 0x… address formats. Display the network name beside the address, in the QR label and in the confirmation email. If you hold the keys, the funds usually remain recoverable on the other chain.

An order was fulfilled twice. The callback handler is not idempotent. Record a unique key per event and check it before acting.

On Magento and PrestaShop the installation is routine work for anyone already maintaining a self-hosted store. What determines whether crypto runs quietly is everything around it: a wallet you control with a tested backup, a unique address per order, a callback URL that is genuinely reachable, status mapping that fulfils only on confirmation, and network choices that reflect 2026 costs rather than 2022 assumptions.

Set those up deliberately, run one real test order per network, and the integration becomes something you stop thinking about – which is the correct outcome for a payment method.