Skip to content

Going live

Test mode and live mode are the same API. Going live is about who you are, and about the keys.

The card networks need to know who is taking the money: the business, the people behind it, and the bank account payouts go to. Going live in the Tuppence app walks you through it, one step at a time, and ends with a quick identity check — a photo of your ID and a selfie, done with Stripe Identity. Verification is Stripe’s: the details you type pass through Tuppence on their way to Stripe and are not stored by us; your bank account number and your ID photos go straight to Stripe and never reach our servers at all. Until it is complete, live keys refuse payments (onboarding_incomplete) and the dashboard’s Live switch stays off.

Create live keys (sk_live_…) under Developers → API keys in live mode, store them as you store any production secret, and replace the test keys in your production configuration. A test key never touches live data, and a live key never touches test data.

Prefer restricted keys (rk_live_…) with only the scopes each service needs, and an IP allowlist where the caller’s addresses are fixed.

  • Webhook endpoints created in live mode, https://, with their live secrets stored.
  • Every POST sends an Idempotency-Key (the SDKs do).
  • You branch on error code, and retry only what should be retried.
  • Your branding (Settings → Branding) says who you are on the pay page, receipts and emails — payers dispute what they do not recognise.
  • A person on your team gets alerts (Settings → Notifications): disputes have deadlines.
  • You know your payout schedule (Balance → Payouts): weekly on Mondays once £50 is available, and a sweep at month end.

The fee is fixed when a card is presented and shown on every payment with how it was worked out. A refund gives the payer everything back and does not return our fee; a dispute costs a fee only if it is lost (pricing). Your monthly statement (Reports → Monthly statements) ties every penny to the balance Stripe holds for you.