Is there a crypto payment gateway for PrestaShop?

Payzum is a non-custodial, stablecoin-first crypto payment processor: payments settle directly to wallets the merchant controls. Its PrestaShop crypto payment gateway is the module payzum, open source under the MIT license at github.com/payzum-dev/prestashop-payzum. This guide covers why PrestaShop merchants add stablecoins, six checks to compare any crypto module, and then version 1.2.0 step by step: install, settings, and exactly what happens in your back office at each stage of a USDC or USDT payment.

Why PrestaShop merchants look for a crypto payment gateway

PrestaShop is the free, open-source cart that thousands of small and mid-sized merchants host and run themselves. W3Techs puts it on 0.5% of all websites and 2.8% of sites with a known e-commerce system (October 2026). Many of those stores sell across borders, and cross-border sales are where card costs climb.

Take Stripe's published pricing for Spain (checked 2 October 2026). A standard European card costs 1.5% + €0.25. A premium European card costs 2.8% + €0.25, and a card issued outside the EEA costs 3.15% + €0.25. Currency conversion adds 2%, and every dispute costs €20. A €400 order from a buyer in Mexico, priced in dollars and settled in euros, pays €20.85 in fees before anything ships, and the money can still be pulled back for months.

PrestaShop checkouts are also a proven target. On 22 July 2022, PrestaShop warned that attackers who took control of shops had "injected a fake payment form on the front-office checkout page" to steal card data. In February 2026 it alerted merchants again. This time a digital skimmer, planted in the active theme's head.tpl file, swapped the real payment buttons for fake ones that led buyers to a counterfeit card form. A skimmer only pays off if buyers type card numbers on your site.

Then there are buyers who would rather not use a card at all: trade customers who settle invoices in USDT, shoppers whose cards are declined abroad, and crypto-native communities. Without a stablecoin option, they abandon the cart or send a wire that takes days to arrive.

What a badly built crypto module costs a PrestaShop store

Adding crypto doesn't remove risk on its own. PrestaShop payment modules fail in PrestaShop-specific ways, and each failure costs money, stock or a weekend:

• Unpaid orders holding stock. Some modules create the order the moment the buyer clicks, in an "awaiting payment" state. PrestaShop deducts stock when an order is created. Every abandoned crypto payment then keeps products off sale until someone cancels the order by hand.
• Orders marked paid by the return page. If the module trusts the buyer landing back on your store, anyone can fake that visit. Crypto confirmation is asynchronous, and the browser is the wrong witness.
• Two orders for one payment. Providers retry webhooks. Two deliveries that arrive together can both read "no order yet" and both create one. You end up with two orders, two confirmation emails and stock deducted twice.
• Charged for one cart, shipped another. While the buyer is on the payment page, the PrestaShop cart can still be edited. If they add an item in another tab, a naive module builds the order from the bigger cart, while the invoice charged for the smaller one.
• Forged notifications. A webhook handler that trusts the cart ID in the request lets anyone mark a cart paid. It needs a signature check and a check against the cart's own secure key.
• A module stuck on an old stack. A module written for an old PrestaShop and PHP, and never updated, breaks on the next upgrade, which is when you can least afford it.
• Funds parked in someone else's balance. Custodial crypto gateways collect your sales in their own wallet and pay you later, on their schedule and under their minimums and freeze policy.

Why card modules, bank wire and custodial crypto fall short on PrestaShop

Card modules are mature, but the card network sets the terms. The acquirer holds the funds, decides when they settle and can pull them back through a dispute. And a card form on your checkout brings the page into PCI DSS scope. Since 31 March 2025, PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 make you inventory and authorize every script on a payment page and check for tampering at least weekly. A tampered checkout page is exactly how both PrestaShop skimmer campaigns worked.

Bank wire is free to install and slow to run. PrestaShop's built-in wire module creates the order as "Awaiting bank wire payment" and leaves you to match each transfer to an order by hand. International wires take days and often arrive short of bank fees.

Custodial crypto modules fix acceptance but not custody. The buyer pays the gateway's address, the gateway credits a balance, and you withdraw when it allows. That balance is exactly what a provider can freeze, or lose if it shuts down.

The DIY route keeps custody and drops everything else. A wallet address in the order email gives you no unique amount per order, no underpayment detection and no status change. Someone ends up matching blockchain transactions to order references by hand.

A PrestaShop store needs a module that behaves like any other payment method in the back office, with a real order, a payment record and the usual confirmation email. It should also settle like crypto: final, in seconds, to a wallet you control.

How to choose a PrestaShop crypto payment gateway: six checks

Several crypto modules exist for PrestaShop. Six questions separate one you can run in production from one you'll regret. Ask them of any vendor, including us:

1. Where do the funds settle? In your own wallet, or in a balance the provider holds and pays out later? Only the first leaves nobody able to freeze the money.
2. What creates the order, and when? PrestaShop's own developer documentation says no payment module should create an order before the customer has been through the payment service. Look for a module that creates the order from a server-to-server webhook. Its signature should be verified over the raw request bytes, with a replay window. The return page should never count.
3. Is the amount checked against the cart? The cart stays editable while the buyer pays. The module should compare the invoiced amount and currency with the cart before it creates the order.
4. What happens when the webhook arrives twice, or twice at once? Look for deduplication by event ID and a lock per cart. Without both, retries become duplicate orders.
5. Does it fit your PrestaShop and PHP versions? Compare the module's declared PrestaShop range and its PHP requirement with your stack. PrestaShop 1.7.8 supports PHP up to 7.4, and PrestaShop 8 recommends PHP 8.1. A module that needs a PHP version your PrestaShop can't run is not an option, whatever its page says.
6. Can you read the code, and what leaves your store? Open-source code lets your developer check how the webhook is verified and where the money goes. Check which customer data the module sends out. And check that the list of accepted coins is enforced by the provider, not only in a setting in your back office.

Our guide to open-source crypto payment plugins turns checks 2, 4 and 6 into a 15-minute audit you can run on any repository.

How Payzum's PrestaShop module handles a USDC payment

The module is a standard PrestaShop payment module. It does two things: turn a cart into a Payzum invoice, then let a signed webhook, and nothing else, turn that cart into a paid order.

At checkout: a hosted page where the buyer picks the coin

The buyer chooses Pay with Crypto / Stablecoins (Payzum), labelled "You will be redirected to a secure Payzum checkout", and confirms. The module creates a Payzum invoice for the cart total in the cart's currency. The total travels as an exact string, so it isn't rounded on the way out. The invoice reference combines the cart ID with part of the cart's secret key, so it can't be guessed. If the buyer comes back and clicks again in the same hour, with the same cart and total, they get the same invoice instead of a second one.

The buyer lands on Payzum's hosted checkout, with a QR code, a deposit address and a live status. They choose the coin and network there and pay from any wallet, without creating an account. If Payzum can't be reached at that moment, they go back to your checkout with a message asking them to try again or choose another method.

The module doesn't choose the coin for the buyer. With the default Settlement currency of all, the hosted checkout offers only the tokens you accept, which you set in your Payzum dashboard under Merchants → Settings → Accepted tokens. Payzum enforces that list on its side. For most stores that means USDC and USDT on fast, low-fee networks. Solana confirms in about 0.4 seconds, and Base and Polygon in about two. If you also accept other crypto, optional auto-convert to USDC or USDT is available on most supported networks.

The module registers only two PrestaShop hooks, the payment options and the payment return. It loads no script and no stylesheet on your storefront, so it adds nothing to the script inventory that PCI DSS requirement 6.4.3 asks for.

After payment: the signed IPN creates the order

Payzum notifies your store server to server, through the module's IPN controller. Before reading a single field, the module verifies an HMAC-SHA-512 signature over the raw request bytes with your webhook secret. The comparison runs in constant time, and replays outside a 10-minute window are rejected. A bad signature gets a 401 and nothing is touched. The module then rebuilds the expected reference from the cart's secret key. A notification that names a cart it doesn't belong to is rejected too.

Next it takes a MySQL lock for that cart. If another delivery for the same cart is still being processed after 10 seconds, the second one gets a 503, and Payzum simply retries it later. The lock name includes your database name and table prefix, so a staging copy on the same MySQL server never blocks production. Every event ID is recorded in the module's own payzum_ipn_event table, and a delivery it has already applied is acknowledged and ignored.

On a finished payment, the module compares the invoiced amount and currency with what the cart is worth now, with half a cent of tolerance for rounding. If they match, it calls PrestaShop's standard order validation. The order is created as Payment accepted. The Payzum payment ID is stored as the transaction ID in the order's Payments tab. A private order message records the coin, the network, the amount paid and the invoiced total. PrestaShop sends its usual confirmation email at that moment, once the payment is final. The engineering behind this pattern is covered in signed webhooks for crypto payments.

The HTTP client and signature check come from the official payzum/payzum-php SDK. It ships inside the module's vendor/ folder, so there's no Composer step.

Where the money goes

Nowhere near Payzum. The buyer's payment goes from their wallet straight to the wallet set in your dashboard, and the module's code contains no wallet address at all. There is no Payzum balance to withdraw, freeze or wait for. The model is explained in what a non-custodial crypto payment processor is.

How to set up the PrestaShop crypto payment gateway, step by step

You need PrestaShop 8 running on PHP 8.1 (the version PrestaShop recommends for 8.x) and HTTPS on your storefront. Most of the time goes into the staging test, which is the step worth doing properly.

1. Set up your Payzum merchant account. Sign up at merchant.payzum.com. Add the wallet you want to be paid into and choose your accepted tokens, for example USDC on Base, Solana and Polygon, plus USDT. Create an API key (64 hexadecimal characters) and note your webhook (IPN) secret.
2. Install the module. Download payzum.zip from the repository's Releases page. In your back office, open Modules → Module Manager → Upload a module and choose the file. The archive unpacks to payzum/, which is how PrestaShop recognizes the module, so don't rename it. Don't use GitHub's green "Download ZIP" button either: it unpacks to prestashop-payzum-main/, which PrestaShop won't accept as this module. From a shell, you can clone the repository into modules/payzum and run php bin/console prestashop:module install payzum.
3. Configure it. Open Modules → Module Manager → Payzum → Configure. Paste the API key and webhook secret, leave Settlement currency on all, and set Environment to Staging for now. Staging has its own API keys; a production key won't work there.
4. Connect the webhook. The configuration page shows your store's IPN URL. Copy it into your Payzum webhook settings, as the page asks (the module also sends it with every invoice). It must accept POST requests from the internet over HTTPS. A test shop behind basic auth, an IP allowlist or maintenance mode will never hear back.
5. Check payment restrictions. Under Payment → Preferences, make sure Payzum is enabled for your store's currencies, and for the countries, customer groups and carriers you sell to. Payzum only appears at checkout when the cart's currency is enabled for it and an API key is saved.
6. Test on staging. Place an order and go to the hosted checkout. Nothing appears under Orders yet, and that's expected. Pay it, and the order appears as Payment accepted, with the coin and network in a private message. To test the safety net, open the invoice, add an item to the cart in another tab, then pay. No order is created, and an error explains why under Advanced Parameters → Logs.
7. Go live. Switch Environment to Production, paste your production API key and secret, and place one small real order.

The configuration screen at a glance

There is deliberately no field for the signature header. The SDK fixes it, so nothing on this screen can drift out of sync with your account.

What happens in PrestaShop at each payment status

Nothing in this table is triggered by the buyer's browser. A closed tab never loses a paid order, and a fake return visit never creates an unpaid one.

What version 1.2.0 doesn't cover

• PrestaShop 1.7 in practice, and PrestaShop 9. The module declares PrestaShop 1.7 to 8, but it needs PHP 8.1, and PrestaShop 1.7.8 supports PHP only up to 7.4. In practice that means PrestaShop 8. PrestaShop 9 has been stable since 10 June 2025, but it's outside the module's declared range, so PrestaShop won't install the module there.
• It isn't on the Payment methods page. PrestaShop lists only officially referenced modules under Payment → Payment methods. You configure Payzum from the Module Manager instead; restrictions under Payment → Preferences still apply.
• Stock isn't reserved during payment. Because the order only exists once the money arrives, two buyers can pay for the last unit at the same moment. If you sell limited runs, keep a small buffer.
• Mismatches need a person. When a cart changes mid-payment, the buyer has still paid the invoice. You reconcile by hand: refund the difference, or create the order manually.
• Refunds go out from your wallet. The module doesn't push refunds. You send the stablecoins back yourself and record the refund in PrestaShop, for example with a credit slip.
• Distribution. As of 2 October 2026, the module is distributed as a GitHub release only, not on PrestaShop Addons or Packagist.

Use cases: PrestaShop stores that take USDC and USDT

The setup is the same for every store. What changes is which part of it pays for itself.

• Furniture maker selling to the Americas. A workshop in Valencia shows prices in dollars to buyers in the US and Mexico and settles in euros. On a €1,200 order paid with a non-EEA card, Stripe's Spanish pricing comes to 3.15% + €0.25 plus 2% for conversion: €62.05. Paid in USDC on Base, the order appears as Payment accepted seconds after confirmation, and the private note shows which coin and network the buyer used.
• Electronics store after the February 2026 alert. A components shop in Lyon cleaned a skimmer out of its theme and wants to give returning buyers a way to pay that involves no card number on the site. Payzum appears as one more payment option, and the payment happens on the hosted page. The card methods stay in PCI scope, but every buyer who switches is one card fewer typed into the checkout.
• B2B wholesaler with trade buyers abroad. A ceramics wholesaler takes a €14,000 order from a distributor outside the EU. On a non-EEA card that would cost €441.25 in fees, and a wire would take days. The distributor pays in USDT, but its treasury sends the money in two transfers. After the first transfer, PrestaShop shows no order. After the second, the order appears once, fully paid, with stock deducted once.
• Record label with limited pressings. A label sells 300 copies of a vinyl reissue. With an "awaiting payment" module, every abandoned crypto checkout hides a copy until someone cancels the order. With Payzum, no order exists until the payment is final, so unsold copies stay on sale. The label keeps a buffer of five copies for buyers who pay at the same moment.

Payzum for PrestaShop vs a card module, bank wire and a custodial crypto module

Compared on neutral criteria. Card figures are Stripe's published pricing for Spain, checked on 2 October 2026.

A self-hosted crypto server is another fair option if you want no third party at all and have someone to run it. Payzum is for stores that want the same custody without operating payment infrastructure. And you don't have to drop anything: most stores add Payzum as one more payment option next to cards and bank wire.

Common objections, answered

"My customers don't have crypto."

Most of them don't need to. Payzum is an extra payment option next to your cards, not a replacement. The buyers who choose it are the ones who would otherwise abandon the cart, wire you money days late or trigger your highest card fees.

"What about volatility, and what about MiCA?"

Your prices stay in your store currency. The module sends the cart total in the cart's currency, and the buyer pays the equivalent in the coin they choose. If you accept only USDC and USDT, you receive dollar stablecoins. If you accept other crypto too, optional auto-convert to USDC or USDT is available on most supported networks. Selling from the EU? Read what MiCA means for merchants and USDT vs USDC for payments before you choose which tokens to accept.

"After the skimmer alerts, I don't install modules on trust."

Good, and you don't have to. The module's logic is about 640 lines of PHP in three main files, plus the vendored official SDK, all public under MIT. It registers two hooks and loads no front-end script. Your API key never reaches the browser, and the code contains no wallet address. It sends Payzum only the cart total, the currency, a cart reference and your callback URLs, with no customer personal data. The IPN controller rejects unsigned or forged notifications before it touches a cart.

"How do refunds work if payments are final?"

You send the USDC back from your wallet under the refund policy you publish, and record the refund in PrestaShop, for example with a credit slip. You decide when money goes back; a card network doesn't decide for you.