Are there open-source crypto payment plugins for e-commerce platforms?

The payment plugin is the most trusted code in your store

Every plugin in an online store runs with roughly the same permissions, but only one of them decides money. The payment plugin holds your API key, receives the callback that says "this order is paid", and changes the order status that triggers shipping, a licence key, a course enrolment or a hosting account. If it gets that one decision wrong, you ship goods for nothing.

It is also third-party code, and third-party code is where breaches increasingly start. Verizon's 2025 Data Breach Investigations Report (April 2025) found that the share of breaches involving a third party doubled in one year, from 15% to 30%. Black Duck's 2026 Open Source Security and Risk Analysis (February 2026) audited 947 commercial codebases: 87% contained at least one vulnerability, and 65% of organizations reported a software supply chain attack in the previous year.

For a store, the plugin ecosystem is the supply chain. WordPress alone runs 40.2% of all websites (W3Techs, 29 September 2026), and a WooCommerce store adds a payment gateway the same way it adds a contact form: upload, activate, trust.

With a closed payment plugin, "trust" is the whole security model. The same goes for one that ships obfuscated or only half its logic. You cannot see whether it checks a signature at all, whether it marks orders paid when the buyer's browser comes back, or where the buyer's money actually goes.

What you can't see in a closed payment plugin can cost you

Orders marked paid by a forged request. A plugin that trusts the buyer's return URL, or accepts a webhook without verifying its signature, can be told "status: paid" by anyone who learns the callback address. The goods ship; the money never arrived.

The same order fulfilled twice. Payment providers redeliver webhooks whenever a store is slow to answer. A handler that does not deduplicate sends two confirmation emails, reduces stock twice and grants the download twice.

Funds routed somewhere you did not choose. Many crypto gateway plugins exist to move your buyer's money into the gateway's own balance. You learn the payout schedule, the reserve and the freeze policy later, and nothing in the plugin tells you where the money flows.

Abandonware at checkout. A closed plugin that stops being maintained breaks on the next major platform release, and you cannot patch it, fork it or pay someone else to fix it. Your checkout waits on someone else's roadmap.

A security review you cannot pass. Enterprise buyers, investors and your own security team increasingly ask which third-party code touches payments. "It's a vendor plugin, we don't know" is not an answer that closes the review.

Why most crypto payment plugins are closed, custodial or both

None of this is malice. It follows from how the processors behind the plugins are built.

With a custodial gateway, the plugin is a funnel. The logic that matters (deposit addresses, confirmations, the balance) lives on the gateway's servers, next to your money. Even when the plugin code is readable, it cannot show you the part you care about, because the funds never pass through it: they land in the gateway's wallet and come back to you as a payout.

A self-hosted open-source processor is the opposite trade-off. Everything is auditable, but you run the processor, its database and often a node, and you own the uptime. That is a good fit for teams with operations capacity. It is a lot to take on for a store with one part-time developer.

Card gateway plugins are often open source, but the rail isn't. You can read the WooCommerce plugin of a card processor, but the acquirer still holds the funds for days and can reverse a payment for around 120 days after the sale.

What most merchants actually want is the combination nobody used to offer: the plugin is open, the processor is non-custodial, and there is no server to run.

Payzum's 29 open-source crypto payment plugins, by platform

Payzum is a non-custodial, stablecoin-first crypto payment processor: payments settle directly to wallets the merchant controls. Each integration lives in its own repository under github.com/payzum-dev, named <platform>-payzum. Seven follow their ecosystem's naming convention instead: medusa-payment-payzum, saleor-app-payment-payzum, vendure-plugin-payzum, sylius-payzum-plugin, django-payments-payzum, omnipay-payzum and frappe-payzum. We checked every row below against the live organization, its licenses, releases and package registries, on 29 September 2026.

E-commerce carts (10)

Headless commerce (4)

Hosting and billing (4)

Donations, memberships and digital downloads (3)

Forms, courses, ERP, accounting, ticketing and .NET (6)

Payment libraries (2)

The same organization holds the official SDKs (Node.js/TypeScript, PHP, Python and Rust) and payzum-openapi. That repository contains the OpenAPI contract for the API and a shared corpus of webhook-signature test vectors, which every SDK is validated against. The WooCommerce plugin, for example, bundles the official PHP SDK and hands signature checks to its verifier instead of hand-rolling its own. If your platform is not in the tables, you do not need a plugin: the three-step integration works with anything that can call an API.

What the source lets you check: where the funds go

We scanned all 29 repositories on 29 September 2026: none contains a wallet address. A Payzum plugin never decides where money goes. It creates a payment from your server with the order total, the currency, an order reference and your callback URLs, then sends the buyer to the hosted checkout. The receiving wallet is the one you set in your own Payzum dashboard.

The buyer pays from their wallet straight to yours. That confirms in about 0.4 seconds on Solana and around two seconds on Base or Polygon, and Payzum never holds the funds. If you price in dollars, optional auto-convert to USDC or USDT is available on most supported networks. The full model is explained in what a non-custodial crypto payment processor is.

What the source lets you check: how the webhook is verified

Open the WooCommerce plugin's gateway class and the whole decision fits in under a hundred lines you can read:

• It reads the raw request body before parsing anything.
• It verifies an HMAC-SHA-512 signature over those raw bytes, taken from a fixed header, using a constant-time comparison. The header is x-nowpayments-sig, because the payment IPN uses a NOWPayments-compatible format.
• It rejects events outside a 10-minute replay window on the signed timestamp.
• It ignores duplicates by event ID, under a per-order lock so two concurrent deliveries cannot both mark the order paid.
• It answers 401 to anything unsigned and leaves the order untouched.

Only then does it map the payment status onto the order: finished becomes processing or completed, partially paid goes on hold, expired cancels, failed fails. Nothing is inferred from the buyer's browser.

How to audit an open-source crypto payment plugin in 15 minutes — then install it

This works for any payment plugin, not just ours. The WooCommerce plugin is the worked example; swap the paths for your platform.

1. Find the official repository. Use the tables above and confirm the repository sits under github.com/payzum-dev, not in a fork or a lookalike account.
2. Read the license and the latest release. MIT, GPL and OSL all let you read, modify and fork the code. Download the packaged zip from Releases, not GitHub's "Download ZIP" button: that one unpacks to a <repo>-main/ folder the platform will not recognise.
3. Open the webhook handler and run the five checks below. On WooCommerce it is includes/class-wc-gateway-payzum.php, method handle_ipn(); on WHMCS it is the gateway's callback/ file.
4. Check where the money goes. Search the code for wallet addresses and for what the plugin sends out. You should find no address, and an outgoing payload of total, currency, order reference and callback URLs, with no customer personal data.
5. Install on staging. Upload the release zip or install from the registry, paste a staging API key and webhook secret, and copy the IPN URL from the settings screen into the webhook settings of your Payzum dashboard.
6. Test the failure path first. Send an unsigned request to your IPN URL (below) and expect a 401. Then place a real staging order, pay it on the hosted checkout, and watch the order move to processing only when the signed webhook lands. Underpay once and confirm the order goes on hold.
7. Go live. Switch to the production key, enable the method, and publish the refund terms the buyer accepts at checkout. On-chain payments are final, so refunds are payments you send under your own policy.

# Must be rejected: no signature header, so the order is not touched
curl -i -X POST https://your-store.example/wc-api/wc_gateway_payzum \
  -H 'Content-Type: application/json' \
  -d '{"order_id":"123","payment_status":"finished"}'
# Expected: HTTP 401 (bad signature)

Five things to check in any payment plugin's webhook handler

1. It reads the raw body and verifies the signature before trusting a single field.
2. It uses an HMAC signature from a fixed header with a constant-time comparison, not a plain string equality.
3. It has a replay window and deduplicates by event ID.
4. It never marks an order paid from the buyer's return URL.
5. It keeps the API key and webhook secret server-side, with nothing secret in the checkout page's JavaScript.

The engineering behind each check, with code for Node.js, PHP and Python, is in signed webhooks for crypto payments. What the plugin does at checkout, step by step, is in the pillar guide crypto payment plugin: a drop-in checkout for your cart.

Use cases: who installs open-source crypto payment plugins, and why

The license matters most to the people who have to answer for the checkout.

• The agency with 40 client stores on three carts. It runs WooCommerce, PrestaShop and Shopware for clients in a dozen countries. It audits the plugin once per platform, pins the release version in its deployment scripts and rolls it out store by store. Each client connects its own wallet in its own dashboard, so the agency never touches client funds, and an update is a diff it can read before shipping it.
• The hosting company on WHMCS. Its security review asks which code can mark an invoice paid. The developer reads the gateway module and its callback, sends the unsigned test request, gets a 401, and closes the review in an afternoon. The business case for stablecoins in hosting is in accepting crypto payments as a web hosting provider.
• The nonprofit on GiveWP with a volunteer developer. Donors ask where their gift goes, and now the answer is checkable: no address in the plugin, and every donation lands in the organization's own wallet, confirmed on-chain with a reference. The volunteer can review a GPL-licensed plugin, which is also the license WordPress itself uses.
• The headless team on Medusa or Saleor. Its B2B flow needs an approval step before payment, which no stock plugin offers. Under the MIT license the team forks the provider, adds the step, and keeps merging upstream releases, instead of rewriting a payment integration from scratch.
• The finance team on ERPNext or Akaunting. Invoices to overseas clients are paid in USDC, and the signed callback marks them paid in the ledger. Reconciliation works from an order reference and an on-chain transaction instead of a wire memo someone typed by hand.

Open-source vs closed crypto payment plugins: comparison

Common objections, answered

"It's not in the WordPress or Shopify marketplace. Is installing from GitHub safe?"

A marketplace review checks one snapshot, once, with criteria you do not see. Open source lets you check every line of the version you actually install, and every diff after it. Pin a tagged release, read the webhook handler, run the unsigned-request test, and you know more about this plugin than about most listed ones. The Packagist, npm and PyPI packages are published from the same public repositories.

"If the code is public, can't attackers read it too?"

They can, and it does not help them. Signature verification is designed to be public: its security rests on your webhook secret, not on hiding the algorithm. An attacker who reads the code learns the header name. Without your secret, they cannot produce a signature the plugin accepts, and without a signature the order does not move.

"My platform isn't on the list."

Then use the API directly. One server-side call creates the payment, the response gives you a hosted checkout URL, and the signed webhook tells you when it is paid. The official SDKs cover Node.js, PHP, Python and Rust. The developer walkthrough is in REST API crypto payment gateway.

"We don't have a developer to audit anything."

The checklist takes a developer about fifteen minutes, and a freelancer can run it for you. If you would rather see it done, book a call and we'll walk through the plugin for your platform on screen.