Select one or more tags, then press “Search Plugins”

Find Plugin with any / all of the selected criteria
Search Plugin

BrickellPay Gateway For WooCommerce Wordpress Plugin - Rating, Reviews, Demo & Download

BrickellPay Gateway For WooCommerce Wordpress Plugin - Rating, Reviews, Demo & Download
No ratings yet
Free
Follow for free plugins, new theme releases and theme news

Plugin Description

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.

Screenshots

No screenshots provided

Similar Plugins:

Rating Widget: Post Rating, 5 Star Rating, Reviews, Thumbs Up & Down, Reaction Default ThumbnailReviews And Rating – Google Reviews Reviews Feed – Google Reviews & Yelp Reviews Plugin

Reviews & Comments