To accept crypto on a WordPress site, select an integration whose current documentation explicitly supports your checkout setup, then configure and verify it according to those instructions before enabling live use. A plugin and a custom connection require different preparation, and the evidence available here does not establish particular WordPress plugins, version requirements, installation sources, or security practices. Treat those as details to confirm for the integration you choose—not as features you can assume from a provider’s general payment API.

Choose a WordPress integration route

A plugin-based route uses a WordPress extension to connect payment functionality to the site. A custom route requires a developer to connect the site’s checkout to an external payment service. Neither label establishes compatibility by itself: the important question is whether the selected integration documents support for the specific WordPress version, theme, and checkout extension in use.

Before choosing, review the integration’s current documentation for supported configurations, dependencies, installation instructions, maintenance guidance, and any requirements imposed by the checkout system. Check that the material describes a WordPress integration rather than only a general-purpose API. If the documentation leaves compatibility unclear, ask the integration’s technical support or a qualified WordPress developer before installing or commissioning custom work.

A provider API can illustrate why this distinction matters. Coinbase’s Payment Acceptance API documentation lists resources for payment authorization, capture, charges, voids, refunds, webhook configuration, event queries, and delivery monitoring. That is a description of the documented API resources; it does not show that a WordPress plugin exists, that a particular checkout extension is supported, or that every listed operation is exposed in a WordPress interface. source

For a plugin, compare the documented setup requirements with the site’s existing checkout and administration process. For custom work, identify what the developer must build and which pieces the external service supplies. Do not treat a custom connection as a simple configuration choice if the documentation instead requires development. The evidence here does not establish which route is faster, less expensive, or more suitable for a particular site, so make that decision from the actual requirements and support available for the selected integration.

Prepare the site before enabling crypto payments

First, identify the checkout system in use and who is authorized to administer WordPress and its payment settings. This gives the site owner a clear path for reviewing configuration and coordinating changes. Then check the site’s own backup, staging, and update process before altering checkout settings. These are prudent preparation steps, not a claim that a particular WordPress tool or workflow is required.

Next, use the chosen integration’s documentation to build a short prerequisite list. Confirm the supported WordPress and checkout configuration, any dependencies, and the installation and setup steps. If the integration documents a test mode, note how it is enabled and what it covers. Do not infer a test facility from another product’s documentation or from a general API reference.

Keep this technical review separate from questions about geographic availability, legal obligations, or taxes. Those matters depend on the relevant service and circumstances, and this guide does not establish an answer for any jurisdiction. Resolve them separately where applicable rather than treating successful WordPress configuration as proof that every other requirement has been addressed.

Before making changes, decide who will perform them and how the site owner will review the resulting checkout configuration. If a developer is involved, ask for a concise record of the integration’s dependencies, settings changed, and documentation followed. This does not replace the provider’s instructions; it helps the site team understand what was configured and who can maintain it later.

Configure the payment integration in WordPress

For a plugin route, follow the selected integration’s current setup documentation and use an installation source that the documentation identifies as appropriate. The evidence available here does not name a WordPress plugin or establish a recommended source, so do not substitute a generic installation recipe for product-specific instructions. Confirm that the plugin’s documented requirements match the site before proceeding.

For a custom route, define the WordPress extension point and the connection to the external service before implementation begins. Agree with the developer on how credentials and other sensitive configuration will be handled, and require the approach to be supported by relevant technical documentation and review. The evidence available here does not establish a secure WordPress credential-storage design. Avoid placing sensitive settings in public page content or client-side code, and do not describe any particular storage method as secure without evidence for that specific implementation.

After installation or development, configure only the payment options and site-facing checkout settings documented for the selected integration. Check where the payment option is intended to appear and whether the instructions apply to the site’s checkout extension. A setting shown in one provider’s API reference is not proof that a WordPress integration exposes that setting, or that the same configuration steps apply to another service.

Keep a record of the documented configuration and the person responsible for it. For a plugin, that record can identify the plugin and the instructions followed; for custom work, it can describe the extension point and the relevant service documentation. This is a maintenance aid, not a claim that documentation alone proves the implementation is correct. If the setup depends on an undocumented assumption, pause and seek clarification rather than silently treating that assumption as an integration feature.

Verify the WordPress setup before launch

Use a test or staging mode only if the integration documents one. Follow its instructions to determine what the mode simulates and how the site returns to its intended configuration. The evidence available here does not establish that every WordPress integration offers test transactions or that different integrations test the same behavior.

Check that the payment option appears at the intended point in the WordPress checkout and that the rest of the checkout remains usable on the site’s supported layouts. Then verify the integration’s documented outcomes in the relevant WordPress administration workflow. Confirm which statuses the integration reports and where the site displays them; do not assume that success, failure, and cancellation use universal names or behave identically across services.

One implementation example shows why status behavior should be checked rather than guessed. BTCPay Server’s e-commerce integration guidance describes states such as processing, settled, expired, invalid, partial, overpaid, and late, and calls for webhook-signature validation before an order is updated. Those details are specific to that integration guidance. They do not establish a universal WordPress status list or a requirement that every integration use the same mechanism. source

As part of the WordPress-specific review, confirm that the expected payment option and documented status information can be found by the people who administer orders. If an outcome is missing or unclear, compare what appears in WordPress with the integration’s documentation and ask the provider or developer to explain the discrepancy. This is a configuration check, not a substitute for a broader website payment-lifecycle design, which is outside this article’s scope.

Do not enable live use merely because the option appears on the checkout page. Verify the documented setup requirements and status behavior first, and resolve any mismatch that could leave site administrators unable to interpret the integration’s reported state. The precise verification steps depend on the integration; use its current instructions rather than extrapolating from another product’s example.

Plan maintenance and know when to pause

Before updating WordPress, the checkout extension, or the payment integration, review the compatibility and update guidance for the specific combination in use. A change to one component can make previously followed setup instructions less applicable, so check the integration’s documentation again when the site changes. The evidence here does not establish an update schedule or a universal maintenance procedure.

Document who owns the payment settings and configuration changes, where the current integration instructions are kept, and whom to contact when actual behavior differs from the documentation. For a custom implementation, include the developer or technical support contact responsible for explaining the connection. For a plugin, identify the appropriate support route using the integration’s own materials rather than assuming support arrangements.

Pause rollout if the documentation does not clearly address compatibility, the statuses the integration reports, or the handling of sensitive configuration. Ask the provider or qualified technical support for clarification before enabling live use. Do not assume that payments can be reversed or recovered, or that a configuration has a particular security property, unless the selected integration’s documentation supports that statement.

This workflow is limited to WordPress route selection, site preparation, configuration, verification, and maintenance. It does not provide a general design for checkout lifecycles, callbacks, refunds, or reconciliation across websites. Use a broader implementation guide for those subjects, and rely on the selected integration’s current documentation for its specific WordPress behavior.

Sources and references