Skip to content
NOSTREL
Talk to usSign in
Changelog

Every entry says
whether you have to act.

Usually the answer is no, and making that the loudest part of each entry is the entire design. A changelog you have to read carefully to find out whether it concerns you is a changelog that will not be read.

Only things that change what you can rely on appear here. Refactors, internal work and the hundred small improvements do not, because listing them would bury the three entries a year that genuinely matter.

  1. Changed

    Every error now carries a stable machine code

    Errors used to come back as a status, a short label and a sentence, which meant anybody branching on more than the status was pattern-matching English that we were free to reword. Now there is one envelope on every route, with a code drawn from a published catalogue of 24, a coarse type for a client that wants one branch per family, a request_id to quote at us, and a fields array on validation failures. It is enforced by a single filter rather than a convention at the throw sites, so it holds for the failures nobody thought to test.

    Do you need to actYes, if you read the body. The old top-level message and statusCode are gone; read error.message and error.code instead. If you only branched on the HTTP status, nothing has moved: every status means exactly what it meant before.

  2. Added

    This website

    Public documentation, the security findings, the compliance position and the pricing shape, all of it readable without an account or a sales call. Previously there was nothing to send anyone.

    Do you need to actNothing. Read the quickstart if you have not.

  3. Fixed

    The consoles are usable without a mouse, and readable at AA

    An accessibility pass over both consoles and the hosted checkout. It found 596 table rows that only a mouse could open, a dialog that trapped focus and then dropped it on close, five controls with no accessible name, and a set of colour tokens that failed contrast in thousands of combinations. All fixed, and now checked automatically across every route, theme and width.

    Do you need to actNothing. If you had worked around any of it, you can stop.

  4. Security

    A success callback no longer credits anything on its own

    Previously a provider callback saying a payment succeeded was enough to post it to the ledger. Now it parks the payment and we confirm with the provider directly before any balance moves. Written up in full on the security page, including why the fix is the confirmation rather than the authentication.

    Do you need to actPossibly. Collections now pass through awaiting_confirmation on the way to success. If your code treats any non-terminal state as a failure, it needs to not do that.

  5. Security

    Logging rebuilt around an allowlist

    Refresh tokens were being written to the application log because the redaction list covered the request cookie header and not the response one. A denylist is the wrong shape for that problem, so logging now allows a fixed set of fields and drops everything else.

    Do you need to actNothing.

  6. Changed

    Payment links can be prepared before approval

    Collection is gated on verification, correctly. Everything else was gated too, which meant a merchant could not lay out products or draft an invoice while they waited. Now you can build everything and only the collecting waits.

    Do you need to actNothing. There is simply more you can do on day one.

  7. Added

    Withdrawals to your own bank or shortcode

    Taking your own money out rides the same rails, ledger, approval and PIN as any other payout, rather than being a separate path with separate bugs. Bank destinations are reached through each bank's own published shortcode, read off the bank's own website rather than an aggregator list.

    Do you need to actNothing, unless you want it, in which case add a destination and verify it.

  8. Added

    Bulk payouts from a CSV

    Four columns, validated before anything moves, reserved against your balance as a run, approved once and posted as individual ledger movements. One failure in nine hundred is one failure rather than a batch to unpick.

    Do you need to actNothing.

  9. Added

    A tamper-evident audit log, with a verifier

    Append-only at the database level and hash-chained on top, with a job that walks the chain hourly and an alarm that pages when it does not verify. Appends take a transaction-scoped lock, because without one two concurrent writers fork the chain and the verifier reports an honest system as tampered with.

    Do you need to actNothing.

We will not break you quietly

Anything that changes what you can rely on gets an entry here and, once there are people to tell, an email to the address on your account. Finding out from a changelog you happened to check is not a notification.

The APISecurity findings