Skip to main content

Go live

share-pay.co.uk is the live environment. Stripe Connect onboarding there verifies your real business, and real cards are charged.

Nothing carries over from the sandbox. Merchant records, API keys, webhook secrets, allowed domains and webhook URLs all exist separately in each environment, so every setting you made while testing has to be made again here. A sandbox API key returns 401 Invalid API Key against production, and a production key returns the same against the sandbox.

Swap these​

  • Register your business on the live site and complete Stripe Connect onboarding for real. This is a fresh registration, not a mode you switch on.
  • Confirm stripe_charges_enabled is true on GET /api/merchants/me. Until it is, every checkout session is rejected with Finish Stripe onboarding before accepting checkouts, and Stripe does not tell us when it declines a business. See Connect Stripe.
  • Point your base URL at https://api.share-pay.co.uk.
  • Swap in the live API key, from the Developers page. Keep it server-side: it must never reach a browser.
  • Set your allowed return domain to your real shop's hostname. Until it is set, every return_url is rejected — and remember it does not cover subdomains. See Set your allowed return domain.
  • Set your live webhook endpoint URL, and read the live webhook secret. It is a different value from the sandbox one, and verifying live deliveries against the sandbox secret fails every time. See Set your endpoint URL.

Check your handler​

  • You verify the signature on every delivery, over the raw request body, and reject anything older than a few minutes. SharePay signs the timestamp but does not enforce a freshness window for you. See Verify the signature.
  • You fulfil on checkout_split.paid only. A buyer landing back on your return_url means the split was set up, not that money moved.
  • Receiving the same event twice does no harm. There is no event id to match on, so recognise a repeat by data.split_id and type together. A resend delivers an event again, and cancelling an order yourself sends you the checkout_split.canceled webhook for it.
  • You read amounts as pounds. Webhook payloads and the session lookup give decimal strings in pounds; POST /api/checkout-splits uses pence. Never compare the two without converting.
  • You know webhook amounts are shares, before fees. Each matching Stripe charge is 20p bigger, because the customer paid the service fee on top. Check total_amount against your own order value, not against the sum of the Stripe charges.

Check what happens when things go wrong​

  • You do not depend on the webhook alone. Failed deliveries are never retried automatically. Store the session token against your order and poll it for anything that goes quiet. See Reconciling without a webhook.
  • You treat a 404 on the session lookup as "no answer yet", not as a cancelled order. A session that outlives its 2-hour window 404s while its split is still perfectly alive.
  • You have an alarm for silent orders. A split that fails during creation or breaks part-way through capture emits no webhook at all, so an order can go quiet after its participant_authorised events and never reach paid or canceled. Flag anything still unresolved after a few minutes rather than waiting on it. See When capture fails part-way.
  • You never blindly retry a request that timed out. Neither way of creating a split can tell a retry from a new request, so sending it again makes a second one — and a second set of card holds on your customers' cards. Check first, then retry.
  • You sweep the delivery log for failures, from the Developers page or GET /api/merchants/webhooks/deliveries. See Respond, and what happens if you do not.

Check your Stripe account​

  • Nothing of yours cancels uncaptured payments in Stripe. Every uncaptured hold on your Stripe account belongs to an order still waiting on approvals, and cancelling any single one of them cancels the whole order, permanently. If you run automated tidy-ups, skip ours: they are all tagged with checkout_split_id, participant_id, order_reference and participant_email. See Participants pay.
  • You know disputes are yours. Payments settle directly to your Stripe account, so a chargeback is between you and the cardholder and you submit the evidence in your own Stripe dashboard. There is no webhook for it; we email the login address of the account that owns the merchant. See Chargebacks.
  • You have checked your actual fee rate. The standard merchant fee is 3%, but your account's live rate is platform_fee_bps on GET /api/merchants/me, and a promotional rate reverts to the standard one at platform_fee_discount_ends_at. See what SharePay charges.

Check your shop and your team​

  • Your order emails expect ours. SharePay emails your participants directly, under your business name, at invite, capture and cancellation. It is not configurable and cannot be turned off. See what we email your customers.
  • The right colleagues have the right roles. Only Owner and Admin can see your API key or change your webhook settings; Finance can refund but not cancel; a Member can cancel but not refund. See Team access and roles.
  • Your checkout button uses the mark correctly, and spells the name SharePay. See Logo and brand.

After your first live order​

Run one real order through, for a small amount, with your own card. Then check three things agree: the split reads captured in your dashboard, your handler recorded a verified checkout_split.paid, and the charges are on your own Stripe account at the share plus 20p each.

If they disagree, do not ship the integration wider — get in touch.