Security

How this is built

Each claim below is a property of the code rather than an intention, and each one has a test that fails if it stops being true.

• A payment-processor key is read-only and restricted, and we measure its scopes before we accept it rather than taking your word for it. Customers and payment methods stay unreadable, so the key physically cannot reach card data or your customers’ details.
• Third-party credentials are encrypted before they are stored, under a key held outside the database. A database dump on its own is inert.
• There are no passwords anywhere — not hashed, not anywhere. Sign-in links and session cookies are stored as digests, never as the value we sent you, and a sign-in link works once.
• Every inbound payment webhook is signature-checked, and a failed check is a rejection rather than a log line. Anybody can post a plausible payment event; forged volume would hide exactly the outage this product exists to report.
• Payment events are reduced to amount, currency, type, timestamp and event id at the door, before anything durable is written. Cardholder data and payer identity never enter the system, so they cannot leak from it.
• An alert delivery receipt records that we sent and never what we sent. There is no column for the message, the subject or the recipient.
• Where an alert goes is encrypted at rest and is refused to every read path except the one that is about to deliver a message. A destination is inert until it is confirmed.
• An API key is stored as a digest and shown to you exactly once. A revoked key says it was revoked, so the script that broke tells you why.
• An address you give us to POST to is checked against what it actually resolves to, every time we send, rather than against the name you typed. A public name pointing at a loopback, link-local or private address is refused, a redirect to one is refused, and what you get back is a sentence saying so rather than a connection error.
• Logs are scrubbed on the way out, and nothing hands a logger an object it might serialize for us. The database is the well-reviewed door; a log file is the open window.

Reporting something

Write to us. Tell us what you found, how to reproduce it, and how you would like to be credited. We will confirm we received it, tell you what we think it is, and tell you when it is fixed.

Please do not run tests that degrade the service for other customers, and please do not read or change data that is not yours. Beyond that, we are not going to threaten anybody who reports a real problem in good faith.

What we cannot promise

There is no bug bounty. This is a small product with one person behind it, and an unfunded bounty programme is a promise that gets broken.