Built so a mistake can’t move money.
Card data never reaches us. Keys do only what you allow. Agents ask before they spend. Every API write is safe to retry, so a timeout never becomes a double charge.
TuppenceCard numbers never pass through us.
Payers type their card into secure fields that send it straight to our PCI DSS Level 1 card processor, and Tuppence gets back a token. Card numbers stay out of our servers, logs, SDKs and tests, and Tuppence stays in the shortest PCI DSS self-assessment, SAQ A.
Checked on every change
Every build scans our code and browser files for anything shaped like a card number, and fails if it finds one.
Redacted even if you send one
We strip secrets and anything that looks like a card number from every log line, even inside a payment’s description.
A locked-down pay page
Our hosted pay pages run a strict Content Security Policy, checked on every build, so nothing but our card processor can receive card data.
Tuppence cards too
Tuppence card details appear in a secure frame in your browser, never through our servers. We hold only the card’s ID and last four digits.
Keys, people and records.
Scoped API keys
Secret, publishable and restricted keys, separate for test and live. A restricted key has only the permissions you give it, and an IP allowlist can pin a key to your servers.
Leaked-key response
If a secret key turns up somewhere public, we revoke it at once and alert you.
Two-factor sign-in
Codes from an authenticator app, or by text message once texts are switched on. Roles limit who can refund or change settings, and the app asks for Face ID before a refund or unfreezing a card.
Audit log
Who changed what, and when: keys, team members and settings.
Request logs
Every API request for 30 days: what your code sent and what came back. Secrets are removed before storage.
Signed webhooks
Every event is signed, so your server can verify it came from us. Rotate the signing secret at any time.
Trust that grows with your history.
Fraud costs honest businesses most. We check who we work with, monitor activity, and give each account more room as it trades cleanly.
A person reviews new businesses
Someone on our team reviews every business before it takes live payments.
Identity checks
The people behind a business confirm who they are with a photo ID and a selfie, checked by our identity verification partner.
Automatic monitoring
We watch for card testing, sudden spikes and other signs of non-genuine sales, and can hold payouts while we investigate.
Limits that grow
New accounts start with limits on payments and payouts, and a rolling reserve. They ease as you build a clean trading history.
Nothing hidden
The dashboard and the app show your limits, your usage and any hold, with what we need from you to lift it.
In our terms
Our terms set out how limits, holds and reserves work.
Agents can ask. People decide.
Agents get their own keys and identities. Tuppence enforces every limit outside the model, so no prompt can get past one.
Only the tools it needs
An agent on a restricted key sees only the MCP tools its permissions allow.
Hard limits on cards
Per-card limits, allowed merchant types and countries, and a person’s approval above an amount you set, checked in real time on every purchase.
Payers approve
A payment an agent starts waits for the payer on a hosted page. A saved card is charged only under terms the payer agreed to, and unusual charges can ask them to authenticate again.
Signed identities
Agents can sign each request with their own key pair, so anyone can verify which agent did what.
How it runs.
Google Cloud, in London
Tuppence runs on Google Cloud in the europe-west2 (London) region, on a Postgres database with point-in-time recovery.
Encrypted twice
Everything is encrypted in transit and at rest. Our application encrypts the secrets we hold for you a second time, with keys in Secret Manager.
Safe to retry
Every write takes an idempotency key, so a retried request returns the first answer instead of acting twice.
Reconciled every night
Our ledger is reconciled with our card processor’s records every night, and our team is alerted to any difference.
Kill switches
Our team can pause new payments or payouts across the platform within seconds. Refunds are never paused.
Deploys without stored keys
Deploys use short-lived federated credentials for Google Cloud. Our build system holds no long-lived cloud keys.
Independently checked.
We publish each one when it’s complete.
PCI DSS SAQ A
Only our card processor’s secure fields handle card data, which keeps us in the lightest scope of the standard. Our card processor, Stripe, Inc., is a PCI DSS Level 1 service provider.
Penetration test
An independent test of the API, dashboard and pay pages is not done yet. We’ll publish a summary here when it is.
SOC 2
We don’t hold a SOC 2 report yet. We’ll list it here once an audit of our security, availability and confidentiality controls is complete.
UK GDPR
How we handle personal data: see our privacy notice.
Found a vulnerability? Tell us.
Email support@tuppence.ai with “Security report” in the subject. Give us reasonable time to fix it before telling anyone else. Test only with your own test-mode account, and never use real card numbers or other people’s data. We’ll reply, keep you updated and credit you if you wish.