What Changed

Fixed

• A card payment can no longer go missing because a notification did. Every gateway learns that a payment succeeded from a single message sent by the provider. Miss it — a deploy landing at the wrong moment, a network blip — and the buyer has been charged while the order sits open, with nothing on your dashboard to say so.

Blockra now asks Stripe directly. Every ten minutes it takes any checkout that started a card payment and never finished, reads the real state from Stripe, and completes the order if the money is there. Receipts, digital delivery and discount counts all follow exactly as they would have.

It is deliberately the same mechanism the bank rail already had, doing the same job against a different provider — a missed message is now a delay of minutes rather than an order nobody ever ships. It also refuses to credit a payment whose provider record points at a different order, so a recovered payment can only ever land on the checkout it belongs to.

Changed

• Two webhook events you could subscribe to have been removed, because neither was ever sent: payment.refunded and payout.completed. Selecting them did nothing but produce silence you might have been waiting on.

payment.refunded implied Blockra can refund your buyers. It cannot, and never could — refunds are issued by you, from your own Stripe or GoCardless dashboard, because the money is in your account rather than ours. payout.completed dated from when Blockra held funds and paid them out; nothing has worked that way since it became non-custodial. Crypto goes to your own wallet and card and bank money to your own provider account, so there is no payout for us to tell you about.

If either was ticked on an endpoint, nothing changes — you were receiving nothing from them before.

• `payment.failed` is documented. It was already being sent when a bank collection is refused; it just was not written down anywhere.

Added

• The bank rail is in the documentation. The API reference now covers all three ways a buyer can pay, and is explicit about the one thing that differs: a bank payment is authorised first and clears afterwards — usually minutes on Instant Bank Pay, about three business days on BECS.

There is a warning on both the introduction and the webhooks page saying what it is genuinely important to know: `payment.confirming` is not a signal to ship. It means the money is on its way and can still fail. payment.completed is the event that says it arrived, and it is the only one worth fulfilling an order on. Blockra holds its own digital delivery to exactly that rule.

Added

• Take payments straight from a buyer's bank account. Connect your own GoCardless account from Settings → Payment methods and a Bank option appears at your checkout beside cards and crypto. The buyer picks their bank, approves the payment on their bank's own page, and the money is paid into your bank account, not ours — Blockra never touches it, exactly as with crypto.

Connecting takes you to GoCardless to authorise it, the same way connecting Stripe does. No keys are copied and no account details are typed into Blockra. Disconnect at any time; existing payments carry on to their conclusion.

The buyer picks their bank on your checkout, not on somebody else's page. A searchable list with logos sits inline beside the coins and the card fields, and the email they already typed is carried across. By the time they leave, the only thing left to do is approve the payment at their own bank — no form to fill in twice, and no page that looks nothing like your shop.

That last hop cannot be removed by anyone, and we do not pretend otherwise: banks refuse to be embedded, and the consent is the buyer's to give at their own bank. What we removed is the detour in front of it.

Australian buyers give a BSB and an account number instead, because their scheme is a debit rather than a push payment and has no bank list to pick from. Same panel, different control — chosen by the rail, not guessed.

This rail is not instant, and the checkout says so rather than pretending. A bank payment is a request to a bank, not a card authorisation, so:

• The buyer returns to a page that says the payment is on its way and that you will email them when it arrives — not a success screen. Nothing is delivered yet.
• Digital products, licence keys and download links are released when the money confirms, not when the buyer gets back. Releasing on the buyer's return would be giving goods away on a payment that can still be refused.
• The order sits in Transactions as Confirming with the date the money is expected — the same word crypto uses while it waits for depth, because it means the same thing on both rails: the money is on its way and is not yours yet. That is deliberately not Pending, which is what an invoice nobody has touched looks like.
• If the bank refuses it, the order does not silently disappear — it is marked failed, and a payment that has already settled is never un-settled by a late message.

Three currencies collect today — £ (Bacs), € (SEPA) and A$ (BECS) — and the option only appears when the buyer can actually be charged in one of them. The other five GoCardless currencies are not offered for one-off payments by the schemes themselves, so showing them would be a button that fails at the bank.

• The buyer is charged in their own currency, not yours. A UK buyer at a shop priced in euros is offered the payment in pounds, converted at the same rate the rest of Blockra uses. Without this a Bacs-only buyer simply could not pay a euro-priced shop at all. If their currency has no rail, the shop's own currency is offered instead, and if neither works the option is not shown.

• Five more currencies to price in: A$, C$, NZ$, kr (SEK) and kr (DKK). The list was dollars, euros and pounds; it is now the eight we can quote a rate for and settle through a bank — the two tests that matter, because a currency that fails either produces a shop that can name a price nobody can pay.

Everything downstream follows: your dashboard totals, analytics, tables, exports, payment links, products and invoices all read in whichever of the eight you pick. Locale pricing covers the new five too, so a Canadian buyer at a pound-priced shop sees Canadian dollars.

• Every amount now says which dollar it is. US, Australian, Canadian and New Zealand dollars had all been rendering as a bare $, so a figure in your transactions table, your analytics or at your checkout could have been any of four currencies. They now read US$, A$, C$ and NZ$, and the two kronor — which genuinely share kr — read SEK and DKK. Your own number formatting is untouched: only the symbol changed, not the grouping or the decimal mark.

Changed

• Your Blockra plan is now a subscription, collected by Direct Debit. Plans used to be blocks of prepaid time — pay, get a month, pay again. They are now an ordinary subscription with a standing bank instruction, which changes several things for the better and one thing you should know about.

How you pay. Authorise once through your bank's own page — we never ask for a sort code and no full account number is stored or shown. Each collection is taken automatically and you are emailed the exact amount and date before it leaves your account.

In the currency you bank in. Eight rails, each collecting in its own currency and paying out domestically: Bacs (£), SEPA (€), ACH ($), BECS (A$), BECS NZ (NZ$), PAD (C$), Autogiro (kr) and Betalingsservice (kr). Prices are fixed per currency, not converted — a UK merchant pays £29 and a Swedish one 379 kr, and neither figure moves because a rate did. Your rail follows the country you bank in, and locks once a bank account is authorised, because a mandate belongs to one scheme for life.

Where we cannot collect at all, the upgrade button says so plainly instead of taking you into a flow that cannot finish.

Changing plan now charges the difference. Upgrade mid-month and you pay for the days left at the new rate, less what you already paid for them — the figure is shown before you confirm and is the same figure taken. Your renewal date does not move.

And downgrades no longer mean cancelling. Previously the only way to a cheaper plan was to cancel and re-buy when the period ran out. Now you pick it and it is scheduled: nothing is charged today, you keep everything you paid for until the period ends, and the cheaper price starts at the next collection. Picking your current plan again calls the change off.

Monthly → annual buys a whole new year less the unused days and moves your renewal a year out. Annual → monthly is scheduled like any other downgrade, because you have already paid for months of runway.

• Cancelling keeps what you have paid for. Nothing is taken again, your bank instruction stays in place so restarting is one click rather than a fresh authorisation, and every paid feature runs to the end of the period — the dialog names the date, and that is the date. If a collection had bounced and a retry was queued, cancelling calls that off too.

• Payment methods. Add a bank account, make it the default, remove one. Making a different account the default moves your subscription onto it without charging you early, and the default cannot be removed while a subscription is live — add another first. There is no edit: bank details cannot be altered on a mandate by anyone, so the screen does not offer a button that would always fail.

• Billing information. The name and address that appear on your Direct Debit instruction and your invoices, editable from Billing. Merchants in New Zealand, Sweden and Denmark are asked for the one national identifier their scheme requires, and only them — set once, then shown read-only, because the scheme will not accept a change.

• Invoices. Every collection that clears produces one, numbered in sequence, with the amount taken, the period it paid for, and the name and address it was billed to as they were on the day. Open one to print it or save it as a PDF. No VAT is charged and the invoice says so in words rather than printing a zero — to an accountant those mean different things.

• When a collection fails, the dashboard tells you. A Direct Debit fails silently from your side: no decline at a checkout, no error on a screen, just money that did not move. You now get a banner saying what bounced, what your bank said about it, when the retry lands, and what happens if that fails too. Dismissing it remembers which failure, so a new one still reaches you.

There is one retry, then we stop — no indefinite chasing. Stopping does not take back time you have already paid for: a failed collection is money that never arrived for the period ahead, so if you are paid through the 1st you keep everything until the 1st, and adding a working account before then puts it all back. A chargeback is the opposite case and does end the period it paid for, because that money has been returned to you.

• Eight emails covering the whole subscription — confirmation, an advance notice before each collection naming the exact amount and date, a receipt when it clears, a failure notice, a downgrade notice, and confirmations for cancelling, downgrading and upgrading. The upgrade one shows both what you paid today and what you will pay next time, because a one-off credit makes those two numbers different and nobody should have to work out why.

• Plan prices are shown in your own currency on the pricing page, from the same table billing charges from — including Free, which used to sit as a hardcoded $0 beside a £29.

Fixed

• Bitcoin confirmations no longer depend on one provider. Reading the chain means asking a block explorer, and we were asking exactly one — so when it became unreachable from our servers one morning, every Bitcoin payment stopped confirming behind it. There are now two, tried in turn, and the health check only raises an alarm when both are gone. No payment was ever at risk of being lost: a payment we cannot read is left alone rather than assumed empty, and coins that arrive during an outage settle normally afterwards even if the window closed meanwhile.

• Settings could not be opened on a phone. Opening settings from the menu, or going straight to a settings link, left you on the dashboard with nothing showing. It works from either route now.

• The discount form ran off the edge of the screen on a phone. The amount field refused to shrink below its natural width, which pushed the whole form wider than the window it was sitting in — so the right-hand margin disappeared and the fields ran under the edge. Every form of that shape has been given room to shrink, and the dialog itself can no longer be pushed out of shape by what is inside it.

Changed

• Settings on a phone is now a list you step into, not a menu you summon. It opens on the sections themselves, each one a page you tap into with a back arrow and a save tick in the header. The old arrangement borrowed the desktop sidebar and hid it behind a button, which meant two panels stacked on top of each other every time you wanted to change section. Unsaved work is still held onto if you step back out, and settings can't be closed out from under it.

Added

• Protect › Blocklist — decide who can pay you. Eight things you can turn away, all of them checked before a payment is ever started: no address is minted, no card is authorised, so there is nothing to refund.

• Email address — one exact address.
• Email domain — everyone at a throwaway mail provider, or at one company.
• Customer — someone already in your customer list.
• IP address — a single address.
• IP range — a whole block in CIDR form, like 203.0.113.0/24.
• Network — an entire hosting provider or ISP by ASN. The most effective entry on the list: nearly all VPN and proxy abuse arrives from a handful of networks.
• User agent — matched as part of the string, so curl/ catches every version of curl.
• Country — resolved from the connection, not from anything the buyer types.

Add one at a time, paste a list, or import a CSV, text or JSON file — the file is read in your browser and every line checked before anything is saved, so you see exactly what was taken, what was already there, and what could not be read. Entries can be paused rather than deleted, and each keeps a count of what it has stopped so you can tell which rules are earning their place.

A blocklist holds up to 10,000 entries, with 200 of those being IP ranges or user agents — the two that have to be checked one by one on every payment. Both limits are the same on every plan: how many people you can refuse to sell to is not something we think you should pay for.

The buyer is never told which rule caught them — only that the transaction could not be processed and to contact you. Naming the rule tells the person it caught exactly what to change. On your side the attempt appears in Transactions as Blocked, with the value that matched.

• Every payment attempt now records where it came from. IP address, network and ISP, city and country, and whether the connection looks like a proxy or a hosting provider. It is kept on the transaction so the risk and fraud tools coming next have a history to work from — those cannot be retrofitted onto data nobody collected, and the first useful day is the day collection starts. Coordinates are deliberately not stored: a city centroid feels like a location and answers nothing the city and country do not.

• Products that have run out say so. A serials product under five keys still shows an amber Low; one at zero now shows a red Empty. It appears on the products table and beside the keys inside the product itself, so you can spot it while scanning your catalogue or while looking at the box you would paste into. Empty replaces Low rather than sitting next to it — zero is not a smaller amount of low, it is a product that has stopped selling.

Added

• Choose a variant at the checkout. A product with tiers, sizes or editions now shows them under the item, with each one's price and how many are left. Picking one re-prices the order there and then. Options that have sold out stay visible and greyed rather than vanishing — a buyer who came for that tier deserves an answer, not a missing row.

• Edit a discount. Everything about it: the code, the amount, the type, the cap, the expiry. Same dialog you created it in, reached from Edit on its row. Changes apply to new checkouts immediately; redemptions already taken keep the terms they were given, because a receipt is a record of what happened rather than a live reading of your current settings.

Changed

• Discounts is out of Beta. It creates, edits, redeems and reports, so the badge came off the page and off the sidebar. Products keeps its own — that one is still settling.

Fixed

• Stock is now held while you pay. Two buyers could previously each open a checkout for the last licence key and both pay for it; one got the key and the other got an apology. The moment a payment starts — a deposit address, or a card — the keys are reserved for that buyer and nobody else can start a payment against them. Walk away and they go back on the shelf.

• A sold-out variant refuses at the door rather than after somebody has paid, and the quantity picker no longer offers more than there is.

Notes

Holding starts when the payment does, not when the checkout opens. Reserving stock the moment somebody follows a link would let anyone lock up a small merchant's inventory by refreshing the page.

Added

• Products. A new section in Commerce for the things you sell. Give it a name, a description and some pictures, then say what it costs and how it reaches the buyer.

• Every product gets a checkout. One link, checkout.blockra.io/product/…, that takes crypto or a card like any other Blockra checkout — with the product's picture, its price and a quantity the buyer can change within the limits you set.

• The buyer is sent what they bought. When the payment settles, an email goes out carrying the goods: the keys, the download link, or the service instructions, with your note underneath. It is separate from the receipt on purpose — one is proof of payment, the other is the thing they paid for. Payment links are unaffected and behave exactly as before.

• One price, or several variants. A product can be a single thing at a single price, or a set of tiers, sizes or editions that each carry their own price, currency, order limits and delivery.

• Three ways to deliver.
• Serials or keys — paste a list, one per line. Each key goes to exactly one buyer and never to a second, even if two people check out at the same moment, and the count of what is left is real rather than a number you maintain.
• A service message — the instructions, link or credentials the buyer receives.
• A file — uploaded to private storage and handed over with a link that expires after seven days. It is never publicly addressable, so nobody who has not paid can reach it.

• Edit a product after you have made it. Same flow as creating one, ending in Save instead of Create. Your keys come with it: the unsold ones are there to add to or take out, and the ones already sent to buyers are kept out of reach — no edit can recall a key somebody has paid for.

• Know when you are running out. A Low badge appears beside your keys once there are fewer than five left, and a sold-out product stops offering a checkout rather than taking money for something you cannot deliver.

• Show buyers how many are left, per variant, if you want the nudge. Off by default, and only where it means something — a service or a file never runs out, so those take a purchase limit instead: sell twenty, then stop.

• Duplicate anything you already sell. Its details, pricing and delivery come across, and its images and files are copied rather than shared — so deleting one product can never take the other's pictures with it. Serial keys are deliberately not copied: they are finite stock, and the same key in two products is the same key sold twice.

• A note to the customer on each variant, sent with the delivery — support hours, redemption instructions, anything they should read after paying.

Storage

Product images and delivery files share one allowance, because you should not have to think about which kind of file you are running out of room for.

A single image can be up to 10 MB and a single delivery file up to 100 MB. Deleting a product frees its space immediately — the images and files go with it.

Notes

A product with several variants sells the first one for now. Choosing between them at the checkout is a screen we are still designing, so rather than guess at it we have left it out.

Listing products on a storefront of your own comes with the site builder, so there is no public/unlisted/private choice to make yet, and a product's address is its ID rather than a name you pick.

Marked Beta while it settles.

Added

• Commerce is a section now. The sidebar has a new expandable group below Payments. Payments is about money arriving; Commerce is about the things you sell and the terms you sell them on, and those two do not belong in one list.

• Discounts. The first thing living in Commerce. Create a code that takes either a percentage or a fixed amount off the total — cap how many times it can be used, limit it to one use per customer, and give it an expiry date if you want it to stop on its own. The list filters and sorts like Transactions does, and each code reads as active, deactivated or expired.

Still marked Beta: a code can be switched off but not yet edited or deleted, and the code a customer used does not appear on their receipt. Both are next.

• Customers can enter a code at checkout. A discount line sits under the subtotal: type the code, and the total updates with the old figure struck through beside it. A fixed discount set in your currency converts if the checkout is denominated in another, so £10 off is £10 off whatever the buyer pays in. Usage only counts when a payment actually completes — an abandoned checkout never eats into a code's limit. "Limit to one use per customer" is checked against the email at the payment step, so a second attempt from the same address is turned away there.

• Allow discounts, in Settings → Checkout. On by default. Turn it off and the code field stays off your checkout entirely, whatever codes exist.

Changed

• Dialogs no longer black out the page behind them. Opening one used to drop an almost-opaque black sheet over everything, which read as the whole window being taken over rather than as something opening on top of it. Every dialog now fades the page back and blurs it very slightly instead, so you keep your bearings — the same treatment the quick-search palette already used.

• Dialog buttons sit in their own tray. Dialogs are built in two layers now: what you read and fill in sits on one surface, and the buttons sit on a slightly different one beneath it, so it is obvious at a glance where the form ends and the actions begin. Creating a payment link, a webhook, an API key or a discount, turning two-factor on, connecting a domain — they all share one shell, so they behave the same way and stay that way.

• Empty lists explain themselves. A page with nothing in it used to show an empty table: column headers you could sort, over no rows. Transactions, customers, payment links, API keys, webhooks and discounts now say what the thing is and, where there is something to create, offer the button to create it. Filters are hidden too — there is nothing yet to filter. Filter a list down to no results and you still get the table and the filter bar, so you can undo it.

Fixed

• Payments could not finish settling. A leftover piece of the identity-verification system that was removed when Blockra went non-custodial was still attached to the payments table, pointing at a column that no longer existed. Anything that changed a payment's state failed on it: a payment could be created and its confirmations counted, but it could never reach completed, and expired checkouts never expired. Confirmations still ticking is why it went unnoticed — the parts you can see kept moving.

The leftover is gone and every state change was re-tested. Any payment left sitting unfinished resolves on its own now.

Changed

• The sidebar reads properly now. Every navigation label was inheriting a muted grey, so the whole rail looked like supporting text rather than the main way around the product. Labels sit at full contrast; icons stay quiet; hovering a row moves only its background, so nothing shifts colour under the pointer. The arrow on an expandable section is the one exception — it brightens on hover, because nothing else about the row tells you it opens.

• Sections stay open. Opening one collapsible group no longer closes the one you were already in, so moving between Transactions and API Keys does not mean re-opening a group each time.

Added

• Command menu. Press Ctrl K — or ⌘ K on a Mac — anywhere in the dashboard to jump to a page or a settings pane without reaching for the sidebar. There is a search box pinned above the navigation that opens the same thing. Arrow keys move, Enter selects, Escape closes.
• Search your payments from it. Type pay: followed by anything you have — a payment ID, the customer's email, your own reference, the last four digits of a card, or a deposit address — and matching payments appear as you type, with no need to press Enter.
• Search your customers from it. cus: finds a customer by name, email address or ID, with the ones who have spent the most first.
• Type anything else to find a page. Every page and settings pane is searchable by name, shown with its full path — searching "billing" gets you Settings › Billing, so you can tell at a glance where you are about to land.

Changed

• The light/dark switch moved out of the top bar and into the sidebar, on the same line as the Blockra logo. It is a setting that applies everywhere, so it no longer sits on the one bar whose contents change with the page.

Fixed

• Opening Settings no longer shifts the page behind it. The dialog was quietly restyling whatever was underneath, which pulled the content upward and away from the right edge.

Added

• Two-factor recovery. If you lose your authenticator app and your backup codes, support can now clear two-factor on your account after confirming who you are, and you sign in with your password again. Previously there was no way back in.
• Deletion on request. If you'd rather email us than use the delete button in Settings, we can now action it directly. It does exactly what the button does: your account, API keys, webhooks and customer records are removed, and settled payments keep only their amount and date with every identifier stripped.

Changed

• Tron is switchable per account. TRX and the Tron network were already live at checkout, but couldn't be enabled on an account by support — only by you, in Settings. Both routes work now.
• Home page — a new hero, and the accepted cards and coins are listed on it.

Fixed

• This page sorted two releases published on the same day by filename rather than by version, and long bullet points were split in half. Both are corrected.

Notes

• Suspending an account has never stopped a payment a customer has already broadcast. Those coins are on-chain and settle to your wallet regardless — nothing Blockra does can recall them.

Added

• Hosted checkout — a payment page for cards and six coins with nothing to deploy.
• Embedded checkout — one script tag, inline or as a drawer, styled to your site.
• Payment links — name a thing, price it, share the URL. No website required.
• Card payments through your own Stripe account, including Apple Pay, Google Pay, Link and buy-now-pay-later.
• Six assets across four chains — BTC, LTC, ETH, TRX, and USDC and USDT on either Ethereum or Tron.
• Blockra Wallet — an optional in-browser wallet for holding and sending what the checkout takes. The recovery phrase is generated and encrypted on your device and never reaches us.
• REST API, signed webhooks and analytics.

• Contact form — messages reach a person, with a copy emailed back to you.
• Changelog — this page. Every release from here on.
• Policies — terms, acceptable use, privacy, cookies, a data processing agreement, security and refunds, all written from what the software actually does.

Notes

• Blockra is non-custodial. Card payouts go to your Stripe account and coins settle at addresses derived from your own extended public key.
• There is no percentage fee on payment volume. Plans are the whole of what you pay.
• Account deletion erases your account and anonymises the payment history behind it, keeping only the amounts and dates as a financial record.