All three work against both the hosted service and a self-hosted instance — everything goes through the public
/api/v1/* API and hosted checkout pages.
Option 1: Payment links (no code)
A payment link is a reusable URL (https://your-instance.com/l/{slug}) with a fixed price. Every visitor who opens it gets their own checkout session and unique deposit address. No plugin needed — you just put the URL on your site.
1
Create the link
In the dashboard, go to Payment Links → New link and set the title, price, and currency. Optionally set:
- Success URL — a page on your WordPress site to send the customer to after payment, e.g.
https://your-site.com/thank-you/. - Cancel URL — where to send them if they back out.
/l/{slug}).2
Put it on your site
In the block editor, add a Buttons block, label it (e.g. “Pay with crypto”), and set the button’s link to the checkout URL. Any other mechanism works too — a nav menu item, a classic-editor hyperlink, or a raw HTML block:If your page already collects the customer’s email (a form, a logged-in user), append it so the checkout skips the email step:
3
Know when you've been paid
Payments appear in the dashboard under Sessions, and you get a notification for each confirmed payment. For automated fulfillment (grant access, send a file), add a webhook — that’s the custom integration below, which composes with payment links: the webhook fires for link payments too.
The success-URL redirect is a convenience, not proof of payment — a customer can open that page directly. If anything of value is delivered automatically, gate it on a webhook or on the session status from the API, never on the redirect alone.
Option 2: The WooCommerce plugin
If your store runs WooCommerce, use the MyCryptoServer for WooCommerce gateway plugin. It adds “Pay with crypto” at checkout, redirects the customer to the hosted payment page, and automatically moves the order On hold → Processing when the on-chain payment confirms, via a signed webhook back to your store. Download it from Dashboard → Integrations → WordPress: enter your store URL, pick live or test mode, and you get a zip pre-configured for your store — the API key and webhook endpoint are provisioned automatically and baked into the download, so setup is upload → activate → enable the gateway. No credentials to copy-paste. Highlights:- WordPress 6.0+, WooCommerce 7.0+, PHP 7.4+; supports HPOS and the block-based Checkout.
- Order statuses map to session events (
session.paid→payment_complete(),session.expired→ Failed,session.underpaid→ kept On hold for review). - Webhook processing is idempotent, every delivery is logged, and there’s a Test send webhook button to verify the round-trip before going live.
Option 3: Custom integration via the REST API
For anything the plugin doesn’t cover — membership/LMS plugins, custom order forms, a non-WooCommerce cart — integrate directly: create a checkout session server-side, redirect the customer, and fulfill on a signed webhook. It’s roughly 60 lines of PHP.Prerequisites
- An API key (API Keys → New API Key) with the
sessions:writescope. See Authentication. - A webhook endpoint (Webhooks → Add endpoint) pointing at the REST route you’ll register below, subscribed to the
session.*events. Copy thewhsec_...signing secret — it’s shown only once.
wp-config.php is the conventional place:
Create a session and redirect
CallPOST /api/v1/checkout_sessions when the customer is ready to pay, store the returned session id against your own record, and redirect to checkoutUrl:
{ "linkId": "...", "metadata": {...} } instead of amount — the price then comes from the link. See Checkout Sessions for both modes.
Receive webhooks
Register a REST route and verify the signature on every delivery. Two details matter:- Correlate by session id. Event payloads identify the session as
data.sessionIdand do not echo back yourmetadata— match deliveries to your records using the session id you stored at creation time. - Be idempotent. Failed or slow responses are retried (up to 6 attempts over ~31 hours), so the same event can arrive more than once. Fulfilling twice must be harmless.
2xx within 30 seconds — do heavy work (emails, license generation) after responding, or queue it. You can inspect and replay any delivery from Webhooks → Deliveries, and fire a synthetic session.paid at your endpoint with the test endpoint before taking real payments. Full payload and signature details are in Webhooks.
Local development
The repo ships a compose file that runs WordPress with the plugin source mounted live, plus a local Anvil chain — useful for hacking on the WooCommerce plugin or testing a custom integration end to end:
Pair it with the main
docker-compose.yml (web + watcher) for a fully scriptable payment loop without touching a testnet. Use a ck_test_... key throughout; test-mode sessions and events are flagged livemode: false.
Webhooks need a URL the MyCryptoServer instance can reach. When both stacks run in Docker on the same machine,
http://host.docker.internal:8080/wp-json/... works; for a hosted instance pointing at a local WordPress, tunnel it (e.g. cloudflared, ngrok).Security checklist
- API key stays server-side — in
wp-config.phpor the gateway settings, never in JavaScript, page content, or a public repo. - Verify every webhook signature before acting on the payload; reject timestamps older than ~5 minutes. Both the WooCommerce plugin and the sample above do this.
- Fulfill on webhooks, not redirects — the success URL can be opened by anyone.
- Serve everything over HTTPS — webhook endpoints and checkout redirects included.
- Scope keys minimally — a store only needs
sessions:write(pluswebhooks:writeif you want the plugin’s Test-send button).
Troubleshooting
WooCommerce-plugin-specific issues (gateway not visible, orders stuck On hold, Test send failures) are covered in the WooCommerce guide.