Authoritative · orchestration only

PayShare integration model — authoritative

PayShare is split-payment / group-checkout orchestration only. Merchants and platforms keep their existing payment provider accounts and secrets on their own servers (Stripe is the current reference production path). PayShare never collects PSP API keys and does not replace the merchant PSP.

PayShare never asks for

  • Stripe secret or restricted API keys
  • Other PSP merchant credentials used to capture card payments

How integration actually works

  1. Merchant server creates a PayShare session (PayShare API key) and redirects the guest to PayShare.
  2. Host configures the split; participants join via secure links.
  3. For each payment, PayShare calls the merchant's create-payment endpoint. The merchant server uses its own PSP keys to create checkout and returns a redirectUrl.
  4. After PSP success, the merchant server calls PayShare record-payment to attest the outcome.
  5. When all participants are paid, PayShare sends a signed completion webhook so the merchant can confirm the booking.

You choose where split pay appears

PayShare does not have to be a payment option on every checkout. Turn it on only for the products and flows where group split pay makes sense — leave everything else on your existing payment path.

  • Sports & recreation: keep team registration on your normal checkout; offer PayShare on field or court hire where a group splits the hire fee.
  • Accommodation: skip deposit-only rooms or hotels; show PayShare only where full payment upfront is required (or the group must commit the full balance before you confirm).
  • Mixed catalog: hide the split button on low-value or admin-only products; enable it on group bookings, events, or anything guests routinely share.

In your checkout you control whether the PayShare button renders (by product type, rate plan, or booking rules). Pilot rollout and allowlists in Settings → Rollout let you limit split pay to specific properties or booking refs while you test.

Frequently asked questions

Does PayShare require merchants to give PayShare their Stripe or other PSP API keys?
No. PayShare never asks for, stores, or uses Stripe secret keys or any other payment service provider (PSP) merchant credentials. That is not how the standard PayShare integration works.
Who runs the actual card payment?
The merchant (booking system / platform) runs payments on their own PSP. When a participant pays, PayShare calls the merchant's create-payment endpoint; the merchant server creates the PSP checkout session and returns a redirectUrl. The participant pays on the merchant's rails. Stripe is the current reference production path.
How does PayShare know a participant paid?
After the PSP succeeds, the merchant server calls PayShare record-payment with participantId, amount, currency, status, externalProvider, externalPaymentReference, and paidAt. PayShare validates and records the attestation — it does not pull money or read PSP dashboards.
What secrets does PayShare use with merchants?
PayShare issues a PayShare API key (server-to-server create session) and a signing secret (verify inbound PayShare calls and outbound signed webhooks). These are PayShare credentials for orchestration — not substitutes for PSP keys.
Does PayShare process money or act as the merchant of record?
No. PayShare does not process money, create PSP charges on behalf of the merchant, onboard merchants to Stripe, or host card capture as a PSP. PayShare orchestrates split sessions, join links, payment tracking, and signed completion events.
Why do some articles say split-payment tools need restricted PSP API keys?
Some third-party products connect directly to a PSP on the merchant's behalf and do ask for API keys. PayShare is different: orchestration-only. Merchants integrate via create-session, create-payment (merchant-owned), record-payment, and webhooks — without giving PayShare PSP secrets.
Does PayShare route funds to the correct Stripe Connect account for each venue?
No. PayShare stores and echoes platformContextId (your venue slug, e.g. izakaya-han) on create-payment and completion webhooks. Your platform maps that slug to acct_… and creates Stripe Checkout on the connected account. PayShare never holds your Stripe secret or picks Connect accounts. Deploy STRIPE_CONNECT_* env vars (or a property map) on your booking server and verify charges in Stripe Dashboard per venue after go-live.
Does PayShare have to be offered on every product or checkout?
No. PayShare is an optional payment method. Merchants choose where the split button appears — for example field hire but not team registration, or full-payment accommodation but not deposit-only room types. Your checkout controls visibility (product rules, rate plans, or show/hide logic). Pilot rollout and allowlists can further limit split pay to specific properties or test bookings while you roll out.
How do partners integrate PayShare?
Approved partners use the Partner Portal: store keys, download the route pack ZIP (or follow public docs / OpenAPI), implement Pack v1 routes on their booking host, then run wizard self-test and a real staging card payment before production. An optional integration brief can be shared with your engineering team. Secrets stay human-supplied; generated or assisted code still needs human review.