Crypto Gateway Data Breach 2026: 1 of 12 Tells You

Your gateway is breached on a Friday. Your buyers' email addresses, wallet addresses and order histories sat on its servers, and you find out from a post on X, like everyone else. By then you are late: the law gave you 72 hours from the moment you could reasonably be certain, and the clock did not wait for the announcement. A crypto payment gateway data breach is the one failure where the penalty lands on the merchant rather than the processor, and almost nothing you signed says who has to phone you.

So we read the published documents of twelve hosted crypto payment gateways on 24 October 2026, and swept all thirteen hosts for a vulnerability-reporting file. We wanted one sentence: a promise to tell the merchant, with a deadline. One gateway of twelve has it. Eight have no breach clause at all, one tells you to notify it, and the best security programme in the set belongs to a company that never says it will call.

The 72-hour clock is yours, not your gateway's

The asymmetry at the centre of this is written into two consecutive sentences of the GDPR. Article 33(1) gives the controller "without undue delay and, where feasible, not later than 72 hours after having become aware of it" to notify the supervisory authority. Article 33(2) gives the processor one line and no number: "The processor shall notify the controller without undue delay after becoming aware of a personal data breach."

Read that as a merchant. If your gateway is your processor, it owns a vague duty and you own a hard deadline. Your 72 hours begin when you are aware, and the EDPB fixes awareness at "a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised". A gateway that spends four days deciding whether its intrusion touched customer records has broken no number, because it agreed to none. You did.

Article 34 adds the harder job. Where a breach is "likely to result in a high risk to the rights and freedoms of natural persons", the controller must tell the data subjects themselves — your buyers, in clear language, with the likely consequences. If the gateway is your processor, that email comes from you, about a system you do not run, on facts you must extract from a company with no obligation to answer quickly. The breach clause in your processing agreement is therefore the most valuable sentence in it.

What twelve gateways actually promise

We checked the same twelve hosted gateways we use for every compliance read here, so the results line up with data protection agreements and the Travel Rule. Three carry a breach clause, one runs backwards, eight carry none.

Gateway	Breach clause?	Who it will tell	Window	Document date
CoinGate	Yes — DPA cl. 4.3	The merchant, as controller	"immediately if possible"	Two, contradictory: "v1 - 04/10/2023" and 4 June 2020
Triple-A	Yes — privacy policy	Supervisory authority and affected individuals	"as required by applicable data protection laws"	Undated
OpenNode	Partial	Regulators; you only where the law compels it	None	21 April 2022
BlockBee	Inverted	You tell BlockBee	"immediately" — your duty	10 September 2025
Confirmo	No	—	—	16 October 2026
BitPay	No	—	—	10 January 2026
Cryptomus	No	—	—	30 July 2026
NOWPayments	No	—	—	Undated
B2BinPay	No	—	—	Undated
PassimPay	No	—	—	10 February 2024
Plisio	No	—	—	12 March 2019
Apirone	No	—	—	In effect as of 1 September 2017

Three numbers are worth keeping. One of twelve commits to telling the merchant. Zero of twelve commit to a deadline in hours. And four of twelve work from a document written before the question mattered: Apirone's has been in effect since September 2017, Plisio's was last edited in March 2019, and NOWPayments and B2BinPay publish no date at all.

CoinGate: the only clause that points at you

CoinGate is the only gateway here that publishes a merchant processing agreement on the open web, and clause 4.3 is why it matters. The processor "shall take all necessary actions to assist and shall promptly notify the Data Controller" about "any accidental or unauthorized access to Personal Data or any other security incidents" — then the only timing language in the document: "immediately if possible".

That is better than everyone else and still short of what Article 33 needs. "Immediately if possible" is a qualified best effort, not a deadline, and the clause never says what you will be told. Article 33(3) wants the nature of the breach, the categories and approximate numbers of data subjects and records, the likely consequences and the remedial measures. A notification lacking those is a warning.

The document also undermines its own currency, carrying two dates that cannot both be right: "v1 - 04/10/2023" at the top and "Date last updated: June 4, 2020" in the body. We flagged the same contradiction reading it for sub-processors and transfers four days earlier. The full CoinGate review covers what else that agreement carries.

Triple-A and OpenNode notify someone, just not you

Triple-A has the cleanest breach sentence in the set, and the merchant is not in it: "In the event of a data breach, Triple-A will notify the relevant supervisory authority and affected individuals as required by applicable data protection laws." That is the controller's duty, discharged by the controller — a good commitment to the buyer and none at all to the shop.

Triple-A's group spans three jurisdictions — Triple A Technologies Pte Ltd in Singapore, Paytop SAS as its European arm, Triple A Technologies Inc in the US — so a European buyer has an establishment inside the EEA to land on, as they do with CoinGate in Lithuania and Confirmo in Czechia. Several providers here have no EEA arm at all, which is where the one-stop-shop problem below bites.

OpenNode goes half as far, twice. It will "notify all relevant regulatory and enforcement agencies of any data breach that is required under applicable law" — agencies, not customers, and only where required. Then, on telling you: "In the event that we are required by law to inform you of a breach to your personal information we may notify you electronically, in writing, or by telephone, if permitted to do so by law." A clause reaching "may" after passing through "required by law" and "if permitted" is not something you can plan around. The policy is dated 21 April 2022, under OpenNode, Inc.

BlockBee inverts it: you notify them

BlockBee's privacy policy contains exactly one sentence about unauthorised access to your data, and it assigns the duty to you: "If you suspect any unauthorized access to your Personal Information or account, notify us immediately" — the one deadline anybody in this set uses, pointed in the wrong direction.

We have seen this shape before. NOWPayments' terms make the merchant "a representative of FD Transfers LLC in relations with the User's customers" and add an indemnity, so obligations that normally flow down to a processor flow up instead. BlockBee does the lighter version: the only notification duty in its document is the customer's. The rest is the standard formula. The policy is effective 10 September 2025; the company is Blockbee Inc of Panama City. To its credit, it is one of only two hosts here with anywhere to send a vulnerability report.

What the other eight call security

Eight gateways have no breach clause. That does not make their documents silent on security — it makes what they say an intention rather than an obligation. We quote each section in full, because the brevity is the point.

Gateway	What its security section says	Standard named?
Confirmo	"We maintain a formal Data Security Incident Response Plan", plus encryption at rest and in transit, role-based access control, mandatory MFA with "security keys or passkeys", and "vulnerability scanning and regular penetration testing"	No standard, but every control is named
BitPay	"administrative, technical, and physical security designed to safeguard personal information in our possession", then "we cannot guarantee the security"	No
NOWPayments	"takes all the reasonable measures to protect Users Personal data from unauthorized access by third parties"	No
Cryptomus	"Cryptomus has implemented security measures to comply with acknowledged international security standards." That is the section, in full	No — never named
B2BinPay	"a variety of security measures to ensure the confidentiality of your Personal Information"	No
Plisio	"appropriate methods of collecting, storing and processing data and security measures"	No
PassimPay	"no electronic transmission over the Internet and information storage technology can be guaranteed to be 100% secure"	No
Apirone	No security section. Liability excluded for "data loss or corruption"	No

Cryptomus is the one to sit with. Its policy was updated on 30 July 2026 — recent, not legacy — and the complete security section reads: "Cryptomus has implemented security measures to comply with acknowledged international security standards." No standard is named, so there is nothing to verify and nothing to hold. The word "breach" appears nowhere; "security incidents" appears once, as a reason Cryptomus may disclose your data rather than protect it.

BitPay deserves a note for honesty. Its notice, updated 10 January 2026, says plainly that "no security measure or modality of data transmission over the internet is 100% secure". True, and useful — it simply leaves the follow-up, what happens the day that proves out, unanswered.

Confirmo is the counter-example, and still has no clause

If you only read security sections, Confirmo wins outright. Its privacy policy, last updated 16 October 2026, is the only one describing controls specific enough to audit: encrypted databases at rest, TLS in transit, role-based access control, mandatory multi-factor authentication using "security keys or passkeys, which makes remote phishing nearly impossible", plus "vulnerability scanning and regular penetration testing". Then the sentence nobody else writes: "We maintain a formal Data Security Incident Response Plan to ensure that we can rapidly detect, contain, and recover from any security incidents."

It is the most reassuring paragraph in the set, and it is not a notification clause. A response plan you cannot read, with no commitment to tell the merchant and no deadline, is a statement about Confirmo's competence rather than a right you hold. The same document puts the risk back: "any transmission to our site is therefore undertaken at your own risk".

Confirmo proves the standard here is reachable — a current document, named controls, a real incident plan. It is one sentence short of the model, and that sentence is the one with a number in it. The Confirmo review covers its fees and licensing.

Nobody to tell: 2 of 13 publish a security.txt

There is a prior question. Before a company can notify you of a breach, somebody has to be able to notify it. RFC 9116 defines /.well-known/security.txt: a plain text file with a security contact, an expiry date and, ideally, a link to the disclosure policy. It costs nothing to publish. We checked all thirteen hosts.

Host	security.txt	What it carries
coingate.com	HTTP 200	Contact, Expires, Encryption, Canonical, Signature, and a Policy field returning 410 Gone. Expires: 2050-01-01
blockbee.io	HTTP 200	Contact and Expires: 2027-10-01. No Policy field
confirmo.com	HTTP 404	—
cryptomus.com	HTTP 404	—
nowpayments.io	HTTP 404	—
bitpay.com	HTTP 404	—
plisio.net	HTTP 404	—
apirone.com	HTTP 404	—
b2binpay.com	HTTP 404	—
passimpay.io	HTTP 307, then 404	Redirects to a locale path that serves none
www.triple-a.io	HTTP 404	—
opennode.com	HTTP 404	—
btcpayserver.org	HTTP 404	No file, but the repository carries a SECURITY.md

Two of thirteen. Eleven crypto payment companies — several holding IBANs, identity documents and transaction histories — have no published address for a researcher who finds a hole. The report goes to support, or nowhere.

Neither file is in good order. CoinGate's is the fuller one, with a PGP key and a signature, and it sets Expires: 2050-01-01 — twenty-three years out, against RFC 9116's recommendation that the value "be less than a year into the future to avoid staleness". Its Policy field points at coingate.com/security-policy, which returns 410 Gone: a deliberate code meaning the page was deleted and is not coming back. The contact works; the policy it advertises has been withdrawn. BlockBee's file is the minimum that validates.

BTCPay Server has no security.txt either, but its repository carries a SECURITY.md that asks for private reports and then does what no gateway here does — commits to a time: "Please allow for up to 2 business days for an acknowledgement of receipt", with remediation targeted "within 90 business days" and explicitly not guaranteed. That is the only service level in this article, and it is owed to a researcher, not to a merchant.

September 2026: what disclosure looked like in practice

On 14 September 2026, Swiss Bitcoin Pay — a non-custodial bitcoin payment processor based in Neuchatel — took its own servers offline. Its statement, posted to X: "A malicious user has likely gained access to Swiss Bitcoin Pay's internal systems." The company said the intruder may have accessed customer email addresses, Bitcoin addresses and IBANs, transaction history, and hashed passwords, and that user funds were safe. No restart date was given.

Note what that is and is not. Funds were not the loss; a non-custodial design protected them, exactly as advertised. The loss was the data around the payments — what a no-KYC gateway accumulates anyway, and what no merchant weighs when comparing fees.

Now apply the law. Switzerland is outside the EEA, and Article 24 of its revised Federal Act on Data Protection takes a different approach: the controller notifies the Federal Data Protection and Information Commissioner of a breach likely to cause "a high risk to the data subject's personality or fundamental rights" "as quickly as possible" — and that is the whole deadline. There is no 72-hour figure in Swiss law. Telling individuals is conditional too, under Article 24(4): only "if this is required for their protection or if the FDPIC so requests". And Article 24(5)(c) lets the controller dispense with telling them where the information is "equally guaranteed by making a public announcement".

Which means a public post may have been the legally sufficient channel. The lesson, plainly: your gateway's jurisdiction decides how, and how fast, you find out — and a design that keeps your money safe says nothing about your customer list.

No DPA means your gateway is a second controller

Everything above assumes your gateway is your processor. For most of these companies that assumption fails, and the failure makes things worse. Article 28(3)(f) requires a processing contract to stipulate that the processor "assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36" — Article 33 among them. When we went looking for those agreements, CoinGate published the only one. A company processing your buyers' data with no agreement and no instructions from you is not a processor with missing paperwork; it is acting as a controller in its own right.

That reclassification cuts both ways, and the second cut is sharp. A controller established outside the EEA but caught by Article 3(2) still owes Articles 33 and 34 in full. It must appoint an EU representative under Article 27 — and here is the part almost nobody knows, from the EDPB guidelines whose entire 2023 update was written about this situation: "the mere presence of a representative in a Member State does not trigger the one-stop-shop system", so "the breach will need to be notified to every supervisory authority for which affected data subjects reside in their Member State."

Count the entities in this set against that. FD Transfers LLC in Saint Vincent and the Grenadines. Blockbee Inc in Panama. BitPay Inc and OpenNode, Inc in the United States. NILESPAY FINANCE INC in British Columbia. A breach at any of them touching buyers in eight EU states is eight separate notifications, by a company whose documents do not contain the word breach. It will not happen, and the exposure does not vanish with it: it sits with whoever the regulator can reach, which is the merchant with the storefront and the European customers.

What to put in writing before your next integration

• Ask for the processing agreement by name. Not the privacy policy — the DPA. If there is none, you are dealing with a second controller, and your records should say so.
• Ask for the breach clause in hours. "Immediately if possible" is the current market best. Twenty-four hours is normal elsewhere in payments; ask for it in writing, by email if the contract will not move.
• Ask what the notice will contain. Article 33(3) is the shopping list: nature, categories and approximate numbers, likely consequences, remedial measures. A notice without them cannot be forwarded to a regulator.
• Ask who, and keep the address. A named security contact, not the support queue. Two of thirteen publish one; for the other eleven, getting one into your runbook is the whole gain.
• Reduce what they hold. We traced what each gateway collects and what a leaked API key reaches; data you never send cannot turn up in a breach notice. Self-hosting removes the third party entirely, and hands you every duty in exchange.

The clock you answer for is started by a phone call eleven of these twelve companies have never promised to make. Write the deadline down, or inherit theirs.

FAQ

Does a crypto payment gateway have to tell me about a data breach?

Only if it is your processor and your contract says so. GDPR Article 33(2) obliges a processor to notify the controller without undue delay, but that duty lives in the processing agreement, and of twelve gateways only CoinGate publishes one. A gateway acting as its own controller owes you nothing: its duty runs to the supervisory authority and the affected individuals, not to the merchant.

How long do I have to report a gateway breach to my regulator?

Seventy-two hours from when you become aware, under Article 33(1), and the EDPB puts awareness at a reasonable degree of certainty that personal data has been compromised. Your clock starts when the gateway tells you, so a provider with no notification clause can consume most of the window before you know it opened.

Who tells my customers if the gateway loses their data?

Whoever is the controller for that data. If the gateway is your processor, Article 34 puts the communication on you when the breach is likely to be a high risk to those buyers. If it is a separate controller, it owes that communication itself, and Triple-A is the only one of twelve that says in writing it will make it.

Which crypto payment gateway has the best breach disclosure?

CoinGate, on the documents: the only published processing agreement that promises to tell the merchant, and one of two hosts with a vulnerability-reporting address. Confirmo has the better security programme and a current policy, and no notification clause at all.

Is a public post on X enough to notify customers of a breach?

Under Swiss law it can be. Article 24 of the revised Federal Act on Data Protection lets a controller dispense with telling data subjects individually where the information is equally guaranteed by a public announcement, and Swiss Bitcoin Pay disclosed its September 2026 intrusion that way. The GDPR equivalent, Article 34(3)(c), is narrower: it applies only where individual contact would involve disproportionate effort.

What should be in the breach clause of a gateway contract?

Four things, and almost no crypto gateway offers them unprompted. A deadline in hours; the Article 33(3) content set, so the notice is usable rather than a heads-up; a commitment to help you assess and notify, which Article 28(3)(f) already requires of a processor; and a named contact that is not general support.

Does self-hosting remove the problem?

It removes the dependency, not the duty. Run BTCPay Server and no third party holds your buyers' data, so nobody else has to tell you anything. You are then the sole controller: the 72-hour clock, the Article 34 communication and the documentation are yours.

Sources

Read and measured 24 October 2026:

• GDPR Article 33 — 72 hours; 33(2); 33(3)
• GDPR Article 34 — high risk; 34(3)(c)
• GDPR Article 32 — security of processing
• EDPB Guidelines 9/2022, v2.0 (PDF) — 28 March 2023; paras. 31, 43–44, 73
• Swiss FADP, Art. 24 (Fedlex) — 24(4) and 24(5)(c)
• RFC 9116 — s. 2.5.5 and 2.5.7
• CoinGate Data Processing Agreement — cl. 4.3; UAB DECENTRALIZED
• CoinGate Privacy Policy — August 2026
• CoinGate security.txt — Policy field returned HTTP 410
• Triple-A Privacy Policy — undated; Paytop SAS
• OpenNode Privacy Policy — 21 April 2022
• BlockBee Privacy Policy — 10 September 2025; Blockbee Inc
• BlockBee security.txt
• Confirmo Privacy Policy (PDF) — 16.10.2026
• BitPay Privacy Notice — 10 January 2026
• Cryptomus Privacy Policy — 30 July 2026
• NOWPayments Privacy Policy (PDF) — FD Transfers LLC
• B2BinPay Privacy Policy — undated
• PassimPay Privacy Policy — 10 February 2024
• Plisio Privacy Policy (PDF) — 12 March 2019
• Apirone Privacy Policy — in effect as of 1 September 2017
• BTCPay Server SECURITY.md — 2 business days to acknowledge
• Bitcoin Magazine — Swiss Bitcoin Pay breach, 14 September 2026