Crypto Gateway Customer Data 2026: We Checked 10

Your customer clicks pay, lands on a page you do not control, and sends coins. What did that page learn about them, and what did your own server hand over before they ever got there? That is the crypto gateway customer data question, and it is the one part of choosing a processor nobody publishes a comparison of.

It matters more than the fee table for two reasons. If your checkout forwards a buyer's name and date of birth to a third country, that is your disclosure to make, not your gateway's. And if a buyer can be asked for photo ID mid-payment, that is a conversion problem you will meet as a support ticket. So we read ten providers' reference docs, terms and privacy policies on 18 October 2026 — the field lists, not the landing pages.

The three ways customer data reaches your gateway

Almost every argument about crypto checkout privacy collapses once you separate three things, because providers that look identical in marketing sit in different columns below.

Merchant-pushed fields are the ones your server puts on the API call: an email, a name, an IP. They are the largest surface by far, optional everywhere we looked, and entirely your decision — which also means a plugin can be making it for you. Buyer-prompted fields are what the hosted page asks your customer for, which is the only route that costs you conversion. Automatic collection is what the provider records because a browser visited it: IP address, user agent, cookies. That last column is never zero on a hosted checkout, and it is the one merchants forget exists.

Gateway	Buyer fields the API accepts	Does the checkout ask the buyer?	Automatic collection documented
CoinGate	Email, IP, first name, last name, date of birth, residence country (all optional)	Not documented	IP, user agent, referrer, visit time
Binance Pay	Name, phone, email, registration time, browser language, device IP, cookie ID, shipping name and address (all optional)	Buyer pays inside the Binance app	Not stated in the API reference
BitPay	Email (invoice notifications)	Yes — and ID above a threshold	IP of invoice viewers, device, first and third-party cookies
Plisio	Email (optional)	Yes, unless you pre-fill the field	Not documented in the API reference
OpenNode	Payer name, payer email (both optional)	Not documented	Not stated in the API reference
OxaPay	Payer email, "for reporting purposes" (optional)	Not documented	Not stated in the API reference
Blockonomics	None documented, but it keeps a copy of anything you collect	No	IP, browser software, cookies
Cryptomus	None documented	No — coin and network choice only	Not stated in the API reference
BlockBee	None documented	No — coin selection and confirmation	Not stated in the API reference
BTCPay Server	None — and the docs say so explicitly	Refund email by default; forms are opt-in	Your server, not a third party

"Not documented" is doing real work there: it means the field or practice is absent from the provider's own reference pages, which is a reason to ask rather than to relax.

CoinGate: the shopper object goes as far as a date of birth

CoinGate's order API has a shopper object, and it is the most detailed buyer-data surface of any non-custodial gateway we have read. The reference is unambiguous that none of it is compulsory: "All fields within the shopper object are optional", and the only required fields on the call are the price, the currency, a title and a description.

Field	CoinGate's own description	Required
shopper.email	"Shopper's e-mail address"	No
shopper.ip_address	"Shopper's IP address"	No
shopper.personal.first_name	"Shopper's first name."	No
shopper.personal.last_name	"Shopper's last name."	No
shopper.personal.date_of_birth	"Shopper's date of birth. Must be a valid date in the format YYYY-MM-DD."	No
shopper.personal.residence_country	"Shopper's country of residence. Must be a valid Alpha-2 country code."	No

The privacy policy then confirms the fields are not decoration. Its anti-money-laundering section lists "Payees' information – when you make a payment to our client (merchant): email, name, surname, date of birth", adds country of residence "and any other data required by applicable laws", and states that the processing covers "as well as shoppers and beneficiaries of transactions". Separately, on visiting the platform it records IP address, user agent, referrer URL and visit date and time.

The honest reading is not "CoinGate collects a lot" — it is that CoinGate built the plumbing for a compliance flow it may need and left the tap in your hands. If your plugin fills that object, your customer's date of birth sits in a third party's AML record. Our CoinGate review covers the fee and custody side.

Binance Pay: name, phone, email, IP and a cookie ID

Binance Pay accepts the widest buyer surface in the set, and the create-order reference offers no explanation for any of it. The optional buyer object takes a full name (first and last are required inside the object once you send it), "Mobile phone number of the buyer from merchants", "Email of the buyer from merchants", "Buyer registration time on merchant side, epoch time milliseconds", and the browser language your platform shows them.

Field	Binance's own description	Required
buyerEmail	"Email of the buyer from merchants"	No
buyerPhoneNo	"Mobile phone number of the buyer from merchants"	No
buyerName	"Name of buyer full name from merchants" (first and last name required within it)	No
buyerRegistrationTime	"Buyer registration time on merchant side, epoch time milliseconds"	No
orderClientIp	"IP of the client device when submit the order"	No
cookieId	"The cookie ID of the buyer"	No
shippingName / shippingAddress / shippingPhoneNo	"The recipient name" / "Shipping address" / "The phone number of a recipient (including extension)"	No

cookieId is the field worth sitting with: it is the only place in ten providers' documentation where a gateway asks a merchant to forward a browser identifier, and the reference gives no purpose for it — no fraud-scoring note, no risk-control paragraph, nothing. A referenceBuyerId works the other way, restricting payment to a named Binance ID, but "Only whitelisted merchant can use this restriction feature".

The buyer side has no ambiguity at all. Binance Pay payments happen inside the Binance app — "Users open Binance APP and scan QR Codes" — so your customer necessarily holds a Binance account, with whatever verification Binance required of them. That is the clearest case in the set where accepting a gateway means accepting your customer was identified by someone else.

Plisio: the one checkout that asks your customer

Nine of the ten leave the buyer alone or let the merchant decide. Plisio is the exception, and its documentation is refreshingly direct about it. The optional email parameter on invoice creation reads: "Before paying an invoice, your client will be asked to enter an email to which a notification will be sent."

Two consequences for a live store. Integrate Plisio without touching that field and your customer meets an email form between the cart and the coins, a step you did not design and cannot style. Pre-fill it and you are choosing what Plisio stores against the invoice: the buyer's real address is a disclosure, your own support address is not. Either is defensible; drifting into one by accident is not.

BitPay: the invoice watches, and above a threshold it asks for ID

BitPay is the only provider in this set that documents all three routes at once, and the only one where a payment can stop and ask your customer for a government document.

Start with what the invoice records. The privacy policy lists "Technical information including IP addresses used to view the BitPay invoice" — viewing, not paying — along with browser, device and operating-system type, device identifiers, pages visited, access times, the referring site and the visitor's internet service provider. For payers it also lists an email address and a crypto wallet address, and on cookies it says "We may collect information about your activities on our Sites via first and third-party cookies". The email is not idle: the terms describe BitPay notifying "the Shopper or Donor, as applicable, of the underpayment by email and/or SMS message".

Then the part that can end a sale. BitPay's terms state plainly that "Shoppers and Donors may be required to complete a verification process at the time of payment", with the requirement depending on the transaction amount — and the current terms name no amount.

None of this makes BitPay a poor processor — it is a regulated one and the behaviour follows from that. It does mean a high-value cart on BitPay carries a verification step your competitor on a no-KYC gateway does not, which belongs in your decision rather than in a support ticket. The BitPay review covers fees and settlement.

BlockBee, Cryptomus, OxaPay and OpenNode: the thin end

Four providers sit at the other end, and they differ enough from each other to be worth separating.

• BlockBee documents no buyer field at all. Its hosted checkout takes an API key, a redirect URL, a notification URL and an amount, plus optional currency, expiry, webhook method and an item_description — "Description that appears on the checkout page." The buyer picks a coin and pays.
• Cryptomus is the same, with one trap for the careless. No buyer parameter appears on invoice creation; the page tells the payer only that "the user will be able to select the cryptocurrency and network to pay this bill". Its additional_data field is described as "Additional information for you (not shown to the client)" — a merchant note, which is exactly the kind of field that ends up holding a customer email because nobody reads it as personal data.
• OxaPay takes one field, and says why. The optional email is there to "Provide the payer's email address for reporting purposes", with amount the only required parameter on the call.
• OpenNode takes two: "Payer's name" and "Payer's email", both optional. Its one email-sending option points the other way — notify_receiver is "Notify receiver (you) via email when this checkout is paid", which is the merchant, not the buyer.

In all four the buyer-facing page is a coin picker and an amount. If handing over as little as possible is the priority, this is the shape to look for — and the thing to check next is the integration, not the privacy policy, because an optional field your plugin fills is not optional in practice.

BTCPay Server: nothing by default, except the refund email

Self-hosting changes the question rather than answering it. There is no third party on your checkout, so the only party collecting anything is you — and BTCPay's documentation is the only one in the set that states its own limit outright: "Currently there is no way to collect Buyer Information using the BTCPayServer interface."

Two qualifications matter. First, there is one buyer-facing prompt, and it is on by default: a refund email. The fix is a checkbox — the docs tell you to go to Stores > Settings > Checkout Experience and "uncheck 'Requires a refund email' box". If you never issue refunds through BTCPay, that is a field you are collecting for nothing.

Second, the Forms feature exists so you can collect more when you want to, with built-in Address and Email forms and per-field required settings. The useful detail is what happens next: "By default, none of the user input will be shown on the invoice receipt", and surfacing it takes a deliberate receiptData fieldset. Collection and display are separate switches, which is the right way round. Our BTCPay Server review covers what self-hosting costs.

Blockonomics: no relationship, and a copy of the data

Blockonomics takes the clearest legal position of the ten, and it is worth quoting because most merchants assume it without checking: "OneByZero Tech does not have a direct relationship with Customers' End Users", and on anything a merchant gathers, "We do not control the purposes or the means by which this personal information is collected." In other words, your buyers are your data subjects, not theirs.

And then the sentence that qualifies it: "If you request personal information from your customers as part of the transaction, we retain a copy of this information." Not controller, but holder. The policy also records IP addresses and "your web-browser software" from people using the service, and says that "we or companies we work with may place cookies on your computer or other devices".

No relationship, no control, and a copy: the most common real-world shape in crypto payments, and the one that catches merchants out when a buyer asks where their data went.

Who holds crypto gateway customer data, and for how long

Retention is where the documentation thins out fastest. Only two of the ten give a period a merchant could plan around, and one of those is long.

Provider	What it says about your buyer's status	Retention it publishes
CoinGate	Processing covers "shoppers and beneficiaries of transactions"	Identity data, including "beneficiary identity data", "for up to 8 years from the date of the end of the business relationship with the client"; 10 years where needed to protect legal interests
BitPay	Shoppers and Donors are named parties in the terms	"We retain data as required or permitted by law"; identification may be held "for 5 years or more after an account has been closed or become dormant"
Blockonomics	"does not have a direct relationship with Customers' End Users"	No period published; retains a copy of what the merchant collects
Binance Pay, Plisio, OxaPay, OpenNode, Cryptomus, BlockBee	Not addressed in the integration documentation	No buyer-specific period in the pages we read
BTCPay Server	No third party involved	Whatever your own database does

The asymmetry is the finding. A provider will tell you precisely which parameter accepts a date of birth and nothing at all about how long it keeps one. If retention matters in your jurisdiction, the only providers above you can answer from published text are the self-hosted one and the two regulated ones — and the regulated answers are counted in years.

What to change in your integration this week

None of this needs a migration. Five checks, in the order they pay off:

1. Log one real payment request from your own server and read it. Not the plugin's settings screen — the JSON. Every buyer field above is optional, so the only way to know what you send is to look.
2. Delete the fields you cannot justify. A date of birth or a cookie ID on a payment request needs a reason you could give a customer out loud. "The plugin filled it" is not one.
3. Decide the Plisio email question deliberately if you use it: let the prompt stand, or pre-fill it, and write down which and why.
4. Turn off collection you do not use. On BTCPay that is one checkbox for the refund email. On a hosted gateway it is whichever optional fields your integration populates out of habit.
5. Ask about thresholds before a large cart, not after. If you sell above a few thousand dollars on a regulated processor, get the current buyer-verification threshold in writing.

Two neighbouring questions change the picture once the money has moved rather than before: how gateways screen inbound payments decides whose coins get looked at, and what your API credentials can do decides who else could read the records you just created.

FAQ

Does my customer need KYC to pay me in crypto?

On eight of the ten gateways we read, no — the buyer picks a coin and sends it. BitPay is the exception that can ask: its terms say "Shoppers and Donors may be required to complete a verification process at the time of payment", depending on the amount. Binance Pay is the exception by design, because the payment happens inside the Binance app, so your customer already holds a verified account with Binance.

What customer data does a crypto payment gateway collect?

Three different things, and they are worth keeping apart. Whatever your server sends on the API call, which is optional everywhere we looked and is the largest surface. Whatever the hosted page asks your buyer for, which only Plisio documents doing. And whatever the provider records because a browser visited it — IP address, user agent, cookies — which BitPay, CoinGate and Blockonomics all describe in their privacy policies.

Is an email address required at crypto checkout?

Only on Plisio, and only by default: "Before paying an invoice, your client will be asked to enter an email", which you can suppress by pre-filling the field. BTCPay Server also asks for one by default as a refund address, and that is a checkbox in Checkout Experience. Everywhere else the email parameter exists and is optional, so whether it is collected is your integration's decision.

Can a crypto gateway see my customer's name?

If you send it. CoinGate's order API accepts a shopper first name, last name and date of birth; Binance Pay accepts a buyer name, phone and email; OpenNode accepts a payer name. All are optional and none is populated unless your integration populates it, which is why reading one outgoing request is the first thing to do.

Which crypto payment gateway is best for customer privacy?

Self-hosting is the only answer that removes the third party: BTCPay Server's own documentation says "there is no way to collect Buyer Information using the BTCPayServer interface", and the one default prompt is a refund email you can switch off. Among hosted gateways, BlockBee and Cryptomus document no buyer field at all, so the thinnest possible request is also the complete request.

Do crypto checkout pages use cookies?

Some say so plainly. BitPay's policy says it "may collect information about your activities on our Sites via first and third-party cookies", and Blockonomics says "we or companies we work with may place cookies on your computer or other devices". Most integration docs do not mention cookies at all, which is a gap in the documentation rather than evidence there are none — load the hosted page and look if it matters to you.

How long does a crypto gateway keep my customers' data?

Two of the ten publish a period. CoinGate keeps identity data, including "beneficiary identity data", "for up to 8 years from the date of the end of the business relationship with the client", and up to 10 years where it needs to protect legal interests. BitPay says it retains data "as required or permitted by law" and may hold identification "for 5 years or more" after an account closes. The other eight publish no buyer-specific retention period in their integration documentation.

Sources

Primary documentation, terms and privacy policies, read 18 October 2026:

• CoinGate — Create order API reference (shopper object: email, IP, name, date of birth, residence country)
• CoinGate — Privacy policy (payees' information, shoppers as data subjects, 8-year retention)
• Binance Pay — Create Order V3 (buyer object, orderClientIp, cookieId, shipping fields)
• Binance Pay — Introduction ("Users open Binance APP and scan QR Codes")
• Plisio — Create an invoice (buyer email prompt and the pre-fill opt-out)
• BitPay — Privacy policy (IP addresses used to view the invoice, cookies, retention)
• BitPay — Terms of use (§4.3 verification at time of payment; §10.4.1 email/SMS notices)
• BitPay — BitPay ID announcement (1 Aug 2019: $3,000 purchaser and $1,000 refund thresholds, "subject to change")
• BTCPay Server — Stores FAQ ("Requires a refund email"; no buyer-information collection)
• BTCPay Server — Forms (Address and Email forms, receiptData mirror fields)
• BlockBee — Checkout payments (parameter list with no buyer field)
• Cryptomus — Creating an invoice (additional_data "not shown to the client")
• OxaPay — Generate invoice (payer email "for reporting purposes")
• OpenNode — Create charge ("Payer's name", "Payer's email", notify_receiver)
• Blockonomics — Privacy policy (no direct relationship with end users; retains a copy)