---
title: "What shopper data does a cross-border checkout need?"
seoTitle: "What shopper data a cross-border checkout needs (2026)"
description: "The payer fields a 2026 cross-border checkout collects per rail: CPF or CNPJ for Pix, CUIT for Argentina, PSE details for Colombia, and why each exists."
date: "2026-10-27"
updated: "2026-10-27"
category: "compliance"
author: "BlindPay Team"
faq:
  - q: "What information does a shopper need to give at a cross-border checkout?"
    a: "It depends on the rail. A name and email are the baseline. Pix in Brazil also needs the payer's CPF or CNPJ, Argentine bank transfers need a CUIT or CUIL, and PSE in Colombia needs full name, document type and number, email, phone, and bank. SPEI in Mexico and ACH, wire, or RTP in the US need no extra payer fields on BlindPay."
  - q: "Why does a Pix checkout ask for a CPF?"
    a: "The CPF or CNPJ tells the provider which taxpayer is allowed to send that Pix, so the deposit can be matched to the order and screened. On BlindPay it goes in pix_allowed_tax_ids on the payin quote, and it is validated against the Receita Federal check digits at quote time, so a typo fails before the shopper opens their bank app."
  - q: "Does a cross-border checkout have to screen shoppers against sanctions lists?"
    a: "Regulated payment providers screen the parties to a payment against sanctions lists such as the OFAC SDN list, and the data you collect feeds that check. On BlindPay, screening runs in the payment flow, and a match sends the payin to on_hold for review. Your counsel decides whether your own business has separate screening duties."
  - q: "Should I store the shopper's tax id after the payment?"
    a: "Store only what you need to reconcile, refund, and answer an audit. The tax id and name tie a deposit to an order, so most teams keep them with the payment record under access controls and a retention period. Avoid copying them into analytics, logs, or email. Ask your counsel about local privacy rules such as Brazil's LGPD."
  - q: "How do I keep the payer form short?"
    a: "Ask only for the fields the chosen rail needs, after the shopper picks a country and rail. Prefill email and name from the cart, validate CPF and CUIT check digits in the browser, label fields in the local language, and show a one-line reason next to each tax id field. Baymard data shows long checkouts are a top reason people leave."
---

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](/resources/more/checkout-payment-instructions-ux). For the whole flow, start with [what is a global payments checkout](/resources/more/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.

| Rail | Country | Payer fields on BlindPay | What the field does |
| --- | --- | --- | --- |
| Pix | Brazil | `pix_allowed_tax_ids`: CPF or CNPJ | Only that taxpayer can fund the payin |
| Transfers 3.0 | Argentina | `transfers_allowed_tax_id`: CUIT or CUIL | Matches the transfer to the sender's tax id |
| PSE | Colombia | `pse_full_name`, `pse_document_type` (CC or NIT), `pse_document_number`, `pse_email`, `pse_phone`, `pse_bank_code` | Opens the payer's bank session in the PSE flow |
| SPEI | Mexico | None | The CLABE and exact amount identify the payment |
| ACH, wire, RTP | United States | None | The `memo_code` on the transfer matches the deposit |

The fields go in `payer_rules` on the [payin quote](/docs/payin-quotes). 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](https://ofac.treasury.gov/specially-designated-nationals-and-blocked-persons-list-sdn-human-readable-lists) before money moves on. Payment messages also carry more originator and beneficiary data since the [FATF Recommendation 16 update of June 2025](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/update-Recommendation-16-payment-transparency-june-2025.html). 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](https://stripe.com/resources/more/payment-localization-best-practices-a-guide-for-scaling-payments-worldwide) 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](https://baymard.com/lists/cart-abandonment-rate) 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](/resources/more/travel-rule-workflow-hold-return-reject) 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](/resources/more/accept-pix-payments-from-abroad).

## Methodology and sources

BlindPay facts come from the [payin quotes](/docs/payin-quotes), [payins](/docs/payins), and [cut-off times](/docs/kb/cut-off-times) docs, read in October 2026. External sources: [Baymard's cart abandonment research](https://baymard.com/lists/cart-abandonment-rate), [Stripe's payment localization guide](https://stripe.com/resources/more/payment-localization-best-practices-a-guide-for-scaling-payments-worldwide), the [OFAC SDN list](https://ofac.treasury.gov/specially-designated-nationals-and-blocked-persons-list-sdn-human-readable-lists), and the [FATF Recommendation 16 update](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/update-Recommendation-16-payment-transparency-june-2025.html). 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.