SellstampChangelog
What shipped, and when.
Written by a person.
One entry per change a merchant or an integration can actually see. Not generated from commits — a commit log is a record of work, and this is a record of what you can now do. Nothing here is unreleased.
September 2026
- Checkout
Five more bank-app rails: Pix, UPI, PromptPay, PayNow and PayID
Each is a code the customer's own banking app reads, built from your own account identifier — no processor, no contract and no KYC beyond owning the account. Your identifier is validated when you connect it, because a typo pays a stranger. PromptPay is the exception worth knowing: a personal transfer there carries no reference field a bank relays, so the order page prints the reference and asks the customer to put it in the memo.
- Checkout
EPC QR, for any SEPA IBAN
The European Payments Council's GiroCode, across all 36 SEPA countries — the same arrangement IPS QR already gave Serbia, generalised. You confirm the transfer arrived; there is no webhook, because there is no processor in the middle.
- Checkout
A second currency, as a price you type
Set an explicit price per currency, per product and per option. Nothing is converted and no rate is involved anywhere, so there is no rate to freeze and no rounding that disagrees with the customer's bank. Payment methods that cannot settle the chosen currency drop out of the picker rather than failing at the end, and revenue reports group by currency instead of summing across them.
- Accounts
Sign in with a passkey, and no password at all
Phase two of passkeys: a passkey is now a whole sign-in rather than only a second factor. The password path is unchanged for anyone who wants it.
- Notifications
Web Push, a fifth notification channel
Alongside in-app, email, Discord and webhooks. A subscription belongs to a browser rather than to a workspace, so granting it on your laptop does not silently opt in your phone.
- Subscriptions
One discount to stay, offered once
A customer who starts cancelling can be offered a percentage off for a number of months. It is minted as your provider's own coupon with a single redemption and attached to the live subscription, so nothing local can drift from what was billed — and a coupon you added yourself in your provider's dashboard is kept rather than replaced.
- SDKs
@sellstamp/license-verify on npm
The licence verifier as a real package instead of a recipe everyone copied by hand: signature checking, offline activation files, and clock-rollback detection for the offline window. It re-exports the platform's own verifier, so there is no second canonicaliser to drift. MIT, Node 22+, no runtime dependencies.
- Accounts
Email verification enforced at login
Not only at billing. The email-change flow was built on top of the same gate, so changing an address proves both ends of it.
- API
Resource-scoped API keys, and a usage dashboard
A key can now be restricted to named stores and named products, given an expiry, carry its own rate limit below the plan's, and be rotated into a new secret with the same authority while the old one runs out on a deadline. Settings → API keys charts thirty days of requests per key, with the routes each one actually calls.
- Fraud shield
A rule of your own that holds the goods, not the payment
Hold fulfilment over an amount you set, optionally only for devices your store has not taken a payment from. The order still charges and settles; what waits is the download grant, the licence key or the parcel — so a false positive costs you a refund fee rather than costing a real customer their purchase. And fraud-signal collection now has a per-store off switch, with its cost stated: turning it off turns off the card-testing refusal too.
- Licences
A licence that grows without issuing a second key
Sell a customer more seats or a higher tier and it lands on the licence they already have, with a row saying what changed. An upgrade is an ordinary order priced from your catalogue; a subscription-backed licence delegates the proration to the provider. A downgrade returns nothing — it changes what the licence allows from here on.
- Storefront
A real shopping cart, and folder-upload theme import
Several listings, one payment. Separately: point the theme importer at a folder of HTML and it becomes pages in your store — each an editable section wrapped by your own header and footer, replacing by slug rather than making about-2 — and it reports what it stripped instead of quietly removing your scripts.
- Payment links
Quotes, proformas and net terms
The paperwork a company needs before it is allowed to pay you: a quote with its own numbering series and a real expiry date, a proforma with its own, and net terms as an approval you grant one buyer's email address. A quote's frozen snapshot is the contract, so a price rise between sending and accepting does not reach the buyer.
- Licences
Floating seats, binding modes, offline activation and transfers
A licence can bind to a machine, a domain, a person, or a seat in a pool held by a short lease. An air-gapped machine activates by exchanging two small text files, and the response is the same signed validation response your SDK already verifies. Licences can be transferred, with your own policy — none, approval-required or free — frozen onto the licence at issue.
- Webhooks
Endpoint health, and a secret you can actually roll
An endpoint that fails for an hour gets you an email; one that fails for a day is switched off, and the dashboard says we switched it off and when. Recovery clears the incident, so a second outage next month gets a second alert. Rolling a secret keeps the old one verifying for 24 hours, with both digests in the signature header, so you deploy without an outage.
August 2026
- Fraud shield
The one rule allowed to block
Card-testing bursts are refused automatically — fifteen checkouts from one browser or fifty from one network at one store in ten minutes — because a run like that is finished before anyone could read a flag. It cools down the attacker, never the shop, and it remains the only automatic refusal in the product.
- Platform
The public status page
Nothing on it is automatic. A component is degraded when a member of staff has said so and recovers when a member of staff has verified it — because the failures that generate three hundred support emails are exactly the ones a liveness probe reports as healthy.
How this page is kept
By hand, and deliberately. The two automatic options both publish the wrong thing: a commit feed is a record of work rather than of what you can do, and it would put internal phase codes and refactors on a public page. Neither can write the sentence that matters most about a change — that your existing integration needs no change.
An entry is never rewritten once it is posted. A correction is a new entry, for the same reason an invoice is corrected by a credit note rather than edited.
Also worth watching
Breaking changes to the public API would appear here first and would carry a version prefix. There have been none: /api/v1 has only ever gained endpoints, scopes and headers. Incidents are a different page — status is where an outage is written down.
What is not on this page
What this does not do
- Anything unreleased. A changelog with a future in it is a roadmap wearing the wrong label.
- An RSS or JSON feed. There is no endpoint behind one, and a link to a feed that 404s is worse than no link.
- Every change. Refactors, tests, internal tooling and typo fixes are real work and none of them is something you can see.
- Version numbers. The product is continuously deployed and there is no release a number would name.
Open a store and try it.
Everything on this page is in the product today. Connect a provider in test mode and put a real order through it before you decide.