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.

Woo multi-store

Store role on each shop, Payment role on the hub — catalog sync and status back to Woo orders.

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
See Woo workflow →

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
Compare agency-ready plans →

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
Custom platforms guide →

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.