For developers
A key that cannot outrank the person it belongs to.
A key that carries a permission list of its own drifts away from the person it was issued for, and nobody notices until it matters. Ours does not have one. It belongs to exactly one login, acts as that login, and is re-read on every single call, so narrowing somebody narrows their keys before their next request.
- 17Endpoints, and exactly one of them writes. Each is the same function the screen behind it calls, so an answer here and an answer there cannot differ.
- 12Scopes, and a scope can only ever narrow. It is checked when the key is made and checked again on every request it is used for.
- Append‑onlyEvery call is recorded: key, login, path, scope, status, rows, duration and address. The table refuses an UPDATE outright.
The model
The key is the person, not a second set of keys.
This is the whole design, and everything else follows from it.
It acts as one login
Same tier, same permissions, same accounts, same rows. A key cannot reach one record its owner could not open in a browser. There is no separate list to keep in step, because there is no separate list.
It is re-read every call
Nothing is cached at issue. Change what somebody may do, deactivate them, or move which accounts they cover, and every key they hold follows on the very next request, with nothing to revoke and nobody to remember.
Scopes only ever narrow
A scope is a further restriction on top, never a grant. Ask for more than the login holds and you get less, not more. What a request can touch is the login’s permissions and the key’s scopes, whichever is smaller.
What it answers
Your own figures, in the shape the screen uses.
Every endpoint is the same domain function the equivalent screen calls. There is no second implementation to drift, and a document that describes a door which is not there fails the build.
Accounts and transactions
Your accounts, and the transactions under them, filtered and paged the way the reports are. One endpoint annotates a transaction; everything else reads.
Money in and money owed
Batches, deposits and statements: what was taken, what was funded and what the month came to.
Disputes
The cases against your accounts, with their state, so a chargeback shows up in your system rather than in somebody’s inbox.
Point of sale
What the till published, read on a schedule and available to your own software in the same shape the screens use.
Devices at the counter
Configuration, captures and log delivery for the lanes you run, each on its own key, so a lost lane is one revocation rather than a fleet rotation.
Money without rounding
Figures leave as exact integers in a fixed scale. The API does not round on the way out, so what you receive is what the book holds, not a float somebody has already spent precision on.
The key itself
Shown once, stored as a fingerprint, and it always ends.
A stolen copy of our database contains no working key, because we do not keep one. We keep only a one-way digest of it. Nobody here can read yours back to you, and that includes us.
In person
The lanes you already run do not have to be rebuilt.
Replacing a payments platform usually means re-flashing every device in the field. We took the other approach and reproduced the contract your fleet already speaks, header for header and path for path, down to the quirks.
Both credentials are accepted
There is no cutover date. A lane already in the field keeps working on the credential it has, while new lanes take ours, and we count which answered so the old path is retired on a measurement rather than on a promise.
One key per lane
Not one key per fleet. A device that goes missing is a single revocation and nobody else is interrupted. That is only possible because a key costs nothing to issue and always expires.
Card data is not ours to hold
The lane authorises on the reader and sends us the outcome. No card number reaches this platform on any path, and no read we offer returns the token the reader produced.
A log is never refused
Diagnostics upload straight to storage, and an unusable filename is corrected and accepted rather than rejected, because a device deletes its own copy only when we say yes, and a refused log is a log lost for good.
Plainly
What it does not do.
A capability list nobody qualifies is a list you find the holes in later, at your own cost. These are ours, said now.
It never calls you
There are no webhooks and no callbacks. Nothing here reaches out to your systems. You ask, we answer. If your design needs to be told rather than to poll, tell us, because that is a real gap and not a preference.
There is no self-serve key
Issuing your own is a permission somebody grants you, and it is off until they do. That is deliberate in a system where a key carries a person’s whole reach, but it does mean our team reviews your project inquiry before granting access.
No credential ever comes back
No endpoint returns a key, a secret or a processor credential of any kind, and none returns what your office buys at or what anybody upstream earns. Those are not fields we forgot; they are fields that are refused.
Tell us what you are building.
Access is granted rather than claimed, so the first step is a conversation about which accounts you need and what you need to do with them. The interface description comes with the key.
