Crypto Payment Gateway GDPR 2026: We Read 10
We read 10 crypto payment gateways' privacy policies and DPAs in October 2026. One publishes a data processing agreement. None lists a sub-processor.
Brian OrmondKey Takeaways
- One of the ten publishes a data processing agreement. CoinGate's DPA names the merchant as "Data Controller" and UAB DECENTRALIZED as "Data Processor". The other nine publish a privacy policy and no DPA — they are describing their own processing, not yours.
- None of the ten publishes a sub-processor list. NOWPayments comes closest and keeps it behind an email: "If you would like to get a full list of all third parties with whom we share your data, please, e mail support@nowpayments.io".
- Only Confirmo names its transfer mechanisms — adequacy decisions, the EU-U.S. Data Privacy Framework, and SCCs "For transfers to the Dominican Republic, a country for which no adequacy decision currently exists".
- Two of the ten name no legal entity at all, so you cannot tell which company holds your buyers' data or under whose law. Of the eight that do, the registered homes include Panama and Saint Vincent and the Grenadines.
- Three policies predate the question they are being asked. Apirone's is "in effect as of Sept 1, 2017" — nine months before GDPR enforcement began — Plisio's was "Last Edited: March 12, 2019", and OpenNode's "Last Update: April 21, 2022".
You have an EU customer, a crypto checkout, and a privacy policy promising to say who your processors are. So you go looking for your gateway's data processing agreement, and on nine of the ten providers we read there is nothing to find. That is the crypto payment gateway GDPR problem in one sentence, and it is not a documentation gap — it is an answer.
Article 28 of the GDPR requires a contract between a controller and its processor, and the European Data Protection Board puts the consequence plainly: processors "need to comply with Article 28 GDPR, otherwise they would act as controllers". A gateway with no DPA is not a compliant processor missing paperwork; it is a second controller deciding things about your customers on its own account. So we read ten hosted gateways' policies and agreements on 20 October 2026, plus BTCPay Server's deployment docs as the self-hosted control, for four things: the role each claims, the entity behind it, who else gets the data, and for how long.
Your gateway is probably not your processor
Most merchants arrive with the card-payments model in their head: you are the controller, your processor is your processor, you sign a DPA, it lists sub-processors, done. Crypto gateways mostly do not work that way, and the tell is on the first page of their own documents.
CoinGate is the one that does. Its DPA defines the controller as the "Natural or legal person who accepted the Terms and Conditions" — you — and commits the processor to act "on documented instructions from the Data controller". That is the Article 28 shape.
Confirmo is the instructive opposite: the most detailed policy in the set, and it still does not make itself your processor. It names three group companies that "act as separate and independent data controllers" and one internal processor serving those controllers, not you. Triple-A does the same at larger scale, naming five group entities and mentioning "data processing agreements" only among safeguards it may apply "where applicable". A crypto gateway treats the merchant as its client, not its instructing controller — and a client does not get an Article 28 contract by default.
| Gateway | Role its own documents claim | Merchant DPA published |
|---|---|---|
| CoinGate | Processor, on documented instructions | Yes — standalone DPA |
| Confirmo | 3 independent controllers; 1 internal processor | No |
| Triple-A | Group controller across five entities | No — named as a safeguard only |
| BitPay | Controller; no processor language | No |
| NOWPayments | Controller; merchant acts as its "representative" | No |
| OpenNode | Controller (role not labelled) | No |
| BlockBee | Controller | No |
| Apirone | Controller | No |
| Cryptomus | Unstated | No |
| Plisio | Unstated | No |
| BTCPay Server (self-hosted) | No third party in the flow | Not applicable |
Read the right-hand column as a question about your own paperwork, not theirs: with no DPA, the processor section of your privacy policy has nothing to point at.
CoinGate: the only DPA on the open web
CoinGate's agreement is worth reading even if you use something else, because it shows what the missing document would have contained. The processor is "UAB DECENTRALIZED (operating the CoinGate platform)", "established and operating under the laws of Republic of Lithuania". Sub-processors are "a third party subcontractor engaged by the Data Processor", and clause 2.4 settles the permission in one line: "The Data Controller entitles Data Processor to enter into agreements with Sub-processors."
That is a general authorisation with no list and no notification clause. Mature processors elsewhere publish a roster plus a notice period in which you may object. Here you grant blanket permission to subcontractors you will never be told about.
The exit terms are better than average: clause 5.2 requires the processor on expiry to "delete or return all Personal Data to the Data Controller" at your choice, and to make sub-processors do the same. The retention table is the uncomfortable part — the account's life, then "10 (ten) years following the termination of the account".
One caveat worth catching before you cite the document to an auditor: it carries two dates that disagree — "v1 - 04/10/2023" at the top, "Date last updated: June 4, 2020" in the body. Either way it predates the blockchain guidance below. Our CoinGate review covers fees, settlement and custody.
Which company you are actually contracting with
"Where does my payment data go?" has a plainer answer than merchants expect. It goes to a company, in a country, and the country decides what recourse your customer has. Two of the ten do not tell you which company.
Cryptomus identifies its controller only as the "Cryptomus website", with no entity, number or address anywhere in the policy. Plisio names no company either; it refers throughout to "Plisio.net" and signs off with a support email. For a merchant that must name its processors, an unnamed counterparty is a dead end before any legal analysis starts.
Among the eight that do name an entity, the spread of registered homes is the finding. NOWPayments is operated by "FD Transfers LLC", "incorporated under the laws of Saint Vincent and the Grenadines, company number 1745 LLC 2022". BlockBee is "Blockbee Inc", "a company registered under the laws of Republic of Panama". Neither country appears on the European Commission's adequacy list, which on the day we checked covered 15 countries and territories plus the United States under the Data Privacy Framework.
Confirmo shows the standard is reachable. It names "Confirmo Ltd" in Dublin as "our main establishment in the European Union", "Confirmo srl" in Santo Domingo, "Confirmo US LLC" in Delaware, and its processor "Confirmo Services s.r.o." with a Prague address and "ID No 22633022". You can look all four up in a register.
| Gateway | Legal entity named in the policy | Registered in | Transfer safeguard the policy names |
|---|---|---|---|
| Confirmo | Confirmo Ltd, srl, US LLC; Confirmo Services s.r.o. | Ireland, Dominican Republic, USA, Czechia | Adequacy, EU-U.S. DPF, SCCs |
| CoinGate | UAB DECENTRALIZED | Lithuania | Referenced, no mechanism named |
| Apirone | Apirone OÜ | Estonia | None |
| Triple-A | Triple A Technologies Pte Ltd, Paytop SAS + 3 more | Singapore, France, USA, Hong Kong, UAE | "appropriate safeguards"; SCCs "where applicable" |
| BitPay | BitPay Inc.; BitPay B.V.; BitPay Software, LLC | USA — no address in the policy | "additional legal protections we have put in place" |
| OpenNode | OpenNode, Inc. | USA (Los Angeles) | None — says data leaves the EEA |
| BlockBee | Blockbee Inc | Panama | None |
| NOWPayments | FD Transfers LLC, company number 1745 LLC 2022 | Saint Vincent and the Grenadines | None |
| Cryptomus | None named | Not stated | None |
| Plisio | None named | Not stated | None |
Confirmo is the only one that names a transfer mechanism
If buyer data leaves the EEA, Chapter V of the GDPR wants a named safeguard. Confirmo supplies three, and the specificity makes them usable: adequacy decisions where they exist; the EU-U.S. Data Privacy Framework for "transfers to our entity in the United States (Confirmo US LLC)"; and SCCs "For transfers to the Dominican Republic, a country for which no adequacy decision currently exists", extended to "any of our service providers in the U.S. that are not certified under the DPF".
Copy that last clause into your own vendor questionnaire, because DPF coverage is per-organisation, not per-country: a US vendor is covered only if it has certified, which you check on the Data Privacy Framework list. Confirmo says of its own US entity that it "shall self-certify", future tense, so verify rather than assume.
The rest range from vague to candid. BitPay offers "Transfer of EU data may be subject to additional legal protections we have put in place" and sends you to a separate EU notice. Triple-A says transfers "are conducted using appropriate safeguards". OpenNode is the most honest of the quiet ones and states the fact: "As we are an American company, your information will be transferred out of the European Economic Area", naming no mechanism. Apirone, BlockBee, NOWPayments, Cryptomus and Plisio have no transfer clause at all.
Nobody publishes a sub-processor list
This is the cleanest result in the set, and the one we did not expect to be unanimous. Zero of the ten publish a list of sub-processors. Several name a vendor in passing, which is not the same thing: BlockBee names "Google, Inc." and notes Google stores data "on servers located in the United States"; Apirone names "Zendesk"; BitPay names "Bureau Van Dijk" and otherwise gives categories such as "cloud service providers providing cloud infrastructure"; Triple-A names "Google, Facebook and LinkedIn" in its cookie banner but "third-party vendors" in the policy.
Cryptomus and Plisio name nobody. Cryptomus lists recipients as "Affiliates", "Service Providers" and "third-party vendors, contractors, consultants, agents" who "are contractually required to protect the confidentiality and security of the information" — a promise you cannot audit, because you do not know who it binds.
NOWPayments alone acknowledges the list exists and can be had: "If you would like to get a full list of all third parties with whom we share your data, please, e mail support@nowpayments.io as the list may vary depending on your specific use of our Services." It is the one request in this article with a documented path.
NOWPayments makes you its representative
One clause inverts the relationship merchants assume, and it belongs in front of anyone integrating NOWPayments on an EU-facing store. Under "PROCESSING OF MERCHANT'S CUSTOMERS' DATA", the policy puts the legal basis on the merchant: you are "obliged to determine the personal data legislation for each its customer and comply with its requirements for each such customer separately", and must "obtain the voluntary consent of its customers or has any other legal basis" for the processing, FD Transfers' own included.
Then the role assignment: "The User (as a Merchant) acts as a representative of FD Transfers LLC in relations with the User's customers on the use of personal data, and also bears full responsibility to its customers for their personal data." You must also name FD Transfers to your customers as "the person to whom the personal data of the User's customers are transmitted".
And the backstop: "In the event that the User violates any personal data legislation and causes losses to FD Transfers LLC as a result of such a violation, the User shall indemnify all losses to FD Transfers LLC."
How long each one keeps it
We covered what the checkout collects separately; this is the other half of the sentence — how long the company that received it may keep it. Five of the ten publish a number, and the numbers are long for a defensible reason: anti-money-laundering law, not commercial preference.
| Gateway | Published retention period | Policy date on the page |
|---|---|---|
| CoinGate (DPA) | Account lifetime, then "10 (ten) years following the termination" | "v1 - 04/10/2023" / "June 4, 2020" |
| Cryptomus | "a maximum of seven (7) years after the termination" | 30 July 2026 |
| BitPay | "5 years or more after an account has been closed or become dormant" | 10 January 2026 |
| NOWPayments | "1 (one) year minimum after termination" for KYC | None on the document |
| Confirmo | "several years (e.g., ten years or more)" for AML and KYB data | 16 October 2026 |
| BlockBee | "the period mandated by applicable regulations" — no number | 10 September 2025 |
| Triple-A | Business relationship plus an unspecified period | None on the page |
| OpenNode | "no personal data longer than is necessary for payment processing" | 21 April 2022 |
| Apirone | "varies depending on the purpose" — no number | 1 September 2017 |
| Plisio | None; "cached or archived copies" for "a certain period" | 12 March 2019 |
Two things follow. A five-to-ten-year tail means a buyer's erasure request will usually be refused on a statutory basis, and that refusal is yours to explain, because the buyer is your customer. And where no number is published you cannot write a retention schedule — five of the ten.
Three policies that predate the question
A date is the cheapest signal of whether a document has been read since the law changed, and three of these have not been touched in years. Apirone's "is in effect as of Sept 1, 2017"; the GDPR became enforceable on 25 May 2018. Apirone is an Estonian OÜ, squarely inside the EEA — a policy from an EU-established company written before the regulation it would be judged under applied.
Plisio's was "Last Edited: March 12, 2019", names no company, no transfer clause and no retention period, and its only statutory nod is to the US Children's Online Privacy Protection Act, with no mention of the GDPR anywhere. OpenNode's is dated 21 April 2022.
At the other end, Confirmo's was updated on 16 October 2026, four days before we read it, and Cryptomus' on 30 July 2026. Two publish no date: Triple-A's page shows only a copyright line, and NOWPayments' is a PDF whose internal title is "NOWPayments Privacy-policy_2025_final.docx".
confirmo.net/legal and confirmo.net/privacy-policy/ each 301 to the matching confirmo.com path, and both of those 404. The live document is a PDF on static.confirmo.net, reachable only from a "Cookies" link in the navigation. The best policy in the set is the hardest to find.
The sub-processor nobody lists: the chain
Every document above stops at the edge of the company. The payment does not: an address and an amount are written to a public ledger that no DPA governs and nobody can amend. Since 7 July 2026 there is a settled European position on what that means, when the EDPB adopted version 2.0 of its Guidelines 02/2025 on processing of personal data through blockchain technologies. Three lines bear directly on a crypto checkout.
First, the ledger entries can be personal data: "On-chain metadata, including transaction identifiers, wallet addresses, event logs, receipts, state transitions and smart contract storage and related traces, may constitute personal data when they enable direct or indirect identification of a natural person". On a store that issues one address per order, that link to an identifiable person is exactly what your own records create.
Second, immutability is not a defence: "The EDPB emphasises that technical impossibility cannot be invoked to justify non-compliance with GDPR requirements". Nor is the architecture a shield — "neither this fact nor the selection of a particular technical infrastructure can be used as a reason not to comply with the GDPR".
Third, the chain's permanence is not a retention policy: "this is not a reason to assume that the lifetime of the blockchain is an appropriate data retention period. Rather, data should be deleted when the end of the processing activity is reached".
The practical reading is narrower than it sounds. You cannot unwrite the chain, so the compliance surface is the off-chain join — the row linking an address to a name, an email and an order. Keep it deletable and short-lived, and the on-chain record stops being a record about an identifiable person.
Self-host and the processor is you
BTCPay Server is the control case, and it resolves the article by subtraction: self-hosted, no third party sits in the payment flow, so there is no DPA to chase, no offshore entity, no sub-processor list to request. You are the controller and your own infrastructure is the processing.
That ends the moment you use somebody else's instance, and BTCPay's own docs are unusually frank. A third-party host can see "Total number of users" and "The email and username of those users", and the third-party hosting page advises that "it's best to assume they may know all details about your BTCPay Server usage". On a hot wallet that host "will act as a custodian of your private keys and thus your funds".
So a free hosted instance is a processor with all the visibility of a commercial gateway and, typically, none of the paperwork — no DPA, no named entity, no retention terms. Our BTCPay Server review covers the trade-off. If data protection is why you chose it, host it yourself.
What to ask your gateway this week
Four emails and an afternoon of reading close most of this gap:
- Ask for the DPA in writing, even where none is published. Nine publish none; that is not the same as refusing to sign one. A refusal tells you the provider considers itself an independent controller.
- Request the sub-processor list. NOWPayments documents the route. Ask the other nine and file the answers; a list you hold beats a clause you cannot audit.
- Get the transfer mechanism named, not described. "Appropriate safeguards" is not an answer; a clause reference is. For a US vendor, check its certification on the DPF list rather than taking a country-level claim.
- Write down which entity holds the data. If your provider names none, that sentence cannot be written, and your own privacy policy is the document that goes short.
- Make the off-chain join expire. Put a retention period on the table mapping addresses to customers and enforce it in code. It is the only part of a crypto payment you can delete.
Two neighbouring questions complete the picture: how long a gateway may hold a payment for AML review, and what your API credentials can do — who inside your own stack can read these records.
- Crypto Gateway Customer Data 2026: We Checked 10
- Crypto Payment Screening 2026: Where the Money Goes
- Crypto Gateway AML Holds 2026: Nobody Says How Long
- No-KYC Crypto Payment Gateways: 5 Options and Their Conditions
- Crypto Gateway API Key Security 2026: We Checked 9
- OpenNode Review: Fees, Settlement, KYC and Custody
You can only name a processor that names itself. Check that before you integrate, not after a subject access request.
We track fees, custody, KYC and settlement for every processor in the directory. CoinGate is the only one here that publishes a merchant DPA; Confirmo names every entity and every transfer safeguard; BTCPay Server puts no third party in the flow at all.
Compare Crypto Payment Gateways →Affiliate disclosure: Payyd earns a commission if you sign up to some providers linked on this page. It changes none of the entity names, quoted clauses, jurisdictions or retention periods reported here, all of which come from the providers' own published documents and are linked below.
FAQ
Do crypto payment gateways need to be GDPR compliant?
If they process personal data of people in the EU when goods or services are offered there, the GDPR applies wherever the company is registered. What varies is whether the gateway is your processor or its own controller. The EDPB says a processor must comply with Article 28, "otherwise they would act as controllers" — so a gateway with no DPA is answering for its own processing, not yours.
Which crypto payment gateway has a data processing agreement?
Of the ten we read on 20 October 2026, only CoinGate publishes a standalone merchant DPA, naming UAB DECENTRALIZED as processor and the merchant as controller. The other nine publish a privacy policy only — which is not a refusal to sign, but it means you have to ask.
Where is my crypto payment data stored?
It depends on the entity, and two of the ten name none. Among the rest the registered homes were Lithuania, Estonia, Ireland, Czechia, the US, Singapore, the Dominican Republic, Panama and Saint Vincent and the Grenadines. Only Confirmo maps transfers to safeguards.
Is a crypto wallet address personal data under the GDPR?
It can be. EDPB Guidelines 02/2025, version 2.0, say on-chain metadata including "transaction identifiers, wallet addresses, event logs, receipts" and related traces "may constitute personal data when they enable direct or indirect identification of a natural person". A per-order address stored beside a customer record is that join.
Can a customer ask me to delete a blockchain transaction?
They can ask, and you cannot comply on-chain. The EDPB does not accept that as the end of it: "technical impossibility cannot be invoked to justify non-compliance with GDPR requirements". Make the off-chain data deletable instead — removing the record that links an address to a person removes the identifiability.
Do I need a sub-processor list from my crypto gateway?
If your own privacy policy promises to disclose recipients, you need to know who they are. None of the ten publishes a list. NOWPayments documents how to request one: email support, because "the list may vary depending on your specific use of our Services".
How long do crypto payment gateways keep customer data?
Where a number is published it is long: CoinGate's DPA says ten years after the account closes, Cryptomus seven at most, BitPay five or more, Confirmo "ten years or more" for AML data, NOWPayments one year minimum for KYC. The other five publish no period.
Sources
Primary documents, read 20 October 2026:
- CoinGate — Data Processing Agreement (UAB DECENTRALIZED; clauses 2.4 and 5.2; 10-year retention table)
- Confirmo — Privacy Policy (PDF) (four named entities; adequacy / DPF / SCCs; "Last Updated: 16.10.2026")
- Triple-A — Privacy Policy (five group entities; no date on the page)
- BitPay — Privacy Policy (BitPay Inc.; Bureau Van Dijk; "Last Updated: January 10, 2026")
- NOWPayments — Privacy Policy (PDF) (FD Transfers LLC, Saint Vincent and the Grenadines; merchant as representative)
- Cryptomus — Privacy Policy (no entity named, seven-year maximum retention; "Last Updated July 30, 2026")
- BlockBee — Privacy Policy (Blockbee Inc, Republic of Panama; Google named; "Effective Date: September 10, 2025")
- OpenNode — Privacy Policy (OpenNode, Inc.; "Last Update: April 21, 2022")
- Apirone — Privacy Policy (Apirone OÜ; Zendesk named; "in effect as of Sept 1, 2017")
- Plisio — Privacy Policy (PDF) (no entity, no transfer clause, COPPA only; "Last Edited: March 12, 2019")
- BTCPay Server — Third-party hosting (what a host can see)
- EDPB — Guidelines 02/2025 on blockchain technologies, v2.0 (PDF) (adopted 07 July 2026)
- EDPB — news release on adoption of the final blockchain guidelines
- European Commission — Adequacy decisions
- U.S. Data Privacy Framework — participant list