About this plugin
BrickellPay Gateway for WooCommerce lets your store accept credit and debit card payments through BrickellPay, a payment platform with smart routing and automatic processor failover. The plugin integrates with WooCommerce checkout, supports both one-time and subscription payments, and uses tokenized card data so your server never sees raw card numbers (PCI scope reduction).
Key features
- Hosted-field tokenization — card data is tokenized in the customer’s browser via the BrickellPay-provided iframe SDK, so your WordPress site never receives or stores raw PANs.
- Smart processor routing — when the primary processor declines, the gateway automatically retries the transaction on a configured fallback processor without re-prompting the customer. Routing rules are configured in your BrickellPay merchant account.
- Real-time payment status — uses SignalR to deliver KYC and payment notifications without polling.
- WooCommerce Subscriptions support — saved-card renewals work out of the box.
- HPOS-compatible — declares support for WooCommerce High-Performance Order Storage.
- Refund + void from the WooCommerce admin — managed directly on the order screen.
Requirements
- WordPress 6.2 or later
- PHP 7.4 or later
- WooCommerce 8.0 or later
- An active BrickellPay merchant account with API credentials (sign up at https://brickellpay.com)
- HTTPS on the storefront (required for any production card-acceptance flow)
External services
This plugin requires external services to function. Some are operated by BrickellPay; one is operated by a separate third-party company (IoniaPay). Both are documented below.
The exact hostnames may vary between sandbox and production environments.
Services operated by BrickellPay:
- BrickellPay API host — https://api.brickellpay.com/ (sandbox: https://sandbox.api.brickellpay.com/ ). REST API for server-side transaction operations.
- BrickellPay Tokenization Facade host — https://payments.brickellpay.com/ (sandbox: https://sandbox.payments.brickellpay.com/ ). Serves the tokenization facade JavaScript and the underlying tokenization/verify SDK modules. Also exposes a CORS-open proxy at /api/v2/consumer/* that the SDK calls from the customer’s browser to authenticate cards and verify transactions.
- BrickellPay SignalR notification hub — host provided per-merchant by the API’s /merchant-config endpoint. Separate WebSocket endpoint for real-time payment + KYC notifications.
Service operated by a third party (IoniaPay):
-
IoniaPay — operated by IoniaPay, LLC, a separate company from BrickellPay. IoniaPay is the card-tokenization and consumer-verification (KYC) provider used when your BrickellPay merchant account is configured to route through the Ionia processor. It is reached at two hosts:
- https://code.ionia.app/ — loaded in the customer’s browser. Serves the Ionia card-tokenization SDK ( /lib ) that renders the card form, and the Terms & Conditions documents ( /docs/toc_new.html, /docs/toc_existing.html ) shown to the customer inside the verification modal.
- https://sandbox.ioniapay.ionia.app/ — called from your server only (never from the browser). Used as a fallback for saved-card lookups when the BrickellPay API cannot resolve a stored card. Only reached in sandbox/test mode.
What is sent to IoniaPay, and when:
- When a customer reaches checkout on an Ionia-routed merchant, their browser loads the Ionia SDK and (for the verification step) the Terms & Conditions document. This discloses the customer’s IP address and user agent to IoniaPay, as with any browser request.
- When a customer submits card details, the card number, expiry, and CVV go from the SDK’s iframes directly to IoniaPay for tokenization. This data does not pass through your WordPress server.
- For consumer verification / KYC, the customer’s email address, phone number, name, and billing address are sent so IoniaPay can create or match a consumer record and deliver an SMS verification code.
- For saved-card lookups (sandbox/test mode only), your server sends the stored card identifier and a session token.
com/terms-of-service
com/privacy-policy
If your merchant account is not configured to route through Ionia, none of these Ionia hosts are contacted.
The plugin uses these hosts for the following operations:
- Tokenization facade — the plugin loads https://payments.brickellpay.com/js/embed/brickellpay-tokenization-facade-v1.js as a single script tag, and exposes a stable window.BrickellPay API to this plugin. The facade then lazy-loads the underlying tokenization and verify modules ( tokenization-X.Y.Z.min.js, verify-X.Y.Z.min.js ) from the Ionia CDN at https://code.ionia.app/lib — see the IoniaPay entry above; this is a third-party host, not a BrickellPay one. Both the facade URL and the SDK origin are overridable by environment variable or filter for self-hosted setups.
- Card tokenization (browser → facade) — when a customer enters card details at checkout, the form is rendered by the facade using VGS Collect iframes. Card data goes directly from the iframe to BrickellPay’s tokenization endpoint, then a token is returned. The PAN never reaches your WordPress server.
- Browser authentication and 3DS (browser → facade host) — the SDK posts to https://payments.brickellpay.com/api/v2/consumer/authenticate-browser and /verify-transaction/{id}/update from the customer’s origin. These are CORS-open endpoints owned by BrickellPay.
- Charge / authorization / capture / refund / void (server → API host) — the plugin sends transaction requests (amount, currency, billing address, customer email/phone) from your server to the BrickellPay API host.
- Real-time notifications (SignalR) — the customer’s browser opens a WebSocket to the BrickellPay SignalR hub to receive KYC + payment status updates. The Microsoft SignalR client library that initiates the WebSocket is bundled locally (Apache 2.0); the hub itself is a separate BrickellPay-controlled host.
The data sent includes: customer email, phone number, billing/shipping address, order amount, order line items, the WooCommerce order ID, and a tokenized payment method reference. Raw card data (PAN, CVV, expiry) is sent only from the browser iframe to BrickellPay, never from your WordPress server.
com/terms
com/privacy
Required Content-Security-Policy
If your site enforces a Content-Security-Policy, it must permit the following directives so the BrickellPay tokenization facade, the Ionia card-tokenization SDK, the Terms & Conditions frame, and the VGS Collect iframes can load:
com;
com in script-src and connect-src.
Bundled third-party libraries
- Microsoft SignalR JavaScript Client v6.0.1 — Apache License 2.0. Source: https://github.com/dotnet/aspnetcore. Bundled at assets/js/vendor/signalr.min.js; license notice at assets/js/vendor/signalr-NOTICE.txt. Used for real-time payment-status notifications.
- intl-tel-input v29.2.2 — MIT License. Source: https://github.com/jackocnr/intl-tel-input. Bundled at assets/js/vendor/intl-tel-input/dist/; license at assets/js/vendor/intl-tel-input/LICENSE. Used for the country selector and E.164 phone formatting/validation on the checkout verification step. The “WithUtils” build is bundled so no library file is fetched at runtime.
The BrickellPay tokenization SDK and verify SDK are normally not bundled — they are loaded at runtime from the BrickellPay tokenization facade (declared above under “External services”). js and is used only when the gateway is in test/sandbox mode, so that development environments do not depend on a deployment being live. Production installations always load the facade from the BrickellPay host.