Key takeaways
- Swiss Bitcoin Pay, the Neuchâtel-based Bitcoin payment processor, shut down its entire server infrastructure on September 14, 2026 after concluding that a malicious user had likely gained access to its internal systems.
- The company believes customer email addresses, Bitcoin addresses, bank IBANs, transaction histories and hashed passwords may have been accessed. It says user funds are safe and that any amounts owed will be returned in full.
- A follow-up exchange on X revealed that the platform batches incoming Lightning payments into single on-chain UTXOs on daily, weekly or monthly cycles, so it temporarily holds user funds while marketing itself as non-custodial.
- The incident sits inside a dense cluster of 2026 compromises (the actively exploited BTCPay Server macaroon flaw, the Liquid federation drain, Pocket Bitcoin, SafePal, Trezor and Revolut) in which the most common prize was customer data.
- No evidence has emerged that merchant private keys were compromised or that Bitcoin left self-custody wallets. The exposed metadata still creates permanent identity-to-blockchain linkages that no password reset can undo.
What happened on September 14
Swiss Bitcoin Pay, founded in late 2022 and claiming adoption by more than 1,000 merchants across 21 countries, disclosed the incident through its official X account rather than a formal security advisory. The statement was blunt about the uncertainty: “A malicious user has likely gained access to Swiss Bitcoin Pay’s internal systems. As a precaution, we are temporarily shutting down our servers while we investigate and secure our infrastructure.” The company listed the data classes it believes may have been touched, namely customer email addresses, Bitcoin addresses and IBANs, transaction history, and hashed passwords. It conceded that it did not yet know whether anything else was accessed, promised that “user funds are safe, and any amounts owed to users will be fully returned,” and gave no reopening date.
Pulling the plug on a production estate mid-investigation is a defensible containment move. It is also the same instruction BTCPay Server gave its operators a month earlier when its own critical vulnerability was being actively exploited (“update immediately or take the server offline”), which says something about how narrow the safe response window has become for Bitcoin payment infrastructure. The part that separates this disclosure from a routine breach notice came afterwards, when a customer asked the obvious question, “User funds? You sell yourselves as non-custodial!”, and the company’s answer redrew its own custody boundary.
“We automatically batch all incoming lightning transactions to 1 onchain UTXO daily/weekly/monthly, which explains why we temporarily hold some user funds on our platform. Generally, these are not significant amounts.”
Swiss Bitcoin Pay, follow-up post on X
That reply describes a custodial float, and it carries more engineering weight than anything else in the disclosure.
What was exposed, and why each data class matters
The specific combination of fields here is unusually toxic, because each element amplifies the others. Together they amount to a financial biography of every affected merchant and customer.
The identity-to-blockchain linkage
Bitcoin’s ledger is public and permanent, but pseudonymous: an address alone tells you nothing about its owner. A database row that binds an email address, a bank IBAN and a transaction history to specific Bitcoin addresses removes that pseudonymity in one stroke. Security researcher Pasquale Pillitteri, assessing the exposure, called the combination textbook material for a tailored phishing attack. The linkage also cannot be rotated the way a password can. A merchant can change credentials and generate fresh addresses tomorrow, and every historical transaction to the old addresses will still be publicly traceable to that business forever. That has consequences for physical security (wrench-style attacks on known holders), for commercial privacy (competitors and suppliers reading revenue flows on-chain) and for personal safety.
What an exposed IBAN actually enables
An IBAN on its own does not let an attacker empty a bank account, because there is no reverse wire primitive in SEPA or Swiss banking. The realistic abuse paths are fraud. Unauthorized direct-debit mandates can be initiated in several SEPA countries with little more than an account number and a name, and are often caught only by refund windows. Payment-redirection invoice fraud works against the merchant’s own counterparties. Bank support lines are easy to pretext when the caller already knows your bank, your account pattern and your transaction rhythm. For a merchant base that includes restaurants, retailers and small businesses, the IBAN plus transaction history also exposes banking relationships and cash-flow seasonality, which is the sort of intelligence that makes business email compromise campaigns far more convincing.
Hashed passwords are only as good as the hash function
Swiss Bitcoin Pay disclosed password hashes, not plaintext passwords, and that distinction matters conditionally. If the hashes came from a memory-hard, deliberately slow function such as Argon2id, bcrypt or scrypt with per-user salts, most customers’ passwords survive offline cracking intact. If they were fast hashes (unsalted SHA-1 or SHA-256, or worse MD5), commodity GPUs can test billions of candidates per second, and any reused or dictionary-based password should be considered compromised. The company has not disclosed the hashing scheme, the salt strategy, or whether session tokens and API keys were exposed alongside the database, and those are the details that determine customer risk. Until they exist, the prudent assumption is that the password is burned. Change it everywhere it was reused, and enable phishing-resistant second factors on the email account that anchors password recovery.
The custody contradiction: batching, float, and the word “non-custodial”
Swiss Bitcoin Pay’s marketing leaves no room for ambiguity. Its public comparison table, still the cleanest summary of its value proposition, scores “Bitcoin with Swiss Bitcoin Pay” with green checkmarks against credit cards and cash on every axis that matters to a Bitcoiner:
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →| Marketed feature | Bitcoin w/ Swiss Bitcoin Pay | Credit card | Cash |
|---|---|---|---|
| Temper-proof | ✓ | ✓ | ✗ |
| Privacy | ✓ | ✗ | ✓ |
| 100% in control of your money | ✓ | ✗ (bank) | ✓ |
| Worldwide money without change fees | ✓ | ✗ | ✗ |
| Passively invest part of your cash | ✓ | ✗ | ✗ |
Set that against the September 14 reality and two rows collapse. “Privacy” now describes a centralized Swiss-hosted database that links identities, bank accounts and on-chain activity, one an intruder allegedly read, and the company advertises that its servers and data sit exclusively in Switzerland. “100% in control of your money” sits awkwardly beside the admission that incoming Lightning payments are held, however briefly, on company-controlled infrastructure before being swept to a consolidated on-chain UTXO.
Why Lightning processors batch in the first place
Batching is how Lightning liquidity management works at merchant scale. A Lightning node receives payments into pre-funded channels, not into on-chain UTXOs. Channel balances are illiquid in one direction, since spending down a channel destroys inbound capacity, and on-chain settlement costs miner fees per transaction. Settling every coffee payment on-chain would drown a merchant in fee overhead and UTXO bloat. So processors schedule sweeps on daily, weekly or monthly cycles, consolidating accumulated channel revenue into single on-chain outputs and optionally handing the aggregate to a fiat off-ramp for IBAN payout. That is exactly the cycle Swiss Bitcoin Pay described.
Every design of this kind creates a custodial float. Between the moment a customer taps an NFC Lightning card and the moment the merchant’s own keys control the settled sats, the value exists as a liability on the processor’s books and as channel balance or hot-wallet UTXOs under the processor’s control. The company’s qualifier, “generally, these are not significant amounts,” is a statement about the size of that float rather than its existence.
The four positions that get called non-custodial
The honest taxonomy has at least four:
- Full self-custody: merchant-run node, merchant keys, as in a self-hosted BTCPay Server.
- Settlement-only self-custody: the processor controls funds in transit, the merchant’s keys control the settled output. This is where Swiss Bitcoin Pay actually sits.
- Custodial in transit with fiat conversion: the processor holds float and pays out CHF.
- Full custody: exchange-style balances.
Collapsing positions two through four into the single phrase “non-custodial” is where the trust damage originates, because the phrase carries legal and regulatory weight in Switzerland that marketing copy does not. Safeguarding other people’s crypto assets is a licensed, FINMA-supervised activity under the country’s DLT-era banking framework, and the boundary between payment processing with transient float and custody is drawn precisely by how long and under whose keys that float sits. Whether or not regulators agree with the company’s structure, users were never told the float existed until a breach Q&A forced the disclosure.
Could this be the BTCPay macaroon bug? The technical context that matters
The obvious question from the operator community is whether September 14 is a delayed aftershock of August 7, 2026, when BTCPay Server disclosed a critical, actively exploited vulnerability that let unauthenticated remote attackers retrieve LND .macaroon credential files, the bearer tokens that grant full control over a Lightning node, and drain channels before the public alert went out. Foundation (the Passport hardware wallet maker) and Citadel21 confirmed their nodes were swept pre-disclosure, and IVPN published a candid postmortem of its own losses after keeping its Lightning checkout dark for days. The remediation guidance was instructive on its own: patching to v2.4.2 stops new theft and does nothing to invalidate already-stolen macaroons, so operators also had to destroy the node’s root signing key and rebuild any BTCPay-generated hot wallet.
Swiss Bitcoin Pay has not linked its incident to any specific vulnerability, and its disclosure describes compromise of “internal systems”, meaning web backends, databases, admin consoles and support tooling, rather than of Lightning node credentials. The two scenarios have different blast radii and should not be conflated: a macaroon-class compromise steals coins directly and leaves on-chain evidence within minutes, while a backend-class compromise steals the metadata layer and leaves balances untouched.
The August episode still matters here, because of the failure modes the two share. Any payment processor that terminates Lightning payments on its own LND or Core Lightning nodes concentrates three crown-jewel assets in one administrative plane: the node’s macaroons, the sweep wallet’s private keys, and the customer database. “Internal systems access” is vague enough to include all three, which is why the assurance that user funds are safe needs supporting evidence.
“User funds are safe”: what that sentence can and cannot promise
The architecture does limit direct theft. Settlement destinations are merchant-controlled wallets that never touch company infrastructure, and no unauthorized Bitcoin movements have been identified. Bitcoin’s transparency also makes the claim partially falsifiable from outside: float wallets that sweep on predictable daily, weekly or monthly cycles produce observable on-chain patterns, and an unexpected consolidation or exit transaction from known sweep addresses would contradict the assurance within hours.
What the sentence cannot cover is the float itself, if node or sweep-wallet credentials turn out to be inside the compromised perimeter. It also cannot cover the operational harm of an indefinite outage on merchants whose point-of-sale apps, dashboards, APIs and e-commerce integrations just went dark, or the downstream fraud losses that phished customers may suffer using data the company held. “Any amounts owed to users will be fully returned” is a solvency commitment, and a welcome one. It is also an implicit confirmation that the company carries user liabilities on its balance sheet, which is the custodial characteristic the marketing table omits.
One breach in a very bad year for crypto infrastructure
Swiss Bitcoin Pay is the latest data point in a 2026 pattern in which the metadata layer and the operational layer of Bitcoin infrastructure failed more often than the protocol did.
Incident (2026) What happened Primary loss BTCPay Server (Aug 7) Actively exploited flaw leaked LND admin macaroons; nodes drained pre-alert; patched in v2.4.2 Merchant Lightning funds Liquid federation (Aug to Sep) Federation wallet drained of close to 4,000 BTC; block production suspended and later resumed Pegged bitcoin Pocket Bitcoin (Aug, disclosed Sep 3) Breach exposed records of 5,411 customers; 291 also lost ID and source-of-funds documents KYC-grade personal data SafePal (2026) Flawed order-tracking plugin exposed 39,798 customers Contact and order data Trezor (Sep) Third-party newsletter platform breach fed targeted phishing campaigns Contact and shipping data Revolut (Sep) Fraudulent requests from a spoofed government agency domain extracted passports, selfies, IBANs and transaction histories Identity and financial data Swiss Bitcoin Pay (Sep 14) Suspected internal-systems access; servers shut down indefinitely Financial metadata, hashed passwords
The pattern is awkward for the self-sovereignty narrative. The coins and the protocol kept working while the companies, plugins, vendors and operational practices around them failed. In a system deliberately built without a risk-absorbing middleman, the processor’s database, its patching discipline and its vendor chain are the safety net, and every row above records a hole in it.
If you are affected: a practical response checklist
Treat every message referencing the outage as hostile until you verify it through an independently typed domain. That covers refunds, account reactivation notices, password resets and support tickets, because attackers holding real transaction records can compose phishing indistinguishable from legitimate support during an outage window. Rotate your Swiss Bitcoin Pay password and every account where it was reused, secure the email address that anchors recovery with a FIDO2 or otherwise phishing-resistant factor, and warn your finance team about payment-redirection requests that cite the breach. IBAN plus invoice history is the exact ingredient set for mandate and invoice fraud.
Merchants should assume their historical on-chain activity is now identity-linked and plan address hygiene accordingly: fresh settlement addresses on relaunch, no reuse, and caution about publishing revenue-bearing addresses on public menus or websites. If you accept Lightning elsewhere in the meantime, apply the August lesson. Verify your stack runs patched versions, revoke and reissue node macaroons instead of merely deleting files, and keep hot-wallet balances at operating-float size rather than treasury size.
Grading the disclosure
The company disclosed quickly, named the exposed data classes specifically, committed to repaying owed balances, and chose containment over business as usual, which compares favorably with the weeks-long silence common in crypto incidents. The gaps are equally clear. There is no attack vector, no affected-user count, no statement on whether data was exfiltrated or merely viewed, no hashing-algorithm detail, no mention of session-token or API-key exposure, and no public incident timeline or status page.
Swiss law sets an external benchmark here. Under Article 24 of the revised Federal Act on Data Protection, controllers must notify the Federal Data Protection and Information Commissioner of any breach likely to result in high risk to data subjects, and a dataset combining identities, bank accounts and permanent blockchain linkages is a strong candidate for that threshold. Set the company’s four-paragraph post against IVPN’s detailed August postmortem, or against Pocket Bitcoin’s iterative updates that converged on exact affected counts of 5,411 customers with 291 identity-document exposures, and the difference comes down to specificity and cadence.
Bottom line
The incident did not drain wallets or break Bitcoin. It showed that “non-custodial” on a landing page can coexist with a custodial float in the settlement pipeline, and that “privacy” can coexist with a honeypot database mapping identities to satoshis. Users had no way to audit either claim until an intrusion forced the architecture into public view.
Settlement-only self-custody with batched sweeps remains a legitimate, even sensible, design for merchant Lightning acceptance. What it needs is vocabulary and transparency. Processors should publish where funds sit between invoice and settlement, for how long, under whose keys, and at what maximum float, and merchants should ask those questions before plugging a terminal into their cash register. Until then, read the comparison table on the front page with the September 14 footnote attached. Every green checkmark on it is an engineering claim about systems that someone else was reading.
Frequently asked questions
Was any Bitcoin stolen in the Swiss Bitcoin Pay breach?
Not according to the company, which states that user funds are safe, that no unauthorized transfers have been identified, and that any amounts owed will be returned in full. Independent reporting has likewise found no indication that merchant private keys were compromised or that Bitcoin left self-custody wallets. The confirmed damage is to data: emails, Bitcoin addresses, IBANs, transaction histories and hashed passwords.
Is Swiss Bitcoin Pay custodial or non-custodial?
Both, depending on which moment of the payment lifecycle you examine. Settlement destinations are merchant-controlled wallets, which supports the non-custodial label. Incoming Lightning payments, however, are batched into company-controlled on-chain UTXOs on daily, weekly or monthly cycles, creating a temporary custodial float that the company acknowledged only after users challenged the “non-custodial” claim. The accurate description is settlement-only self-custody with transient processor float.
How risky is the exposure of hashed passwords?
It depends entirely on the hashing algorithm and salt strategy, which Swiss Bitcoin Pay has not disclosed. Slow, memory-hard functions such as Argon2id, bcrypt and scrypt keep most passwords safe even offline. Fast unsalted hashes do not. Either way, reuse turns a single hashed leak into multi-account compromise, so rotation and phishing-resistant 2FA on the associated email are the correct responses.
Can criminals steal money with my exposed IBAN?
Directly, no. An IBAN alone cannot initiate a wire out of your account. Indirectly, yes: unauthorized SEPA direct-debit mandates, invoice and payment-redirection fraud, and targeted bank-impersonation phishing all become cheaper and more credible with a real IBAN plus transaction history. Finance teams at affected merchants should tighten verification on any payment instruction received during the outage.
When will Swiss Bitcoin Pay services come back online?
Unknown. The company said on September 14 that it has no reopening date and is working to secure its infrastructure before restoring service, leaving merchant apps, dashboards, APIs and e-commerce integrations offline in the interim. Merchants dependent on the platform should line up fallback acceptance, such as direct wallet invoices or a self-hosted processor, rather than wait indefinitely.
Should merchants just self-host BTCPay Server instead?
Self-hosting removes the processor float and the centralized metadata database. It transfers the entire operational burden onto the merchant: patching within hours of critical advisories, macaroon hygiene, hot-wallet discipline, backups and incident response. The August 2026 macaroon exploit showed how unforgiving that burden can be, since nodes were drained before the public alert. The rational question is not custodial versus non-custodial, it is whether your operational maturity matches your threat model. Businesses without round-the-clock security capacity may be safer with a transparent processor that discloses its float policy than with sovereign infrastructure they cannot actually maintain.
