> ## Documentation Index > Fetch the complete documentation index at: https://waffo.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Can I Send Shopper Details So the Checkout Doesn't Ask Again? > Trusted shopper data on the Waffo checkout: exactly which nine fields can be pre-filled from your order request, why the form still appears, which value wins when the shopper edits it, why a national ID such as CPF is not one of them, and how the configuration is scoped and requested. If you already hold a shopper's name, email or address, you can have the Waffo checkout arrive **pre-filled** with what you sent instead of showing empty fields. This page is about exactly what that does and does not change. Adjacent pages: which order fields a payment method makes mandatory in the first place is in [Conditional & Required Fields](/docs/en/support/conditional-required-fields-faq); what the checkout form looks like and how it is styled is in [Checkout Forms & Flow](/docs/en/support/cashier-forms-and-flow-faq). ## Which shopper fields can be treated as trusted? Nine, and the list is fixed: | Field | What it is | | - | - | | `userEmail` | Shopper email | | `userFirstName` | Given name | | `userLastName` | Family name | | `userPhone` | Phone number | | `address` | Street address | | `city` | City | | `region` | State / province / region | | `postcode` | Postal code | | `addressCountryCode` | Country of the address | Nothing outside those nine can be trusted, however the checkout collects it. That is a hard boundary of the mechanism, not a per-method setting. ## Can a national ID such as CPF be trusted so the shopper doesn't retype it? No. Identity-document numbers are not among the nine fields, so there is no configuration that makes the checkout accept a CPF (or any other national ID) from your order request in place of asking the shopper. If the payment method requires the document number, the shopper enters it on the checkout. This is the same answer for a bank-transfer voucher method, a wallet, or a card-based method — the field list does not vary by payment method. You can still send a document number on the order for the payment itself (`paymentInfo.payMethodProperties` carries `cpf` for methods that need it) — but sending it is not the same as the checkout treating it as trusted and skipping its own collection. ## Does trusting a field remove the collection step? No. It fills the field in; it does not remove it. The checkout decides whether to render a form purely from **which required fields exist** for the chosen payment method — not from whether those fields already have values. So on a method that requires an email, a trusted email means the shopper sees the email field already filled with your value. It does not mean the shopper goes straight to paying. What you get, then, is fewer keystrokes and fewer typos, not a shorter flow. If your goal is "no form at all", the lever is the payment method (a method with no required fields renders no form), not the trusted-field configuration. ## The shopper edited the value I sent. Which one is used? The shopper's. What they submit on the checkout is the value the payment is made with, and it is also written back as the trusted value for the order — so an order inquiry afterwards reflects what the shopper actually entered, not what you originally sent. The full precedence, highest first, for the value shown in a checkout field: | Priority | Source | | - | - | | 1 | What the shopper submitted on a previous attempt at this same order and payment method | | 2 | A value the shopper has used before on your account, if you have that feature enabled | | 3 | Your trusted value from the order request | | 4 | Empty | Two things follow. First, a shopper retrying a payment sees their own last input, not your trusted value — that is deliberate, because their correction is newer information than your record. Second, if you are reconciling shopper details against your own CRM, read them back from the order rather than assuming your submitted values survived. ## I send placeholder values for some fields. What happens when trust is enabled? They reach the shopper. A trusted field is passed through as-is: nothing validates it against reality, and nothing detects that an address or an email is a placeholder. The shopper simply sees your placeholder pre-filled in the form. For a field the payment method requires, the practical outcomes are: * The shopper notices and corrects it — the flow works, but you gain nothing. * The shopper does not notice and submits the placeholder — the payment can be attempted with an unusable email or address, and anything downstream that depends on it (a receipt, a voucher, a refund that needs the shopper's details) inherits the bad value. So before enabling trust on a field, check that the field is genuinely populated with real data in every order you send. Enabling trust on a field you fill with a placeholder is worse than not enabling it: without trust the shopper is *forced* to supply a real value. ## Can I enable it for some payment methods only? No. The configuration is a list of trusted fields held **against your merchant account**, and it applies to every order that account creates, on every payment method that asks for one of the nine fields. There is no per-payment-method, per-market or per-product dimension to it. If you need one method to keep collecting a field afresh while another accepts your value, that is not expressible in the current configuration. What *is* per-order: you can simply not send the field. A trusted field with nothing behind it on a given order falls through to priority 4 above — the shopper gets an empty field and fills it in. So "trust my email, except on these orders" is achievable by omitting the email on those orders; "trust my email on this payment method only" is not. Sub-merchant scoping follows the same account boundary — see [Multi-Brand & Sub-Merchants](/docs/en/support/multi-brand-and-sub-merchant-faq). ## How do I get it configured? Can I change it myself in the Portal? There is no Portal screen for it. The trusted-field list is set on the Waffo side, so it goes through your integration contact: say which of the nine fields you want trusted, and confirm that you send real values for each of them on every order. Because the setting is account-wide and takes effect on the next order, treat a change as a release: verify in the sandbox that your orders carry the fields you are about to have trusted, then ask for the production change. See [Sandbox & Testing](/docs/en/support/sandbox-testing-faq). ## Where do I look next? * [Conditional & Required Fields](/docs/en/support/conditional-required-fields-faq) — which fields a payment method makes mandatory, and what happens when one is missing * [Checkout Forms & Flow](/docs/en/support/cashier-forms-and-flow-faq) — what the shopper sees, step by step * [Order Creation Field Guide](/docs/en/support/order-create-field-guide) — where `userInfo` and `addressInfo` sit on the request * [Checkout Display Rules](/docs/en/support/cashier-display-rules-faq) — how payment methods are ordered and grouped This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.