BrickellPay Gateway for WooCommerce

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:

1. BrickellPay API host — https://api.brickellpay.com/ (sandbox: https://sandbox.api.brickellpay.com/). REST API for server-side transaction operations.
2. 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.
3. 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):

1. 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.

   IoniaPay terms of service: https://ioniapay.com/terms-of-service
   IoniaPay privacy policy: https://ioniapay.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.

BrickellPay terms of service: https://brickellpay.com/terms
BrickellPay privacy policy: https://brickellpay.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:

script-src  'self' https://payments.brickellpay.com https://code.ionia.app https://js.verygoodvault.com;
frame-src   'self' https://code.ionia.app https://*.verygoodvault.com;
connect-src 'self' https://payments.brickellpay.com <your-merchant-API-URL>;
img-src     'self' data: https://payments.brickellpay.com;

For sandbox installations, also allow https://sandbox.payments.brickellpay.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”). One exception: a point-in-time copy of the facade script is included at assets/js/vendor/brickellpay-tokenization-facade-v2.0.0-local.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.