Woo multi-store
Store role on each shop, Payment role on the hub — catalog sync and status back to Woo orders.
Solutions
One payment hub. Many kinds of storefronts.
The Payment Hub stays on WordPress. Your shops can be WooCommerce, agency client sites, or any custom stack that speaks the Custom Store API.
Who FinPay is for
Built for networks — not a single shop
Pick the path that matches how you sell. Every path lands on the same Payment Hub, PayPal checkout, and status sync.
Agencies
Mint client stores under licensed seats. Per-store credentials without rebuilding payment for every site.
Custom platforms
Laravel, Node, headless — keep your commerce stack. FinPay is the payment destination.
Fit check
Choose FinPay when this sounds familiar
Many shops, one processor
You want one PayPal destination without merging every storefront into a single Woo install.
Mixed stacks
Some shops are Woo, others are Laravel or headless — and they must share the same hub.
Agency portfolios
You mint client stores under seats and need attribution without rebuilding payment each time.
WooCommerce brands
Multi-store checkout without splitting PayPal
Install FinPay as Store on each shop and Payment on the hub domain. Customers stay on familiar Woo carts; money clears on one payment site.
- Each store keeps catalog, pricing, and customer experience
- Selected products sync to the hub with optional masking for PayPal
- Checkout creates a hub payment session; status returns over HMAC REST
- Customer emails stay on the store — hub bridged orders skip duplicate mail
Agencies & portfolios
Many client storefronts. One payment site.
Run payment once, then mint and connect client stores under your LicensePress seats — with clear attribution on every bridged order.
- Mint stores from the hub under plan seat limits
- Per-store credentials and attribution on hub orders
- Disable, regenerate, or disconnect without tearing down the hub
- Growth and Scale plans when clients need support and installation
Custom & non-WordPress
Keep Laravel, Node, or headless. Connect the hub.
Anything that can sign HMAC envelopes and expose a status webhook can use FinPay as the payment destination — no forced rebuild in WordPress.
- Store hub URL, store id, and API secret server-side
- Sign health, connect, product_sync, fee_info, and create_payment
- Verify webhook signatures and mark orders paid
- Optional iframe checkout — postMessage is UI-only
Ownership boundaries
What stays on the store. What lives on the hub.
FinPay does not take over your catalog UI or customer accounts. It separates payment responsibility so networks can grow without a forced rebuild.
- Store: browse, cart, customer email, order ownership
- Hub: PayPal, registry, masked catalog, bridged orders
- Status notify is the source of truth for “paid”
Shared outcomes
Same results across every path
Whether you sell on Woo or a custom stack, the hub delivers the same payment story.
One destination
PayPal today; Stripe on the roadmap.
Attribution
Every bridged order knows its originating store.
Status back
Signed notify finalizes the origin order.
Masked catalog
Clean processor-facing receipts.
Retry path
Recover when status notification fails.
Ready to map your network?
Walk the full workflow or pick a plan with the seats you need.