Repository navigation
TASK-22425 feat: enable send -> bank -> Brazil -> Pix key sends - #3055
Conversation
The send->bank country list gated on bridge support only, so Brazil sat disabled behind a soon badge even though the PIX-key send flow (Manteca QR-payment endpoint) already pays another person's key. Enable Brazil in that list and route it to method=pix, which delegates to PixKeySendView. bank-transfer stays the route for the other Manteca countries: it is the own-account offramp. Argentina stays gated, same ruling that keeps Mercado Pago off the send list (PR #2813).
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Code-analysis diffPainscore total: 7297.09 → 7297.33 (+0.24) 🆕 New findings (7)
✅ Resolved (6)
|
🧪 UI test report — ✅ all greenSuites
📊 Coverage (unit)
⏱ 10 slowest test cases
|
|
/chip review |
🖼 Visual diff — 6 screens moved8 of 68 shots changed · 60 identical · baseline
job summary · before/after/diff images — artifact Fixture screenshots, no backend. Advisory — this check never blocks a merge. Posted from the default branch by ds-shots-comment.yml; the report it renders is untrusted data. |
![chip-peanut-bot[bot]](https://avatars.githubusercontent.com/in/2915219?s=60&v=4){kind=small}
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
Brazil is enabled only in the send-to-bank country gate and is routed into the existing Pix-key payment flow; Argentina and unsupported countries remain disabled, and downstream payment eligibility is still enforced.
Findings
- MAJOR · src/components/Common/CountryList.tsx:207 · [claude-opus] Send→bank→Brazil promises third-party PIX-by-key sends that product truth says we do not offer
What changes for users:CountryList.tsx:207makes Brazil selectable in the send→bank country list (enforceSupportedCountriesis set only forisBankFromSend, AddWithdrawRouterView.tsx:366), andAddWithdrawRouterView.tsx:386routes it tomethod=pix, whichapp/(mobile-ui)/withdraw/manteca/page.tsx:95delegates toPixKeySendView— an input for any person's PIX key, handed to/qr-pay. So the app now advertises Brazil as a 'send to a bank' destination and accepts an arbitrary third party's chave PIX.
Product truth disagrees on three counts:
product/countries.mdBrazil entry:third_party_payout: false, note "First-party only, same rule as Argentina above" (Argentina's note: "Third-party payouts exist on the Bridge rails only (EU, US, MX, UK)"). Brazil is now a fourth, non-Bridge, third-party payout destination.product/spending.md:38and:243: "Pix QR scan for merchant payments. To send funds to a person, use a Peanut Link" / "To send money to someone in Brazil, share a Peanut Link." The new entry point is exactly send-to-a-person-by-PIX-key.product/feedback/problems/pix-direct-payment-broken.mddecision log: "2026-04 · disabled by compliance, no date to re-enable", plus the 2026-07-04 note "PIX by cellphone/CPF/email/CNPJ temporarily DISABLED". Nothing in product/ records that ruling being reversed.
Audience also widens. The pre-existing PIX-key entry point (SendRouter.view.tsx:101) is shown only to users geolocated in Brazil (useGeoFilteredPaymentOptions.ts:48). The country list applies no residence filter, so this path reaches every user; the only downstream gate is capability-based (canDo('pay', { provider: 'manteca' })). Product does sanction geo-agnostic QR pay ("Any account verified with Manteca can pay Pix QR codes, regardless of residence"), but the same file records the opposite for keys: "non-Brazilians can only pay PIX by scanning a merchant QR, not by direct transfer to a PIX key."
Which is wrong: I can't confirm from the repos that the 2026-04 compliance disable was lifted. If TASK-22425 carries that sign-off, product/ is the stale side and must be updated before this ships — countries.md (third_party_payout carve-out for the QR-rail PIX-key send), spending.md:38/243, and the pix-direct-payment-broken decision log — otherwise support answers generated from product/ will keep telling Brazilian users "own account only / use a Peanut Link" while the app offers the opposite. If the disable still stands, the gate change is the wrong side and Brazil should stay off the send→bank list.
Checked clean
- Pinned detached checkout, merge base, trusted author, dev base, and exact PR head all match the supplied values.
- CountryList enables Brazil only when the send-to-bank supported-country gate is active; Argentina remains disabled and Bridge countries remain selectable, with focused regression coverage.
- Brazil selection routes to /withdraw/manteca?method=pix&country=brazil, which delegates to PixKeySendView and the shared Pix-key-to-BR-Code handoff.
- The destination /qr-pay flow independently enforces the Manteca pay capability and region restriction before payment initialization, so this UI gate change does not bypass payment authorization.
- The live Lexicon identifies Pix as Brazil's local payment rail, and TASK-22425's binding scope and definition of done match the implemented Brazil-only routing change.
- All exact-head CI checks completed successfully or were intentionally skipped, including unit, typecheck, lint, format, native export, design-system checks, preview deployment, provenance, and advisory screenshots. Local focused tests were unavailable because the detached checkout has no installed dependencies.
Security review by moonshotai/kimi-k3: 0 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion by claude-opus: 1 finding(s), marked with the model name. It answers only product truth, missing tests and the cross-repo contract, so treat its findings as advice.
Exact head: 21b9c6739c62 · Context: repo, product · Took 14m
|
Re the Product truth is the stale side here. Evidence:
The stale product/ + content/ pages (countries.md |
There was a problem hiding this comment.
Chip review — no blocking findings — this is not an approval
The routing is internally consistent and CI is green, but enabling Brazil for every send-to-bank user conflicts with the current product and compliance rules for direct Pix-key transfers.
Findings
-
MAJOR · src/components/Common/CountryList.tsx:207 · Brazil Pix-key sends bypass the documented audience restriction
enforceSupportedCountriesis used by the send-to-bank flow without a residence filter, so this line makes Brazil selectable for a non-Brazilian user and the new route sends their arbitrary Pix key through/qr-pay. Current product truth distinguishes geo-agnostic merchant QR payments from direct key transfers:product/countries.mdmarks Brazil third-party payouts as unsupported,product/spending.mddirects person-to-person sends to Peanut Links, andproduct/feedback/problems/pix-direct-payment-broken.mdrecords Pix-by-key as compliance-disabled. Keep Brazil gated unless that decision has been reversed; if TASK-22425 carries approval, update those canonical rules and encode the approved audience before shipping so the app and support guidance agree. -
MINOR · src/components/Common/CountryList.tsx:207 · [claude-opus] Third-party Brazil Pix sends contradict product truth (Bridge-only third-party payouts)
This PR makes Brazil selectable in the send→bank country list and routes it tomethod=pix→ PixKeySendView →/qr-pay, i.e. paying another person's Pix key from the Peanut balance. Product truth says the opposite in three places: -
product/countries.md(brazil):third_party_payout: false, note "First-party only, same rule as Argentina above"; the Argentina note it inherits says "Third-party payouts exist on the Bridge rails only (EU, US, MX, UK)". -
product/networks.md:direct_bank_transfers.regions: [united-states, europe, mexico, united-kingdom], and §"Direct Bank Transfers (Third-Party)" — "available in the EU, US, Mexico, and the UK via Bridge". -
product/spending.md:38and:243: "Pix QR scan for merchant payments. To send funds to a person, use a Peanut Link" / "To send money to someone in Brazil, share a Peanut Link".
The code is what's right here — the PR title states this is the intended capability, and the QR rail genuinely is geo-agnostic and pool-settled, so the flow is coherent. Product/ is what's now stale. The cost of leaving it is customer-facing: support answers and generated pages are produced from these files, so they will tell a Brazilian user to use a Peanut Link for a person-to-person Pix send that the app now offers directly, and networks.md's third-party region list will omit Brazil.
Fix: update product/countries.md (brazil — distinguish the first-party PIX_BR offramp rail from third-party Pix-key sends over the QR/pool rail), product/networks.md (the third-party send section and regions), and product/spending.md:38,243 via the update-content path. Note the split explicitly, since the same file's Argentina entry stays first-party-only and the PR deliberately keeps Argentina gated.
Checked clean
- Pinned detached checkout, merge base, trusted author, dev base, and exact PR head all match the supplied values.
- Brazil selection routes to /withdraw/manteca?method=pix&country=brazil, which delegates to PixKeySendView and the shared Pix-key-to-BR-Code handoff.
- The destination /qr-pay flow retains its existing Manteca pay-capability and region-restriction gates; no API contract or payment implementation changed.
- The existing direct Pix entry is geo-filtered to Brazil, while the changed send-to-bank country list has no equivalent residence filter and therefore widens the audience.
- TASK-22425 requests the widened flow, but the current canonical country, spending, and Pix compliance records do not record a reversal of the direct-key restriction.
- All exact-head CI checks completed successfully or were intentionally skipped, including unit, typecheck, lint, format, native export, design-system checks, preview deployment, provenance, and advisory screenshots. Local focused tests were unavailable because the detached checkout has no installed dependencies.
Security review by moonshotai/kimi-k3: 0 finding(s), marked with the model name. It reads the diff only and answers only security, privacy and money, so treat its findings as advice.
Third opinion by claude-opus: 1 finding(s), marked with the model name. It answers only product truth, missing tests and the cross-repo contract, so treat its findings as advice.
Exact head: 21b9c6739c62 · Context: repo, product · Took 8m
Summary
Send → Send to friends → Bank showed Brazil disabled behind a "soon" badge: the country list's
enforceSupportedCountriesgate only accepted Bridge countries. The Pix-key send flow already pays any third-party Pix key (Manteca QR-payment endpoint,PixKeySendView), so the gate blocked a path the product supports. This PR enables Brazil in that list and routes it tomethod=pix.CountryList.tsx: the send→bank gate now accepts Bridge countries plus Brazil. Argentina stays disabled — its Manteca rails in this flow are own-account offramps, same ruling that keeps Mercado Pago off the send list (feat: design system release #2813).AddWithdrawRouterView.tsx: the send→bank Manteca branch routes Brazil to/withdraw/manteca?method=pix&country=brazil(delegates toPixKeySendView);bank-transferstays for the rest.Task
TASK-22425
Risks / breaking changes
canDo('pay', { provider: 'manteca' })) is enforced downstream in/qr-pay, same as the existing Brazil-geo entry points.?method=bankmarker is dropped on the Brazil hop, same as the existing Mantecabank-transferhop;PixKeySendView's back navigation targets/sendalready.QA
npm test— 524 suites green, incl. new tests:CountryList.test.tsx: underenforceSupportedCountries, Brazil selectable, Argentina disabled, Bridge country (Germany) selectable.AddWithdrawRouterView.test.tsx: send→bank Brazil click pushes/withdraw/manteca?method=pix&country=brazil.Design notes / accepted trade-offs
'brazil'literal appears twice (the CountryList gate and the AddWithdrawRouterView route). The two sites encode different decisions — which countries the send→bank list offers vs which Manteca method a country routes to — so a shared constant would couple them without making either clearer. If a second Manteca send country lands, promote a map inmanteca.conststhen.Screenshots
375×667, dev build with the
withdrawfixture (API faked). Assets branchpr-assets-3055is deleted post-merge.Click-through verified live: tapping Brazil lands on
/withdraw/manteca?method=pix&country=brazil(the "Send with Pix" key-entry screen).