From 9445022680d5187b0dece6ab8dac337d003c4a74 Mon Sep 17 00:00:00 2001 From: Hugo Montenegro Date: Fri, 29 May 2026 19:20:33 +0100 Subject: [PATCH] =?UTF-8?q?kyc(EEA=20#5):=20branch=20onKycSuccess=20routin?= =?UTF-8?q?g=20on=20flow=20=E2=80=94=20fixes=20'Add=20Money'=20page=20show?= =?UTF-8?q?ing=20withdraw=20form?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `AddWithdrawCountriesList` is mounted for both add-money AND withdraw flows (`flow: 'add' | 'withdraw'` prop). Its `onKycSuccess` handler unconditionally flipped an internal view state to `'form'`, which renders `` — the offramp/withdraw bank-account input form that asks the user to enter THEIR bank account details (account holder name, IBAN, etc.). For withdraw that's correct (user tells us where to receive the money). For add-money it's the WRONG form — add-money needs to show Bridge's deposit instructions (an account belonging to Bridge that the USER wires TO). That lives in `AddMoneyBankDetails` at `/add-money/[country]/bank`. Pre-fix user flow (EEA QA bug #5): 1. User clicks Add Money, picks country 2. KYC gate blocks them; they complete Sumsub 3. `onKycSuccess` fires → `setView('form')` 4. Page renders: NavHeader "Add Money" + DynamicBankAccountForm (withdraw fields) 5. User confused — sees "account holder name" input on an "Add Money" page Fix: in `onKycSuccess`, branch on `flow`. For `flow === 'add'`, route to `/add-money/[country]/bank` (deposit-instructions page). For `flow === 'withdraw'`, keep the existing `setView('form')` (correct destination). Why this slipped past existing coverage: the initial `useState` for `view` at line 71 already guards with `flow === 'withdraw' && amountToWithdraw`, so add-money never hits `view: 'form'` on initial mount — only via the post-KYC transition. Systemic audit: NOT systemic. `AddWithdrawCountriesList` is the ONLY component used for both add + withdraw flows. Other useMultiPhaseKycFlow consumers (qr-pay, withdraw bank, MantecaAddMoney, MantecaFlowManager, BankFlowManager-claim, UnlockedRegions, KycStatusDrawer, add-money bank page) are single-flow or use empty handlers — none have the same shared-component-with-divergent-destinations gap. --- .../AddWithdraw/AddWithdrawCountriesList.tsx | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/components/AddWithdraw/AddWithdrawCountriesList.tsx b/src/components/AddWithdraw/AddWithdrawCountriesList.tsx index 388d4919b..87ef8f235 100644 --- a/src/components/AddWithdraw/AddWithdrawCountriesList.tsx +++ b/src/components/AddWithdraw/AddWithdrawCountriesList.tsx @@ -62,6 +62,22 @@ const AddWithdrawCountriesList = ({ flow }: AddWithdrawCountriesListProps) => { const sumsubFlow = useMultiPhaseKycFlow({ onKycSuccess: () => { setIsKycModalOpen(false) + // The `view: 'form'` branch below renders DynamicBankAccountForm — + // the offramp/withdraw bank-account input form. That's correct for + // `flow === 'withdraw'` (user enters THEIR bank account to receive + // funds) but completely wrong for `flow === 'add'`, which needs + // Bridge's deposit instructions (an account belonging to Bridge + // that the user wires TO). Pre-fix this unconditional setView + // surfaced the withdraw form under an "Add money" title — the + // EEA QA Bug #5 ("Submitted, but still asking for account holder + // details when I'm trying to add money"). Route add-money users + // to /add-money/[country]/bank instead, which mounts + // AddMoneyBankDetails (deposit-instructions display). + if (flow === 'add') { + const countrySlug = currentCountry?.path + router.push(countrySlug ? `/add-money/${countrySlug}/bank` : '/add-money') + return + } setView('form') }, onManualClose: () => setIsKycModalOpen(false),