內容簡介
BrickellPay Gateway for WooCommerce 讓您的商店透過 BrickellPay 接受信用卡和借記卡付款，具備智能路由和自動處理器故障轉移功能。此外掛與 WooCommerce 結帳整合，支援一次性及訂閱付款，並使用令牌化的卡片數據，減少 PCI 範圍。
【主要功能】
• 令牌化技術：客戶端瀏覽器中令牌化卡片數據
• 智能處理器路由：自動重試交易於備用處理器
• 實時支付狀態：使用 SignalR 提供通知
• 支援 WooCommerce 訂閱：自動續訂功能
• HPOS 兼容：支援高效能訂單儲存
• 從 WooCommerce 管理介面退款：直接在訂單畫面操作
外掛標籤
開發者團隊
② 後台搜尋「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:
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.
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
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.
