Accepting Crypto in WooCommerce: What the Plugin Actually Does

WooCommerce runs a large share of the independent web, and it accepts crypto through the same mechanism it accepts anything else: a payment gateway plugin that registers itself, renders something at checkout, and tells WooCommerce when the money arrived.

This piece is about the part that plugin guides skip. Installing is four clicks. What decides whether your store works on a bad day is how the plugin behaves when the webhook does not arrive, when the customer sends the wrong amount, and when the same notification arrives twice.

The five minutes of setup

1. 1Install and activate Oxialink Crypto Payments for WooCommerce.
2. 2Create a free Oxialink account and create a wallet for each coin you want to offer. This step is not optional and it is the most common reason a first test fails: a coin with no wallet has nowhere to settle, and the gateway says so rather than guessing.
3. 3In WooCommerce, go to Settings, then Payments, then Oxialink. Paste the API key, API secret and webhook secret from your dashboard, choose the coins, enable the gateway.

That is the whole installation. Everything below is what the plugin is doing on your behalf afterwards.

What the customer sees

The coin picker renders on both checkout types, which matters more than it sounds. WooCommerce has two: the classic shortcode checkout and the newer block-based one. They are different rendering paths with different data flows, and a plugin that only handles the classic one silently disappears from stores that have moved to blocks. The block integration passes the chosen coin through the Store API rather than a form post, because that is the only route a block checkout has.

Choosing a coin and placing the order creates an invoice and redirects to a hosted payment page with a QR code, the exact amount, and a live confirmation count. The customer is never asked for anything beyond the payment itself. No personal data leaves your store: the plugin sends the order total, the currency, the chosen coin, an order reference, and your callback URLs. Not the name, not the email, not the address.

What happens when the money arrives

A confirmed payment fires a webhook to your store, signed with HMAC-SHA256 over the delivery id, timestamp, event name and the exact bytes of the payload. The plugin verifies that signature against the raw body before it touches the order. This is the part worth being fussy about: a webhook endpoint that does not verify is an unauthenticated "mark this order paid" button on the public internet.

Then three things that only matter when something goes wrong.

The webhook that never arrives. Your server was down, or a security plugin ate the request, or the callback URL changed. Left alone, the order sits unpaid forever while the customer has genuinely paid, which is the worst possible outcome for both of you. The plugin schedules an hourly poll of every invoice still awaiting payment, so a dropped callback delays the order rather than stranding it. If you build your own integration, build this too; it is not optional.

The same webhook twice. Deliveries are at-least-once. A slow response can produce a retry for something you already handled, and fulfilling an order twice costs real money. Every delivery carries a unique id, and it exists to be deduplicated on.

The customer who underpays. Someone sends 94 USDT for a 100 USDT invoice, usually because their wallet deducted the network fee from the amount rather than adding it. The order goes on hold with a note recording what was received against what was requested, so a human can decide. It is not marked paid, and it is not silently cancelled with the money kept.

An expired invoice cancels the order and releases the stock.

Pricing in your own currency

An invoice is priced in whatever currency your store uses and converted at the rate when the customer checks out. That rate is then fixed for the life of the invoice, so a market move while the customer opens their wallet does not change what they owe.

Ten currencies are supported: USD, EUR, GBP, JPY, IDR, INR, SGD, MYR, AUD and CAD. A store priced in something else is refused at checkout with a message naming the ones that work, rather than being quoted an amount computed from a rate that does not exist. That refusal is deliberate. The alternative failure is silent and much worse.

Where it will not help you

Refunds are not automatic. There is no chargeback, which is the point, but it also means there is no reversal mechanism. Refunding a crypto payment means sending crypto back, by hand, from your wallet. If your business refunds often, price that in.

You still owe tax. A gateway that does not ask for your ID is not a permission slip. Revenue is revenue where you live.

Cashing out is a separate question with a separate answer. Accepting crypto needs nobody's approval. Converting it to your local currency happens at an exchange or a peer-to-peer market, and that business will run its own checks. Any gateway that implies otherwise is describing something it does not control.

A payment below the network minimum cannot be credited. Moving 2 USDT off a receiving address costs more in fees than the payment is worth, so the invoice is refused at creation rather than accepted and then quietly lost. The minimums are published and readable from the API.

Test it before you trust it

The sandbox runs the same code against public test networks, with faucets that hand out coins in under two minutes. Point the plugin at the sandbox base URL, pay an invoice with test TRX, and watch your order move to Processing. A webhook signature that verifies there verifies in production, because it is the same signing function.

Do this before you go live. It costs nothing, and it is the only way to find out that your webhook endpoint is behind a firewall while it is still cheap to find out.

A note on testing in WordPress Playground

WordPress Playground is excellent for checking that a plugin activates, that its settings screen renders, and that Plugin Check passes. It is not usable for testing a payment gateway. Its network proxy replaces the body of an upstream error response with its own text, so a perfectly good API error arrives at the plugin as an unreadable one. Use a real WordPress install, local or staging, for anything that leaves the site over HTTP.