Product overview

What GrinGo Pay does

GrinGo Pay lets a UK or EU tourist pay for anything in Brazil — a taxi, a restaurant bill, a market stall — by scanning a PIX QR code with their phone. The tourist funds the app with a bank transfer in GBP or EUR from their normal bank; that balance sits at a regulated payments partner (Infinia) and is converted to BRL at the exact moment of payment.

~15–20 seconds at the till. Fast enough to feel like Revolut, not like a crypto payment.

Who it's for

• UK and EU travellers to Brazil who don't want to carry cash, get gouged on card FX fees, or install a Brazilian bank app.
• Digital-savvy consumer users who expect the app to work like a normal fintech (Revolut, Wise, Monzo) — no seed phrases, no wallet addresses, no "connect your web3 wallet" prompts.

Supported markets (MVP)

MVP is UK + EU-27 senders only. Deposit in GBP via FPS or EUR via SEPA; withdraw back to a UK / EU bank in the same currency; pay Brazilian PIX in between.

We deliberately narrow at launch because Infinia has full deposit + withdraw coverage on those rails today. Expansion is gated on rail parity — see roadmap § Geographic scope for the phased plan. US, Singapore, and LatAm sender markets are on the roadmap; US is specifically gated on Infinia adding US to their payouts endpoint (otherwise US users would have deposit access but no way to withdraw a leftover balance, which is a worse UX than not supporting them yet).

Country allowlist is enforced post-KYC — if Infinia's verified identity returns an address in an unsupported country, we reject account provisioning. See flows/onboarding § country allowlist.

What the user experiences

1. Sign up with Sign in with Apple or Google. No password, no email verification step.
2. Complete a one-time KYC — document + selfie inside a hosted verification widget. Handled by Infinia.
3. See a UK sort code + account number (or an IBAN for EUR) — the user's Infinia virtual account in their own name.
4. Send £100–£500 from their bank to that account. It shows up as their GBP balance in the app.
5. In Brazil: tap Pay PIX, scan a QR, see a locked-rate price ("R$500 = £77.10, rate locked 60s"), confirm, done. Payment settles at the merchant in ~15–20s.
6. Withdraw any remaining balance back to their bank at the end of the trip.

What GrinGo does not do

• No custody of funds. User balances live at Infinia (regulated third party). GrinGo has no operational treasury, no signing keys, no ability to move funds without triggering an Infinia API call attributable to the user.
• No KYC document handling. Documents and selfies go directly to Infinia's hosted widget. We only ever see the result of verification (name, DOB, address, gov ID number), which we store encrypted at rest.
• No crypto for the user. No wallet, no seed phrases, no gas, no Base chain, no balance to think about in anything but pounds and euros. Infinia does use a per-user USDC account internally as a transient settlement pivot for the PIX conversion (see how-it-works), it is normally funded and drained inside a single payment, never surfaced to the user, and excluded from balances (the one exception: if the USDC→BRL leg definitively can't complete, the payment auto-unwinds — the USDC is reversed back to the user's home currency and refunded — so it may briefly transit the user's own USDC account across a payment; still never shown to the user). The previous architecture put USDC in the user's own on-chain wallet — that is what the current model removes. If the market ever demands user-held crypto, the escape hatch is documented.
• No card issuance, no P2P transfers between users, no merchant-side onboarding. Not in MVP scope.

Why this shape

Design choices in order of consequence:

1. Fiat held at a regulated custodian (Infinia), not on-chain in a user wallet. The trade-off analysis lives in custody-model. Short version: at point-of-sale, ~15–20s beats ~35s by a margin that changes whether the product is usable at a merchant terminal.
2. Native OAuth for auth, not a bundled auth-plus-wallet vendor. Fewer moving parts, no wallet UX in a fiat app, zero auth vendor bills.
3. Infinia HOSTED KYC — Infinia's own hosted widget (SumSub-powered), which absorbs biometric data collection so it never enters our systems. One vendor bill.
4. Two-leg FX at payment time — Infinia offers no direct GBP/EUR→BRL pair, so the conversion routes GBP/EUR → USDC → BRL through a per-user USDC pivot account: two internal transfers, two FX quotes, two spreads, all inside Infinia. The USDC leg is an invisible internal settlement step — the user never sees or holds it. (Being rolled out behind the USDC_ACCOUNTS_ENABLED flag.)

See how-it-works for the mechanical detail.

Fee model

Flow	Infinia fee	GrinGo fee	Notes
Deposit	TBC	0%	Infinia's deposit fee (if any) shown as the delta between sent and credited amount.
PIX pay	Bundled in Infinia FX spread	~2.0% (200 BPS)	GrinGo margin is the delta between the composed two-leg (GBP/EUR→USDC→BRL) rate Infinia gives us and the rate we show the user.
Withdraw	TBC	0%	GBP/EUR return to user's own bank, no FX involved.

Concretely: on a £500-equivalent PIX payment the GrinGo margin is roughly £6.25. See packages/shared/src/pix/pricing.ts for the pricing math (DEFAULT_GRINGO_SPREAD_BPS = 200).

Infinia's exact fee schedule is one of the open questions we're tracking — once known, we may revise the GrinGo spread to hit a target margin net of Infinia fees.

What's next

See the roadmap for post-MVP work.