How to Accept Crypto Payments on WooCommerce

A WooCommerce store can take crypto through four routes: a payment plugin, a hosted payment page, a payment link, or a direct API integration. For a standard store, the plugin route closes the job in under two hours once verification clears. This guide covers WooCommerce cryptocurrency setup with Speend end to end, including what tends to break afterwards and what the payment processing actually costs.

What the plugin catalogue shows

Around 26,000 active installs of crypto payment plugins sit across roughly 7,000,000 active WooCommerce installs. That works out at 0.37%, or about one store in every 270.

The figures come from the public wordpress.org catalogue, narrowed to the 121 plugins whose job is accepting cryptocurrency on WordPress. Card-in, stablecoin-out gateways and internal wallet plugins are left out as a different product. The catalogue rounds install counts to an order of magnitude, so every total here is an estimate of scale rather than a headcount.

The segment is also concentrated. Five plugins account for 18,000 of those installs, 69% of everything crypto-related running on WooCommerce today.

The visible ranking and the installed base disagree with each other, and that gap is the point of the exercise. Coinsnap carries 60 active installs while its blog holds positions across four of the seven keywords in this cluster and its plugin ranks second for woocommerce bitcoin plugin. GoUrl carries about 1,200 installs across two plugins last touched in 2023 and 2024, and one of them ranks seventh for woocommerce bitcoin gateway. A search position tells you nothing about the state of the code behind it.

Plugin	Active installs	Last updated	Compatibility declared
MyCryptoCheckout	8,000	19.08.2026	7.1
NOWPayments for WooCommerce	4,000	25.08.2026	7.1
Coinbase Commerce	4,000	31.05.2024	6.5.10
Blockonomics	2,000	03.08.2026	7.0.4
BTCPay Greenfield	1,000	18.08.2026	7.0.4
CoinPayments.net	1,000	02.05.2025	6.2.11
GoUrl (two plugins)	700 + 500	13.04.2024 / 27.10.2023	6.6.7 / 6.4.10
Cryptocurrency Payment Gateway	400	01.04.2026	7.0.4
Crypto.com Pay Checkout	300	30.04.2025	6.7.7
TripleA	200	06.03.2026	6.9.7
CryptoPay Lite	100	15.07.2026	7.0.4
Coinsnap for WooCommerce	60	05.06.2026	7.0.4
Coinremitter	10	05.08.2026	7.0.4

Catalogue data as of 4 September 2026. The current WordPress release is 7.1, and WooCommerce is at v11.1.0, updated 3 September 2026.

Thirteen plugins that stopped getting updates

Thirteen of the 121 plugins have gone twelve months or more without a release. Together they carry around 7,600 active installs, which is 29% of the segment. Nearly one in three stores accepting crypto on WooCommerce runs code that nobody has shipped a fix for in over a year.

A payment plugin is a poor place for stale code. It signs requests, receives webhooks, moves orders between statuses, and writes to the order record. When WordPress or WooCommerce changes an interface, a maintained plugin gets a release and an abandoned one gets a support thread. The catalogue exposes enough to check this yourself before installing anything: the date of the last release, the “tested up to” value, and whether the support forum has recent answers.

Declared compatibility is the fastest signal: six of the thirteen plugins in the table above name a WordPress version at least two minor releases behind 7.1.

The Coinbase Commerce plugin and four thousand stores

The Coinbase Commerce plugin carries 4,000 active installs, was last updated 31 May 2024, and declares compatibility up to WordPress 6.5.10. The product behind it no longer exists for most of those stores.

Coinbase closed the Commerce merchant portal on 31 March 2026 for merchants outside the United States and Singapore, folding the product into Coinbase Business, which launched in those two markets with an international rollout announced across 2026. Merchants elsewhere were told to move to another provider before the cutoff. The plugin, meanwhile, stayed in the catalogue and kept its install count.

It also stayed in the recommendations. Several of the plugin roundups that rank for this topic were refreshed during 2026 and still list Coinbase Commerce in their shortlists without a word about the shutdown. If a store owner picked a gateway from a listicle this year, the catalogue is the only place the state of the plugin was visible. Migration paths are covered separately in what to use instead of Coinbase Commerce.

Four ways to connect crypto payments

Four routes lead to the same result, and they differ in how much of the checkout you control. A WooCommerce bitcoin plugin is the shortest of them. The hosted page and the payment link need no code at all, and the REST API is for stores whose checkout does not live in WooCommerce templates.

Route	Fits	What it takes	Time to first payment
Plugin	Standard WooCommerce checkout, classic or block	ZIP upload, keys from the dashboard	Under two hours after verification
Hosted payment page	Stores that want the payment step off their own domain	A link from the dashboard	Minutes
Payment link	Invoices, pre-orders, sales outside the catalogue	A link per amount	Minutes
REST API	Custom or headless checkout, non-standard order flow	Development work against api.speend.io	Several days

Before any of these, the merchant account has to exist and the store domain has to be registered with the provider. Business verification runs 1 to 3 business days from the moment documents arrive, and it gates everything else. The Speend plugin for WooCommerce is published as a downloadable package, and other plugins for CMS platforms cover Shopify and Magento, which are supported on the same account even though their pages are not published yet.

The hosted page and the payment link work the day the account opens, before anyone touches WordPress, which makes them a reasonable way to run a first live transaction while the plugin is still being configured. The comparison of these routes across platforms sits in the guide on how to accept crypto payments.

When a plugin is enough and when you need the API

The plugin covers a store where WooCommerce owns the cart, the checkout, and the order record. It renders inside the standard checkout, writes order notes, and moves orders between statuses on its own. Nothing in that flow needs a developer.

The API becomes the answer in three situations. The first is a headless or heavily customised checkout, where the payment step is rendered by your own front end rather than by WooCommerce. The second is an order flow that starts outside the store, such as a CRM or a back office that issues invoices and only later reconciles them with WooCommerce. The third is per-customer static wallets, where each buyer keeps a permanent deposit address instead of receiving a fresh invoice each time.

The dividing question is not turnover but ownership of the checkout. A high-volume store with a stock checkout stays on the plugin, while a small store with a custom front end goes to the API. Transaction limits are set individually and depend on the asset, the merchant profile, and the outcome of verification, so they rarely decide this choice.

Installation: requirements and steps

The package needs WordPress 5.8 or newer, WooCommerce 6.0 or newer, and PHP 7.4 or newer with the curl and json extensions enabled. Installation is a ZIP upload: the package, Speend Payments v1.2.0, is downloaded from the plugin page and uploaded through the WordPress admin. WooCommerce crypto payments start working once the keys are in place.

The search box in Plugins → Add New will not find it. The package is distributed from the provider’s own domain rather than through the wordpress.org catalogue, the same way CryptAPI, CCPayment and Coinremitter ship their gateways on GitHub. The upload path is standard WordPress behaviour and takes one extra click.

1. Open the plugin page and download the current package. A checksum is published next to the file, so the archive can be verified before it goes anywhere near the site.
2. In the WordPress admin, go to Plugins → Add New → Upload Plugin, select the ZIP, install, activate.
3. Sign in to the merchant dashboard and register the store domain. The plugin authenticates per domain, and requests from an unregistered host are rejected.
4. Copy the Merchant UUID and the API key from the dashboard into the plugin settings.
5. Copy the Withdrawal API key if refunds from the WooCommerce admin are needed. Without it the refund function stays switched off.
6. Set a webhook password if you want the callback signature to include one.
7. Save. The plugin registers its own webhook URL and pulls the list of available coins and networks from the provider.

Verification is the long pole in the sequence, not the install. Documents go in first, the account opens 1 to 3 business days later, and the WordPress side takes under two hours from download to a working checkout. A merchant planning a launch date should count backwards from verification.

Keys and the webhook

Four credentials exist in the dashboard, and they do different jobs. The Merchant UUID identifies the account. The API key signs ordinary requests: creating an invoice, reading its status, listing available coins and networks. The Withdrawal API key is separate and authorises money leaving the balance, which is why refunds depend on it. The webhook password is optional and only affects the callback signature.

Callbacks arrive as POST requests carrying the payment status, and every one of them is signed with the API key and the webhook password. The plugin checks the signature itself, so the scheme only matters to stores that handle callbacks with their own code.

Delivery is retried up to seven times per status. The plugin deduplicates by the last status it applied, so a repeated callback for a status the order already carries changes nothing.

Storefront setup and the first payment

Four settings decide what the buyer sees: checkout type, payment mode, available coins and networks, and invoice lifetime. Both the classic WooCommerce checkout and the block checkout are supported, and the plugin renders in either without extra configuration.

Payment mode is the choice with visible consequences. Redirect sends the buyer to a hosted payment page and returns them to the store afterwards. On-site, the host-to-host mode, keeps the payment inside the store’s own checkout. Redirect is faster to launch, and On-site keeps the buyer on your domain through the whole order. Both settle identically.

The coin and network picker appears on the storefront with a search field, so a buyer holding USDT on one network is not forced onto another. The list is pulled live from the provider and cached for about ten seconds, which means switching a network off in the dashboard takes effect on the storefront almost immediately. A light and a dark theme are available for the payment interface.

Invoice lifetime is selected from 1, 2, 3, 4, 6, 8 and 12 hours, and defaults to 2. The lifetime is the window in which the quoted amount holds. A short lifetime narrows the exposure to price movement between order and payment, while a long one suits buyers who need to move funds from an exchange first.

Run the first payment in the sandbox before switching the store to live keys. The sandbox mirrors production one to one: invoice created, deposit detected, order moves to paid, callback logged. Check that the order note appears and that the status changes without a manual refresh. If both happen, the webhook path works.

What breaks after installation

Four failures account for most of what goes wrong after a working install, and all four are diagnosed the same way: read the payment status, then check whether the callback for that status reached the store. The plugin writes an order note on every status it applies, which makes the order screen the first place to look rather than the server log.

Payment statuses come through the callbacks and through the status endpoint. process means the invoice exists and nothing has arrived. check means a deposit was seen and confirmations are pending. paid and paid_over both close the order as paid, the second on an overpayment. wrong_amount_waiting means a partial payment arrived and the rest is expected. wrong_amount means the invoice closed short. locked means the transaction is held by an AML check. cancel means the invoice expired or was cancelled without payment.

The order sits in pending while the payment went through

Check the payment status first. If it reads check, the deposit was seen and confirmations are still pending, and the order is meant to sit in pending until the network confirms. Nothing is broken and the order will move on its own.

If the status reads paid and the order is still pending, the callback did not reach the store or was rejected. Retries run up to seven times per status, so the order often resolves itself within minutes. If it does not, the problem is on the receiving side and the next section applies.

Webhooks stopped arriving

Three things break callback delivery, and they are checked in this order. The webhook URL first: the plugin registers it automatically, but a site moved to a new domain, put behind a maintenance mode, or fronted by a firewall rule that blocks POST requests from unknown hosts will stop receiving them.

The webhook password second. If it was set or changed in the dashboard after the plugin was configured, the signature the store computes no longer matches the one that arrives, and every callback is rejected as invalid while looking perfectly normal in the provider’s log.

The signature routine third, and only if the site verifies callbacks with custom code rather than the plugin. The hash covers the base64-encoded JSON body without the sign field, plus the API key, plus the webhook password. Re-serialising the payload before hashing reorders the keys and breaks the match.

Underpayment and overpayment

Two statuses cover the two directions, and they need different handling. wrong_amount_waiting means the buyer sent less than the invoice and the invoice is still open: the remainder can arrive, and the order should stay pending. wrong_amount means the invoice closed with less than the full amount, which is a manual decision — accept the shortfall, ask for the difference, or refund.

Overpayment is simpler. paid_over closes the order as paid, and the surplus lands on the merchant balance. The plugin does not return it automatically. A refund of the difference goes out as a separate transfer and carries its own network fee.

A conflict after a WordPress core update

Update order matters more than update speed. A payment plugin should be tested against the new core on a staging copy before the live store moves, because the failure mode here is a checkout that renders without a payment method rather than an obvious error.

Compatibility declared in a plugin’s update metadata trails the current release for most gateways, including this one, so treat the declared value as an indicator rather than a verdict. Run this check before the core update, not after:

• Copy the store to staging and update the core there first.
• Place a sandbox order and confirm the payment method renders in the checkout.
• Confirm the invoice is created and the callback moves the order to paid.
• Check that the coin and network picker still loads its list.
• Check that a refund from the admin still initiates.
• Check the PHP error log for deprecation notices raised by the payment plugin.
• Only then update the live store, ideally outside the store’s busy hours.

What it costs

Three lines make up the total: the provider fee, the conversion fee if the settlement currency differs from what the buyer paid, and the network fee. The base rate starts from 0.5%, with no hidden markups above the disclosed rate. There is no setup fee and no subscription.

Auto-conversion is charged per coin rather than as a flat rate. Converting Bitcoin into a stablecoin at the moment of receipt is 0%. For other coins, converting into a different settlement currency is 1%. Settlement currencies named on the coin pages are USDT, USDC, EUR and USD.

The network fee is passed through at blockchain cost without a markup, which means it depends on the rail and on the day rather than on the provider. Measured 4 September 2026:

• Ethereum L1, USDT on ERC-20 to a new recipient: $0.0136
• TRON, USDT on TRC-20 to a new recipient: $4.27
• Solana, an SPL token transfer: $0.0005

Prices were read straight off the networks’ public nodes on 4 September 2026, taken as the median over the last thousand blocks and converted at the coin prices of that moment.

Two things follow for a store. Network costs move fast enough that a figure quoted in an article is a snapshot rather than a rate card, and the difference between rails on the same day can be three orders of magnitude. A transfer to an address that already holds the token is cheaper than one to a fresh address, so leaving several networks enabled in the picker lets the buyer pay on whichever rail is cheap when the order is placed.

Refunds

Refunds are issued in cryptocurrency from the WooCommerce admin, on the order screen, the same place a card refund would be issued. They require the separate Withdrawal API key: with no key saved, the function is switched off, and the refund button does nothing.

A refund moves through its own statuses. refund_processing means the payout is in flight, refund_success marks the order as refunded, and refund_failed leaves the order untouched and needs a look at the balance and the destination address. Each refund is an on-chain transfer and carries the network fee of the rail it goes out on.

Funds sit on the merchant balance at the provider until they are withdrawn, and the merchant remains their owner. Withdrawal is available on demand to a self-custodial wallet, to an exchange account, or to a supported banking channel.

Who this fits

The plugin route suits stores running a standard WooCommerce checkout that want crypto as an additional payment method alongside their existing ones. E-commerce verticals covered on the crypto payments for online stores page include electronics and hardware, digital goods and downloads, subscriptions, cross-border retail, and high-ticket and luxury items.

High-ticket stores need one extra conversation before launch. Transaction limits are set individually and depend on the asset, the merchant profile and the outcome of verification, so a store whose average order is well above retail norms should confirm its ceiling during onboarding rather than discover it on the first large order.

The jurisdiction in which the business is registered is settled at verification, not by where the store sells or what language it publishes in. That question belongs in the KYB paperwork, and it is worth raising early if the company structure is unusual.

Questions

Does this need a developer?
No, if the store runs a standard WooCommerce checkout. The plugin is a ZIP upload plus four fields copied from the dashboard, and no template or code changes are involved. Development work only enters the picture with the API route, which is for custom or headless checkouts.

How long does the whole thing take?
Business verification runs 1 to 3 business days from the moment documents are submitted, and the WordPress side takes under two hours. The two do not overlap: keys are issued after verification, so the plugin cannot be finished before the account opens. Plan the launch date from the document submission.

What happens if a buyer sends less than the invoice?
The invoice stays open with the status wrong_amount_waiting, and the remainder can still arrive within the invoice lifetime. If the lifetime expires with the amount short, the status becomes wrong_amount and the order needs a manual decision. Neither status closes the order as paid, so nothing ships automatically on a partial payment.

Can money be returned to a buyer?
Yes, in cryptocurrency, from the WooCommerce order screen. The separate Withdrawal API key has to be saved in the plugin settings first, and each refund carries the network fee of the rail it goes out on. There is no card-style chargeback path, so refunds are always a deliberate action on the merchant side.

What about the exchange rate moving between order and payment?
The invoice fixes the amount for its lifetime, selectable from 1 to 12 hours and set to 2 by default. Auto-conversion at the moment of receipt closes the remaining exposure by converting the incoming payment into a stablecoin or another settlement currency straight away. A shorter lifetime plus auto-conversion is the tighter combination, while a longer lifetime is friendlier to buyers moving funds off an exchange.

Does the same thing work on Shopify and Magento?
Both platforms are supported on the same merchant account, with the same rates and settlement options. The plugin pages for them are not published yet, so setup for those platforms runs through the dashboard and support rather than through a download page.