Testing

Two ways to run the whole flow without moving money:

• Test keys on your own account. A key that starts sp_test_ works against the live API and creates test splits. Nothing you configure needs copying anywhere when you go live: switch the key.
• The sandbox at demo.share-pay.co.uk, a separate environment with Stripe test cards.

Test keys

In the dashboard, choose Switch to test mode from the profile menu at the top of the sidebar (on the phone, on the business profile), then create a key under Settings, Developers. From the API, call POST /api/merchants/api-keys with the header x-sharepay-mode: test. A test key needs nothing verified.

While the dashboard is in test mode an amber Test mode bar runs across the top, and every list shows test records only. The choice is remembered per business on each device, so a colleague's dashboard is not moved by yours. Test invoices are numbered from their own sequence, TEST-INV-0001 onwards, so the live numbering has no gaps. Every checkout it opens, and every split made from that checkout, is a test:

• No real card is charged. Test splits run on one of two processors:

  • Your Stripe test account, if you have connected one in test mode (Settings, Payments, Connect Stripe, while in test mode). It is a separate Stripe account from your live one, and payers use Stripe's test cards, such as 4242 4242 4242 4242. A real card is declined there. Where SharePay has not switched Stripe test accounts on, connecting says so, and test splits run on the simulated processor below.
  • A simulated processor otherwise, so test splits work before you have connected anything. The pay page offers a Test result instead of a card form: Approved, Declined or Insufficient funds. A decline leaves the share unpaid and payable again, as a declined card does.

• The pay page says it is a test, above the card form or the test result.

• Emails still go to the addresses you give, so you can see them, with [TEST] at the start of the subject and a line at the top saying no money moves.

• Webhooks go to a separate test URL, never your live one. Set it on the Developers page while in test mode; it has its own signing secret. With no test URL, test events are not sent. They carry livemode: false. See Webhooks.

• Nothing is billed. No fee is taken and nothing is added to your monthly bill.

• Test invoices need less. A legal name and a business address, plus bank details when the customer pays by bank transfer. No identity check and no Companies House check: nobody is being invoiced. A live invoice needs all of those too.

Holds, captures, cancellations, expiry and refunds all behave as they do live, with the same statuses and the same events.

A key acts only in its own mode. A test key cannot refund, remind on or read the status of a live order, and a live key cannot touch a test one. Either returns 404, the same answer as for an order that is not yours.

Test and live keys are listed separately: GET /api/merchants/api-keys with x-sharepay-mode: test lists only test keys, and without it only live ones.

The sandbox is a separate environment

The sandbox runs real Stripe test mode, so it is the place to try Stripe's own test cards: declines, authentication challenges and disputes.

	Production	Sandbox
Site	https://share-pay.co.uk	https://demo.share-pay.co.uk
API base	https://api.share-pay.co.uk	https://demo.share-pay.co.uk/api
Stripe	Live mode, real cards	Test mode, test cards
Accounts and keys	Your live merchant	Separate. Register again

It is not a mode you switch on. It is a different backend, on a different database, with different Stripe keys. Merchant records, API keys and webhook secrets do not cross between the two, so your production API key returns 401 Invalid API Key against the sandbox, and a sandbox key returns the same against production.

To set up:

1. Register an account at demo.share-pay.co.uk and become a merchant there.
2. Complete Stripe Connect onboarding again on the sandbox. It runs in Stripe test mode, so it verifies nothing real.
3. Set your allowed return domain and webhook URL on the sandbox Developers page. They are separate settings from your live ones.
4. Create an API key on the sandbox Developers page and point your integration's base URL at https://demo.share-pay.co.uk/api. The key is shown once, so copy it then. As in production, creating a key there needs the sandbox business verified.

Everything else in these docs, endpoints, payloads, signatures and statuses, is identical between the two.

Test cards

A card that always succeeds:

4242 4242 4242 4242
Any future expiry date, any CVC

Stripe's own test card list covers declines, authentication challenges and disputes. Anything Stripe supports in test mode works here, because our holds are ordinary Stripe payments on an ordinary test-mode Stripe account.

A reference integration

A working storefront runs at shop.share-pay.co.uk against the sandbox. It does the four things every merchant integration does: creates a checkout session with an API key from its own server, redirects the shopper, verifies checks the X-SharePay-Signature header on the way back (rejecting bad signatures, and anything older than 300 seconds), and fulfils the order on checkout_split.paid. If a detail on Hosted checkout or Webhooks is ambiguous, that is the thing to compare against.

Going live

share-pay.co.uk is the live environment. Stripe Connect onboarding there verifies your real business, and real cards are charged. Nothing you configured on the sandbox carries over, so work through the go-live checklist before you take a real order.