Collecting customer data at checkout: ask for less, collect the rest on demand

Checkout forms tend to grow towards the strictest provider they will ever use. One local method needs a tax ID, one acquirer wants a phone number, and a third provider asks for a full address, so every field ends up on the form for every customer. A shopper in Germany paying by card then scrolls past fields meant for a shopper in Brazil paying with Pix.

This article sets out which details providers and local methods really need, why asking for all of them up front costs conversions, what data minimisation requires, and how to start with the minimum and collect the rest only when a provider asks. For local field formats, see our guide to checkout localisation. For the design of the form itself, see checkout form design.

Which customer details do providers really need?

It depends on the method, then on the provider. The table shows what published documentation asks for today. Treat it as a starting point: each provider keeps its own list, and these lists change.

Method	What the documentation asks for	Source
Cards	Card number, expiry and CVC. Postal code and billing address allow verification. Cardholder name plus phone or email for Visa 3-D Secure	Stripe, Visa
Apple Pay and Google Pay	The wallet holds the card. Google Pay returns name, country and postal code by default if you request a billing address. Stripe says wallets do not need a CVC check	Google, Stripe
Pix, Brazil	Name, email, CPF or CNPJ	Stripe
Boleto, Brazil	Name, email, CPF or CNPJ, street address, city, state, postal code	Stripe
OXXO, Mexico	Full name and email	Stripe
Mobile money in Ghana, Kenya and Côte d’Ivoire	Mobile money number and chosen network	Paystack
Payments in Colombia	Document number, with a type such as CC, NIT or CE	EBANX

Two things stand out. First, no single customer needs all of this. Second, the list can change within one country: moving from Pix to Boleto on Stripe adds four address fields. A form built as the sum of every requirement asks a customer with Apple Pay for details the wallet already holds.

The lists also differ by provider, not only by method. EBANX says the document field is required for payments in both Colombia and Brazil. Another provider for the same method may ask for something else. That is why a field list written once, for one provider, goes out of date when you add a second.

Why does asking for everything up front cost conversions?

Every extra field is work the customer has to do before paying. Baymard Institute found that the average checkout flow in 2024 contained 11.3 form fields, down from 11.8 in 2021 and 12.7 in 2019, and says most sites need only 8. Its advice is to focus on how many fields users must review, not only on how many steps the checkout has.

Shoppers say the same thing when asked why they left. In Baymard’s data on US online shoppers who abandoned for reasons other than browsing, 17% blamed a checkout that was too long or complicated, and 19% did not trust the site with their card details. An unexplained request for a national ID number on a foreign website touches both problems at once.

Google’s Pay documentation makes the point directly. It says a billing address should be requested only if it is required to process the transaction, and warns that asking for more adds friction and can lower conversion. Its default billing format returns only name, country and postal code.

Forced fields also produce bad data. A customer who sees no reason for a field may type anything that passes it. Visa Acceptance Solutions advises against sending dummy values in 3-D Secure requests, because accurate cardholder data is what helps issuers decide. A field you did not need, filled with a false value, is worth less than no field.

Which data is still worth asking for on every card payment?

Minimal does not mean empty. Some fields pay for themselves, and removing them can cost more than they save.

• CVC and postal code. Stripe recommends collecting both to avoid declines from suspected fraud, and says the impact of other data, such as the full billing address, varies by card brand and country.
• Billing address, where it can be checked. Stripe says support for address verification varies by country and issuer, and that most cards issued in the United States, Canada and the United Kingdom support street address checks. Our AVS glossary entry covers the results.
• The 3-D Secure fields. Visa’s rules for standard Visa Secure payments require the cardholder name and a phone number or email in every authentication request, plus the browser IP address and screen size, or the device IP address in apps. Visa adds that these minimums do not apply where local privacy rules prohibit sharing a field, and it still recommends sending all 12 of its priority fields.
• Evidence for disputes. Stripe warns that some disputes are lost because only the minimum information was required, which can make it hard to show the customer was genuine.

A field earns its place if it passes one of four tests. A provider cannot process the payment without it. A scheme requires it. It improves fraud decisions or dispute evidence by enough to justify the friction. Or you need it to deliver the order. Anything else should come off the form.

What does data minimisation require at checkout?

Article 5(1)(c) of the GDPR says personal data must be “adequate, relevant and limited to what is necessary” for the purposes it is processed for. Article 25(2) adds that, by default, only personal data necessary for each specific purpose should be processed, and it applies this to the amount collected, the extent of processing, the storage period and who can access the data.

For a checkout, that has four practical effects.

• Each field needs a purpose. “A provider might need it one day” is weak. “This provider requires it for this method” is strong. Asking every customer for a tax ID, when only some methods use it, is hard to defend.
• The purpose decides who you ask. A CPF has no purpose for a customer in Germany paying by card.
• Collected data needs a limit. Article 5(1)(e) says personal data must be kept in identifiable form for no longer than necessary, so a field you collect is also a retention decision.
• Saving card details is a separate choice. The European Data Protection Board says consent appears to be the sole appropriate legal basis for storing card data after a purchase just to ease later purchases. Consent should be requested through a box that is not pre-ticked, kept apart from the terms of sale, and never made a condition of the transaction. These recommendations do not cover storage for a legal obligation or for subscriptions and other continuing contracts.

This is a summary of EU law, not legal advice, and other markets have their own rules. Your data protection lead should review the flow.

There is a security argument too. Every tax ID and phone number in your database is one more item to protect, retain and delete on request. Data you never collected needs none of that.

How do you start with minimal data and collect the rest later?

The method is simple to describe. Collect in the order the payment needs it, not in the order your form was designed.

1. List fields per provider and method. Write down what each provider requires, what it merely accepts and what you use the field for.
2. Separate order data from payment data. Delivery details belong to the order. Tax IDs and network choices belong to the payment.
3. Start with what you already hold. Amount, currency, country and an email address are often enough to begin.
4. Let the chosen method decide the next fields. Show the CPF field after the customer picks Pix, not before.
5. Explain each unusual field in one line. “Required by Brazilian rules for this payment” answers the question the customer is asking.
6. Validate before you submit. Stripe’s Boleto rules, for example, require a CPF of 11 digits or a CNPJ of 14, and its OXXO rules require a first and last name of at least two characters each.
7. Reuse what you already collected. WCAG 2.2 success criterion 3.3.7 says information already entered in a process should be filled in automatically or offered for selection, not asked for again.
8. Set retention before launch. Decide how long each field stays and who can see it.

Step 4 is where most builds stop, and it hides a harder problem. With several providers behind one method, the fields depend on which provider your routing rule picks, and that choice can change by amount, country or card BIN. If a payment moves to another provider, that provider may need a field the first one did not. A form designed per method cannot know this in advance. The request has to be answered at the moment the provider asks.

How do Omno forms collect data only when a provider needs it?

Omno forms are built around that moment. You start a payment with the data you already hold, which can be very little. Your routing rule picks a provider. If that provider needs a detail your request does not carry, such as an address, a phone number or a national ID number, Omno shows the customer a short form, collects the missing fields and stores them on Omno’s side. The next payment from that customer does not ask again.

Stage	Full form up front	Omno forms
Start of payment	Customer fills in every field any provider might need	You send what you hold
Provider chosen	Fields were guessed before the provider was known	The provider’s needs are known
A field is missing	The request fails or you build a new form	Omno asks the customer for that field only
Where the data lives	In your systems	On Omno’s side
Next payment	You must store and prefill it	The customer is not asked again

The idea has three effects that matter to a merchant.

Customers see only what their payment needs. A customer whose provider needs nothing extra sees no extra form. The tax ID question reaches the customer it applies to, at the point it makes sense.

Your team stops maintaining field lists in code. You do not build a form per provider, and a provider changing its requirements does not mean a release. Adding a provider becomes configuration.

Less personal data sits in your systems. You never build these forms and never keep this data, so tax IDs and phone numbers stay out of your database. That supports a smaller data footprint, though it does not end your duties: your privacy notice still has to describe the collection, and your contracts should set out each party’s role.

The forms are part of the hosted checkout. The data then appears on the customer profile, alongside the customer’s payments.

Two limits are worth stating. Omno does not run KYC, so a detail collected for a payment is not identity verification. And connecting to Omno does not onboard you with a provider, because each provider onboards you separately.

What are the common mistakes?

• Copying the strictest provider’s list onto the main form. One provider’s requirement becomes every customer’s problem.
• Asking before the customer has chosen a method. A tax ID makes little sense until the method that needs it is selected.
• Removing fields that protect you. Dropping the CVC or postal code to shorten a form can cost more in declines than it saves.
• Asking twice. A returning customer who is asked again for a CPF has every reason to doubt the site.
• Keeping data with no plan. A field added for one provider often outlives that provider. Review the list when providers change.
• Treating a format check as verification. A valid-looking tax ID is not proof of identity.

How does Omno handle customer data at checkout?

Omno lets you start a payment with minimal customer data, then uses Omno forms to collect what a provider needs and stores it, so you never build those forms or keep that data. The hosted checkout page shows how forms, fields and methods are set up without a release.