What shopper data does a cross-border checkout need?

A cross-border checkout needs the shopper's name and email on every rail, plus the fields that rail uses to match and screen the payment. On BlindPay that means a CPF or CNPJ for Pix, a CUIT or CUIL for Argentine transfers, and full payer details for PSE in Colombia. SPEI and US bank rails need no extra payer fields.

This guide lists every field per rail as of October 2026, why each one exists, and what to store. For the screens that show these fields, read bank transfer checkout UX. For the whole flow, start with what is a global payments checkout.

Key takeaways

• Pix needs the payer's CPF (11 digits) or CNPJ (14 digits), validated against Receita Federal check digits when the quote is created.
• Argentina's Transfers 3.0 needs a CUIT or CUIL, the tax id BlindPay uses to match the incoming transfer.
• PSE in Colombia needs six fields: full name, document type (CC or NIT), document number, email, phone, and bank code.
• SPEI, ACH, wire, and RTP need no payer rules on BlindPay. The US rails rely on a memo code to match the deposit.
• Baymard counts a too long or complicated checkout as a reason 17% of US shoppers abandon, so ask for each field only when the chosen rail needs it.

Which payer fields does each rail need?

Each local rail identifies the payer differently, so the form changes with the rail the shopper picks.

The fields go in payer_rules on the payin quote. Two formats get checked strictly. CPF and CNPJ must pass the Receita Federal check digits, so an invalid number fails at quote time, not hours later at the bank. The PSE phone must be +57 plus the national number, and the full name is capped at 50 characters.

Collect name and email for every rail anyway. You need them for receipts, support, and refunds, even where the rail itself does not.

Why does each field exist?

The fields do two jobs: they match a deposit to the right order, and they let the provider screen who is paying.

Matching. Bank transfers are push payments. The shopper sends money from their own bank app, and the provider has to know which order it belongs to. A tax id allowlist (Pix, Transfers) or a memo code (US rails) is how the deposit finds its payin. Without it, an unmatched deposit sits in limbo until someone reconciles it by hand.

Screening. Regulated providers check the parties to a payment against sanctions lists such as the OFAC SDN list before money moves on. Payment messages also carry more originator and beneficiary data since the FATF Recommendation 16 update of June 2025. A real name and tax id make that screening accurate. A fake one makes it fail.

Who this is for: product, engineering, and compliance teams designing the payer step of a checkout that accepts Latin American and US bank transfers.

How do you collect payer data without losing the sale?

Ask late, ask little, and validate in the browser.

1. Pick the rail first. Show the country and rail picker before any form, so a Mexican shopper never sees a CPF field.
2. Prefill. Carry name and email over from the cart or the merchant's customer_email.
3. Validate locally. Run the CPF, CNPJ, and CUIT check digit math in the browser and show the error inline before the quote is requested.
4. Explain the field. One line next to each tax id: "Your bank needs your CPF to send a Pix to a business."
5. Localize. Label fields in the shopper's language. Stripe's localization guide recommends the local language for field labels, error messages, and buttons.
6. Quote, then confirm. Create the payin quote only after the fields pass, then show the local amount and a confirm button.

The cost of a long form is measurable. Baymard's abandonment research lists "too long or complicated checkout process" at 17% and "the site wanted me to create an account" at 18% among US shoppers who left. Each extra field needs a reason.

What happens when the data is wrong?

The payment fails early, or it waits for review. Both are better than a silent mismatch.

• Invalid CPF or CNPJ. The quote request fails. Show the error under the field and let the shopper fix it.
• A Pix from a different taxpayer. The allowlist names who may send. Tell shoppers to pay from an account in their own name.
• A late Argentine transfer. If funding for a Transfers payin arrives after it was marked failed and no stablecoins were sent yet, BlindPay revives it and completes it once it matches the sender's tax id and amount.
• A screening match. The payin goes to on_hold for manual review. Show "Your payment is being reviewed", not "failed".

The Travel Rule in an automated workflow covers how holds, returns, and rejections play out on the payout side.

What shopper data should you store?

Store what you need to reconcile, refund, and answer an audit, and nothing you collected only to pass a form.

• Keep with the payment record: payer name, email, tax id, rail, local amount, and the BlindPay payin id.
• Keep out of logs and analytics: tax ids, phone numbers, and document numbers. Mask them in support tools.
• Set a retention period with your counsel, and delete on schedule.
• Use the payin id for receipts. BlindPay's public tracking endpoint, GET /v1/e/payins/{id}, needs no API key and returns the payer's name and tax id, so share a receipt link only with the payer.

Privacy law varies by country, including Brazil's LGPD. Confirm your collection and retention rules with your compliance counsel.

How does BlindPay handle shopper data at checkout?

BlindPay asks for payer data only where the rail needs it, and checks it before money moves.

• Per-rail payer rules on the payin quote: CPF or CNPJ for Pix, CUIT or CUIL for Transfers 3.0, the six PSE fields for Colombia, and none for SPEI, ACH, wire, or RTP.
• Validation at quote time, including Receita Federal check digits on CPF and CNPJ, so bad data fails before the shopper pays.
• Screening in the payment flow, with a match sending the payin to on_hold instead of completing it.
• One record per payment, with statuses processing, on_hold, completed, failed, and refunded, plus payin.new, payin.update, and payin.complete webhooks.

Your checkout owns the form and the copy. BlindPay owns the checks and the deposit matching. For the Pix-specific flow, see how to accept Pix payments from abroad.

Methodology and sources

BlindPay facts come from the payin quotes, payins, and cut-off times docs, read in October 2026. External sources: Baymard's cart abandonment research, Stripe's payment localization guide, the OFAC SDN list, and the FATF Recommendation 16 update. This is not legal advice.

What to do next

List the rails you plan to show, then copy the payer fields table into your form spec, one rail per column. Build the rail picker first, and test an invalid CPF on a development instance to see the quote error your shoppers will get.