v2.1.0 · WP 6.9 · WC 10.7 · PHP 8.3

Sell on one site.
Settle Stripe payments
through another.

Drop-in WordPress plugin for WooCommerce. Site 1 takes the order. Site 2's Stripe or Square account receives the money. Cart contents stay on Site 1. Processor sees a clean charge from Site 2's domain.

Buy via Telegram Read the docs →
Features

A two-site Stripe setup for WooCommerce, done as a plugin.

Built against the 2026 WooCommerce stack — HPOS-ready, Cart/Checkout Blocks-aware, PHP 8.3+. Configures end-to-end in under five minutes.

Stripe and Square supported

Works with WooCommerce Stripe Gateway 9.x and WooCommerce Square 5.x. Classic checkout, Cart/Checkout Blocks, Apple Pay, Google Pay, Express Checkout, Cash App.

Cart contents never leave Site 1

Product names, SKUs, descriptions, categories, and line items stay on the selling site. The payment request to Stripe only carries amount, currency, and a generic order reference. Processor sees a payment, not your catalog.

Site 2 credentials, Site 2 domain headers

Outbound HTTP requests carry Site 2's Stripe / Square keys, statement descriptors derived from Site 2's domain, and post-payment redirects that route through Site 2. Stripe's server-side fingerprint of the transaction looks like it came from Site 2.

Credentials encrypted at rest

Site 2 API keys are stored with libsodium XSalsa20-Poly1305 (AES-256-GCM fallback). Per-install key, masked in the admin UI, recursively redacted from debug logs.

Drop-in WordPress plugin

No theme changes, no functions.php hacks, no JavaScript surgery, no checkout rebuild. Install the .zip, paste Site 2 keys, flip the toggle. Uninstalls cleanly with `uninstall.php` removing both option keys.

Built for 2026 WooCommerce

WordPress 6.7+, WooCommerce 10.x, PHP 8.3+. HPOS-declared, Cart/Checkout Blocks integrated. Stripe API pinned to 2026-04-22.dahlia, Square pinned to 2026-04-21.

How it works

Four steps. The buyer sees nothing different.

The relay is transparent at checkout. Same form, same flow, same success page. The only thing that changes is whose Stripe account the money lands in.

01

Customer reaches checkout on Site 1

Standard WooCommerce checkout on your selling site. WC Stripe or WC Square renders its card form, Payment Element, or Web Payments SDK normally — the buyer sees exactly what they would on any WooCommerce store.

02

Plugin rewrites the outbound request

Right before the HTTP call to Stripe or Square leaves your server, the plugin intercepts it. Site 1's credentials are swapped for Site 2's. The Authorization header, the publishable key, the application/location IDs — all replaced.

03

Cart-level data is removed from the payload

Line items, product names, SKUs, descriptions, categories, and product metadata are stripped. Only the fields the processor actually needs (amount, currency, billing details, order reference) are sent to Stripe / Square.

04

Charge settles into Site 2's account

Stripe or Square processes the charge under Site 2's account. Funds land in Site 2's connected bank. Statement descriptor reflects Site 2. From the processor's side, the transaction looks like a payment to Site 2.

Use cases

When you want Site 1 and Site 2 separated.

If any of these describe your operation, the plugin solves your problem out of the box.

Run your storefront on a different domain than your processor account

Stripe and Square approve accounts under a specific domain. If you want to sell on a domain that isn't the one you registered the processor account under, you need either a checkout rebuild or this plugin. The plugin is faster.

Multiple storefronts, one Stripe account

You run several WooCommerce stores under different brands or niches. You want all of them to settle into a single Stripe / Square account for cleaner accounting and a single payout flow. Install the plugin on each store, point them all at the same Site 2 credentials.

High-risk vertical, low-risk processor face

The vertical you sell in is processable but flagged. You want the Stripe account to live on a domain that doesn't expose the vertical. Site 1 sells the products. Site 2 is whatever the processor sees — a generic landing page, a service site, a B2B brand page.

Separate the checkout from the brand

You want the customer to see one brand at checkout (Site 1) and a different entity on their card statement (Site 2). Useful for white-label storefronts, reseller setups, or anywhere the customer-facing brand and the legal payment entity intentionally don't match.

Pricing

One price. Unlimited installs.

Lifetime license, all future updates included, no subscription. Delivered manually via Telegram within hours of payment confirmation.

Lifetime

Payment Gateway Relay

$249 one-time
  • ✓ Use on unlimited WooCommerce stores
  • ✓ Stripe and Square gateways supported
  • ✓ Obfuscated source distribution + README
  • ✓ Every future update, free for life
  • ✓ Direct Telegram support from the author
Message @lucimornens to buy

BTC and USDT (TRC-20 / ERC-20) accepted; other crypto on request. Delivery typically within an hour of payment confirmation.

FAQ

Common questions.

If something isn't clear, message @lucimornens on Telegram before buying — happy to walk through your specific setup.

What problem does this solve?
You operate a WooCommerce store on Site 1. You have a Stripe (or Square) account on Site 2. You want every payment processed on Site 1 to settle into the Site 2 account, with Site 2's domain and credentials used in the outbound request. That's what this plugin does.
Do I need a Stripe or Square account configured directly on Site 1?
No, not really. You need the WC Stripe Gateway (or WC Square) plugin installed and active on Site 1 so the payment method appears at checkout. The credentials it has configured are overridden by the relay before any request goes out — you can leave dummy values in WC Stripe's own settings and the relay still works.
What does Stripe actually see on the receiving end?
Stripe sees a charge created with Site 2's secret key, against Site 2's account. The Stripe API version is pinned, the Stripe-Account header is stripped, the statement descriptor is derived from the Site 2 domain you configured, and the return URL points to Site 2. The product, SKU, line items, and cart contents from Site 1 are not sent.
Does the buyer see anything different at checkout?
No. The checkout form is rendered by the WC Stripe / WC Square plugin as usual on Site 1. The brand on the receipt and statement descriptor will reflect Site 2. Configure Site 2 to match the brand experience you want the customer to see post-purchase.
Does it work with subscriptions, Apple Pay, Google Pay, Cash App, 3DS?
Yes. Stripe Subscriptions, Stripe Payment Element, Apple Pay, Google Pay, Express Checkout, 3DS challenge flows, and the full Square Web Payments SDK (cards, Apple/Google Pay, Cash App Pay, 3DS) are all supported.
Does it work with WooCommerce Blocks checkout?
Yes. The plugin registers a Cart/Checkout Blocks integration that overrides the Stripe publishable key and Square application/location IDs at runtime, so Blocks renders the payment form against the Site 2 account. Classic shortcode checkout works too.
Are Site 2 credentials safe in the database?
Secrets are encrypted at rest using libsodium authenticated encryption (XSalsa20-Poly1305) with AES-256-GCM as a fallback. The encryption key is generated per install and stored alongside other WordPress site secrets. Values are masked in the admin UI and recursively redacted from debug logs.
How is the plugin delivered?
After payment confirmation we send a single .zip file via Telegram DM. Upload through WordPress → Plugins → Add New → Upload Plugin, activate, and configure under WooCommerce → Gateway Relay. Average delivery is under an hour from payment confirmation.
Refund policy?
No refunds. You're paying for a digital deliverable that ships immediately. If you're unsure, ask for a sandbox walkthrough on Telegram before you buy.

Ready to split Site 1 and Site 2?

Drops into any modern WooCommerce store in under five minutes.

Talk to us on Telegram