Skip to main content
There are three ways to take crypto payments on a WordPress site with MyCryptoServer, in increasing order of effort: 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. 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.
Copy the checkout URL (/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.paidpayment_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.
The full walkthrough — installation, API key scopes, webhook setup, status mapping, troubleshooting — is on the dedicated WooCommerce page.

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

  1. An API key (API Keys → New API Key) with the sessions:write scope. See Authentication.
  2. A webhook endpoint (Webhooks → Add endpoint) pointing at the REST route you’ll register below, subscribed to the session.* events. Copy the whsec_... signing secret — it’s shown only once.
Keep the credentials out of the database and out of client-side code. wp-config.php is the conventional place:

Create a session and redirect

Call POST /api/v1/checkout_sessions when the customer is ready to pay, store the returned session id against your own record, and redirect to checkoutUrl:
If you sell fixed-price items you’ve already defined as payment links, pass { "linkId": "...", "metadata": {...} } instead of amount — the price then comes from the link. See Checkout Sessions for both modes.
Never call the API from the browser. A ck_ key in front-end JavaScript is public — anyone can read it from the page source. Session creation belongs in PHP (or any server-side code), as above.

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.sessionId and do not echo back your metadata — 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.
Your endpoint URL is then:
Register that URL in Webhooks → Add endpoint. Respond 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.php or 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 (plus webhooks:write if 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.