Testing & self-test

Wizard self-test steps and required card E2E after green.

Integration Wizard → Run self-test exercises PayShare and your merchant server in order. Fix the first failing step before re-running.

Self-test steps (summary)

  1. Webhook reachable
  2. Start session
  3. Host checkout URL (create-payment)
  4. Guest checkout URL (create-payment)
  5. Merchant stripe-success route exists
  6. Confirm payments (record-payment)
  7. Completion webhook
  8. Organiser return URL (when allowlisted)
  9. Idempotent replay

Staging checklist

  • Deploy create-payment and stripe-success on the same origin as production paths.
  • Use Stripe test mode keys; verify payments on the correct connected account in Dashboard.
  • Log platformContextId and stripeAccount at create and retrieve.

Pilot rollout (button visibility vs live create gating)

PayShare cannot decide where your PayShare button appears — that’s controlled by your checkout UI. Unless you explicitly gate it on your end, the button can be visible and clickable on every checkout your system renders.

What PayShare can do is restrict which live sessions your system is allowed to create during rollout. In pilot mode, live session creation is blocked unless the request matches your pilot rules.

  • If a checkout is allowlisted, your normal “Split with PayShare” flow works.
  • If a checkout is not allowlisted, your PayShare button will show a disabled state like “Split with PayShare — unavailable” and do nothing on click (or show a small tooltip).

Pick the identifier that matches how you want to roll out:

  • One property / hotel / site → allowlist platformContextId only (e.g. hotel_001).
  • One or a few bookings → allowlist merchantOrderRef only.
  • One website domain → allowlist return URL origin only (e.g. https://yoursite.com).
  • Stricter rollout → combine more than one box (session must match every allowlist you filled in).