[$250] w27-BA- IBAN does not appear in the confirmation page, Auth CreateCorpayBankAccount error shown

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.4.26-9
Reproducible in staging?: Yes
Reproducible in production?: Unable to validate in Prod - Provide reasoning.
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-53229/folder/13176691/48574880/1539393073?sort=%2Bidentifier
Email or phone of affected tester (no customers): applausetester+gg2@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Honor x6b / Chrome , Windows 10/ Chrome
App Component: Other

Action Performed:

Precondition: Use a new expensifail account, be admin of a workspace with EUR currency

1. Navigate to Workflows → Add Bank Account → Connect Manually
2. Select Czech Republic as the Country and enter a valid test IBAN (e.g., CZ5508000000001234567899)
3. Continue to the next step, enter an address, and proceed to the confirmation page
4. Tap on Confirm
   Result: IBAN does not appear in the confirmation page, Auth CreateCorpayBankAccount error shown
5. Tap on go back button 3 times
   Result: "What are your bussines bank account details?" is spikked and Confirm currency and country is displayed
6. Tap on Confirm and Next without make any change until reach Confirmation page > Verify IBAN is displayed
7. Tap on Confirm > Verify "Business info" page is displayed

Expected Result:

User should be able to see IBAN information and continue to Business info page without need to go back

Actual Result:

IBAN does not appear in the confirmation page at first try and Auth CreateCorpayBankAccount error is shown. When user go back 3 times "What are your bussines bank account details?" is spikked and Confirm currency and country is displayed. Finally, when user proceed without make any change until reach Confirmation page, IBAN is displayed

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7198734_1783095344462.document_5062334242189477866.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7198734

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022073136426865643852
• Upwork Job ID: 2073136426865643852
• Last Price Increase: 2026-07-10

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/df1f754b3b4adc335bc580e61dbb3ffaf91de0fa7aa818c2768d991166571c9f

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On the non-USD (Corpay) "Add Bank Account → Connect Manually" flow for an EUR workspace, the IBAN entered for Czech Republic does not appear on the Confirmation page and tapping Confirm throws an Auth CreateCorpayBankAccount error on the first pass. After tapping back to the "Confirm currency and country" step and re-proceeding without changing anything, the IBAN appears and the flow succeeds.

What is the root cause of that problem?

This is a frontend race condition in the App repo between the asynchronous getCorpayBankAccountFields fetch and the rendering of the BankInfo form.

The Corpay dynamic bank-account fields (which define the IBAN input) are fetched only by a useEffect inside BankInfo.tsx that runs after navigating into the BankInfo step — the Country/Currency step does not prefetch them. For EUR, that effect re-fetches whenever the selected country differs from corpayFields.bankCountry (BankInfo.tsx:89).

Crucially, the render path (BankInfo.tsx:128-151) only gates on isRedirecting and the not-found case — there is no gate on corpayFields.isLoading and no check that the loaded fields match the selected country/currency. So the form renders against empty/stale formFields while the fetch is still in flight. Because the IBAN input, its input keys, and the Confirmation rows are all generated dynamically from corpayFields.formFields, the IBAN field never gets bound to the correct key, its value is never written to the form draft, and createCorpayBankAccount submits an incomplete payload → blank IBAN on Confirmation + the CreateCorpayBankAccount error.

It works on the second pass because getCorpayBankAccountFields merges formFields into Onyx and never clears them on back-navigation, so on re-entry the correct formFields are already cached on the first render and the IBAN is captured correctly.

Evidence / data flow

• IBAN input generated from formFields: BankAccountDetails.tsx — no formFields ⇒ no IBAN field ⇒ nothing saved to draft.
• Input keys derived from formFields: getInputKeysForBankInfoStep.ts.
• Confirmation rows keyed by field.id from formFields: Confirmation.tsx — value missing ⇒ blank IBAN row.
• Fetch merges into Onyx and is never cleared on back-nav: BankAccounts.ts (getCorpayBankAccountFields / clearCorpayBankAccountFields).

Flow: confirm EUR + Czech Republic (no fetch) → land on BankInfo with empty/stale corpayFields → effect kicks off async fetch, isLoading: true but no gate → form renders without the IBAN field → user's IBAN not saved → Confirm sends incomplete inputs → CreateCorpayBankAccount error + blank IBAN. Back 3× → fetch has resolved & cached → re-proceed → IBAN field present on first render → success.

What changes do you think we should make in order to solve the problem?

Gate the BankInfo substep render until the Corpay fields for the currently selected country + currency have loaded, and invalidate stale fields when country/currency changes:

1. In BankInfo.tsx, before rendering CurrentPage, show FullScreenLoadingIndicator while corpayFields?.isLoading is true, or while corpayFields?.formFields is undefined, or while corpayFields.bankCountry/bankCurrency don't yet match the selected {country, currency}.
2. Invalidate stale fields on refetch — include formFields: null in the optimistic MERGE inside getCorpayBankAccountFields (or call clearCorpayBankAccountFields before refetch) so a stale EUR fetch can't be rendered while the correct one is in flight.
3. As a safety net, disable Confirm / block advancing while corpayFields?.isLoading or while the fields don't match the selection, so createCorpayBankAccount can never be called with an incomplete payload.

What alternative solutions did you explore?

The CreateCorpayBankAccount error is a downstream symptom of the incomplete frontend payload, not a separate Auth-side bug — so no backend change is needed; the fix belongs entirely in App.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95309) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[kitvasyl]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When adding a Czech EUR bank account, the first confirmation page omits the IBAN and submitting it causes CreateCorpayBankAccount to fail. Re-entering the bank-info flow makes the IBAN appear and allows onboarding to continue.

What is the root cause of that problem?

In src/pages/ReimbursementAccount/NonUSD/BankInfo/BankInfo.tsx, getCorpayBankAccountFields() refetches the field definition after detecting that corpayFields.bankCountry does not match the selected country. However, the subpage flow can still initialize and advance using the previous field definition.

BankAccountDetails.tsx builds fieldIds from that stale definition, while Confirmation.tsx later renders values from the refreshed definition. Consequently, the IBAN key can be omitted from the saved draft and from the first createCorpayBankAccount() payload. Going back gives the fetch time to finish, so the second pass uses the correct fields.

What changes do you think we should make in order to solve the problem?

In BankInfo.tsx, derive whether the Corpay fields match the selected country and currency. Keep the bank-info subflow in its loading state and prevent its pages from advancing or submitting until isLoading is false and bankCountry/bankCurrency match the current selection.

Only calculate the initial substep and expose the bank-info pages after those matching fields are ready. This ensures BankAccountDetails builds fieldIds with the IBAN field and submit() sends the same values displayed by Confirmation.

Add a regression test covering a country change followed by a Corpay-field refresh, asserting that confirmation contains the IBAN and the create request includes it on the first pass.

What alternative solutions did you explore? (Optional)

Adding IBAN directly to the confirmation or create payload would hide the race and remain fragile for other country-specific fields. Waiting for the selected country’s complete field definition fixes the shared state transition instead.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-03 20:11:22 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

In the "Add Bank Account → Connect Manually" flow of a EUR workspace, after selecting a EUR-but-non-Eurozone country (e.g. Czech Republic) and entering a valid IBAN, the Bank info confirmation page shows no IBAN on the first attempt and the CreateCorpayBankAccount request fails with an Auth error. If the user backs out to "Confirm currency and country" and steps through the exact same data again without changing anything, the IBAN now renders and the account is created successfully. So the same inputs fail the first time and succeed on the retry.

What is the root cause of that problem?

The failure is a timing bug tied to the EUR-only re-fetch of the Corpay field schema, not a bad value in the payload. In BankInfo.tsx, whenever the workspace currency is EUR, an effect re-fetches the Corpay fields any time the selected country doesn't equal the country echoed back inside the fetched Corpay data:

App/src/pages/ReimbursementAccount/NonUSD/BankInfo/BankInfo.tsx

Lines 88 to 92 in b2e9881

	// When workspace currency is set to EUR we need to refetch if country from Step 1 doesn't match country inside fetched Corpay data
	if (currency === CONST.CURRENCY.EUR && country !== corpayFields?.bankCountry) {
	getCorpayBankAccountFields(country, currency);
	return;
	}

For a EUR account whose bank country is Czech Republic, getCorpayBankAccountFields('CZ', 'EUR') returns a bankCountry that is not the requested ISO (this reconcile branch only exists because the two never line up for the shared EUR schema). The first fetch (call #1) resolves so the IBAN input renders and the user fills it in — but that resolution changes corpayFields.bankCountry, which is a dependency of the same effect, so it immediately schedules a second reconcile fetch (call #2) that sets corpayFields.isLoading back to true. On the cold first pass this second fetch is still in flight by the time the user reaches the confirmation sub-page.

The confirmation sub-page renders its summary rows (including the IBAN row) only when the Corpay fields are not loading, otherwise it shows a spinner:

App/src/pages/ReimbursementAccount/NonUSD/BankInfo/subSteps/Confirmation.tsx

Lines 76 to 80 in b2e9881

	{corpayFields?.isLoading ? (
	<ActivityIndicator
	size={CONST.ACTIVITY_INDICATOR_SIZE.LARGE}
	style={styles.flexGrow1}
	reasonAttributes={corpayFieldsLoadingReasonAttributes}

So while call #2 is in flight, corpayFields?.isLoading === true, the items list is replaced by the ActivityIndicator, and the IBAN "does not appear." Critically, the Confirm button in that FormProvider has no isSubmitDisabled guard, so the user can still tap it. Confirmation.onSubmit is wired to onNext, which drives useSubPage to call onFinished → BankInfo.submit(), which fires CreateCorpayBankAccount against the still-loading/inconsistent Corpay state, producing the Auth error:

App/src/pages/ReimbursementAccount/NonUSD/BankInfo/BankInfo.tsx

Lines 56 to 60 in b2e9881

	const submit = () => {
	const {formFields, isLoading, isSuccess, ...corpayData} = corpayFields ?? {};
	isSubmittingRef.current = true;
	createCorpayBankAccount({...values, ...corpayData} as ReimbursementAccountForm, policyID);

On the retry the schema is already cached, so the same reconcile fetch resolves near-instantly and isLoading is false by the time the confirmation renders — the IBAN row shows and the submit goes out against settled data, which is exactly why the identical inputs succeed the second time.

What changes do you think we should make in order to solve the problem?

Gate the confirmation's Confirm action on the Corpay fields being ready, so CreateCorpayBankAccount can never be dispatched while the EUR reconcile fetch is mid-flight. The minimal change is to pass an isSubmitDisabled guard to the FormProvider in Confirmation.tsx so the button is disabled exactly when the rows are hidden:

isSubmitDisabled={!!corpayFields?.isLoading || !corpayFields?.formFields?.length}

This mirrors the pattern already used on the sibling sub-step BankAccountDetails (isSubmitDisabled={!inputs}), so it is a well-established, low-risk approach and is scoped entirely to this page — no other caller of createCorpayBankAccount or the shared form is affected. Once call #2 resolves, isLoading flips to false, the IBAN row renders, and the button re-enables, so the user confirms against complete data. As a belt-and-suspenders guard for the onFinished path, BankInfo.submit() should early-return when the fields aren't ready (if (corpayFields?.isLoading || !corpayFields?.formFields?.length) { return; }) before calling createCorpayBankAccount, preventing a premature dispatch even if the button were reached in a transient state.

What alternative solutions did you explore? (Optional)

I considered fixing the reconcile effect itself so it stops issuing the extra mid-flow fetch (e.g. tracking the country already fetched instead of comparing against the backend-echoed bankCountry), which would remove the isLoading flicker at the source. I rejected it as the primary fix because that branch was added specifically to reconcile EUR country changes and its correctness depends on the backend's bankCountry semantics, so changing it risks regressing the country-switch case; guarding the submit fixes the user-visible failure without that risk.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-03 20:16:07 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

When an admin of a EUR workspace adds a bank account manually and picks Czech Republic, the IBAN they entered is blank on the confirmation page and tapping Confirm throws an Auth CreateCorpayBankAccount error. The only way through is to go back to the bank-details page and walk forward again without changing anything, at which point the same IBAN shows up and the submission succeeds.

What is the root cause of that problem?

The Corpay dynamic-form state hasn't settled by the time the user confirms, so the confirmation reads an incomplete set of fields and the API sends a payload with no IBAN.

Here's the flow. In src/pages/ReimbursementAccount/NonUSD/BankInfo/BankInfo.tsx, getCurrencyForNonUSDBankAccount resolves {country: 'CZ', currency: 'EUR'} (Czech Republic is mapped to EUR in BBA_COUNTRY_CURRENCY_MAP even though its local currency is CZK, and it's not in the Eurozone). The fetch effect at lines 82-100 then decides whether to (re)fetch the Corpay fields:

if (currency === CONST.CURRENCY.EUR && country !== corpayFields?.bankCountry) { getCorpayBankAccountFields(country, currency); return; }
if (currency === corpayFields?.bankCurrency) { return; }
getCorpayBankAccountFields(country, currency);

Both guards compare the user's selected country/currency against the values the backend echoes back in corpayFields.bankCountry/bankCurrency. For a CZ+EUR request, the Corpay response comes back with a bankCountry/bankCurrency that never satisfies both guards at once, so the effect keeps re-firing getCorpayBankAccountFields on every render. corpayFields.isLoading churns and formFields gets replaced repeatedly, so on the first forward pass the state never settles.

That matters because the IBAN only reaches the payload through values in Confirmation.tsx (line 32), which is keyed off getInputKeysForBankInfoStep(corpayFields) — the current formFields ids. While formFields is unsettled, the IBAN (field id accountNumber) is absent from values, so it renders blank in the confirmation list and is missing from the object passed to createCorpayBankAccount at BankInfo.tsx:60, which is what the Auth backend rejects. On the retry the response is cached and settled, so values is complete and the identical input goes through — the app sent a different, complete payload the second time, which is why the workaround works.

There's a compounding gap. The FormProvider in Confirmation.tsx (lines 66-72) has onSubmit={onNext} with no isSubmitDisabled, so a Confirm tap while corpayFields.isLoading is still true goes straight to createCorpayBankAccount with the incomplete values. The onReconnect handler at BankInfo.tsx:63-67 and the fetch effect also fire with no in-flight guard, so they can stack duplicate fetches.

The EUR refetch branch (lines 88-92) was added in commit c45c1a690b31 ("fix: 60519", 2025-04-29). Nothing has touched BankInfo.tsx or getBankInfoStepValues since besides formatting, so this isn't already fixed on main.

What changes do you think we should make in order to solve the problem?

Stop refetching against the backend-echoed values and instead fetch each (country, currency) pair at most once, guarded on the in-flight load. A useRef holding the last-fetched key does this cleanly and matches how the repo tracks one-shot fetches elsewhere:

const lastFetchedRef = useRef('');
useEffect(() => {
    if (country === '' || corpayFields?.isLoading) return;
    const key = `${country}:${currency}`;
    if (lastFetchedRef.current === key) return;
    lastFetchedRef.current = key;
    getCorpayBankAccountFields(country, currency);
}, [country, currency, corpayFields?.isLoading]);

For defense in depth, pass isSubmitDisabled={!!corpayFields?.isLoading} to the FormProvider in Confirmation.tsx so an incomplete payload can't be submitted even if the fields are mid-flight. There's currently no test around the NonUSD EUR refetch or the confirmation payload, so I'd add one: with EUR plus a country whose backend bankCurrency isn't EUR, assert getCorpayBankAccountFields is called at most once and that the confirmation values contain the IBAN.

One thing to flag: the exact guard depends on what the real CZ/EUR Corpay response echoes back, which isn't visible from the App repo. I'd want to confirm the refetch loop in a running build (count the GetCorpayBankAccountFields calls and watch corpayFields.isLoading) before finalizing. If that loop doesn't reproduce, the root cause moves to the Auth/Corpay backend and is out of App-repo scope.

What alternative solutions did you explore? (Optional)

I considered that the field-id keys permanently mismatch for CZ, but ruled it out — the second pass reads the same draft and succeeds, so it's a settling/timing problem, not a fixed key change. I also considered a pure backend rejection of valid data, but the identical input succeeds on retry, which means Auth received a different (complete) payload the second time, so the Auth error is downstream of the app's incomplete first payload.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When a user submits the Corpay bank account form for the first time, the IBAN value is not being passed correctly to the confirmation page or to the CreateCorpayBankAccount API call. The likely root cause is that the IBAN field value is stored under a different key or is being read before Onyx has persisted it, causing an empty/undefined value on the first attempt. After going back and re-submitting, the Onyx store is populated so the value appears correctly on the second try.

What changes do you think we should make in order to solve the problem?

I'd look at src/pages/ReimbursementAccount/ — specifically the Corpay bank account step that handles IBAN input and the confirmation page that reads it. The fix is to ensure the IBAN field key used when saving draft values matches exactly the key used when reading for the confirmation screen and API payload.

// In the IBAN input step (e.g., CorpayBankAccountForm or similar)
- const ibanValue = reimbursementAccountDraft?.[CORPAY_FIELDS.IBAN];
+ const ibanValue = reimbursementAccountDraft?.[CORPAY_FIELDS.IBAN] ?? reimbursementAccount?.achData?.[CORPAY_FIELDS.IBAN];

And in the CreateCorpayBankAccount action, ensure the IBAN is read from the correct Onyx key before the API call is made, not from a stale local variable:

- const iban = formValues.iban;
+ const iban = formValues[CORPAY_FIELDS.IBAN] ?? reimbursementAccountDraft[CORPAY_FIELDS.IBAN];

This guarantees the IBAN is never undefined on the first submission attempt.

What alternative solutions did you explore?

An alternative would be to force a re-read of the Onyx draft values inside onSubmit via Onyx.get() before calling the API, but that introduces async complexity. The direct key-alignment fix above is cleaner and addresses the root cause without side effects.

[nabi-ebrahimi]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-06 13:32:51 UTC.

Proposal

What is the root cause of that problem?

The Non-USD Bank info step is schema-driven. It derives inputKeys, confirmation values, and the final CreateCorpayBankAccount payload from the current ONYXKEYS.CORPAY_FIELDS.formFields in BankInfo.tsx

App/src/pages/ReimbursementAccount/NonUSD/BankInfo/BankInfo.tsx

Lines 50 to 60 in 9febb24

	const {country, currency} = getCurrencyForNonUSDBankAccount(policy, reimbursementAccountDraft, reimbursementAccount);
	const inputKeys = getInputKeysForBankInfoStep(corpayFields);
	const values = useMemo(() => getBankInfoStepValues(inputKeys, reimbursementAccountDraft, reimbursementAccount), [inputKeys, reimbursementAccount, reimbursementAccountDraft]);
	const startFrom = useMemo(() => getInitialSubStepForBankInfoStep(values, corpayFields), [corpayFields, values]);
	const isSubmittingRef = useRef(false);
	const submit = () => {
	const {formFields, isLoading, isSuccess, ...corpayData} = corpayFields ?? {};
	isSubmittingRef.current = true;
	createCorpayBankAccount({...values, ...corpayData} as ReimbursementAccountForm, policyID);

The same component fetches that schema from the selected bank country and currency in BankInfo.tsx

App/src/pages/ReimbursementAccount/NonUSD/BankInfo/BankInfo.tsx

Lines 82 to 100 in 9febb24

	useEffect(() => {
	// No fetching when there is no country
	if (country === '') {
	return;
	}
	// When workspace currency is set to EUR we need to refetch if country from Step 1 doesn't match country inside fetched Corpay data
	if (currency === CONST.CURRENCY.EUR && country !== corpayFields?.bankCountry) {
	getCorpayBankAccountFields(country, currency);
	return;
	}
	// No fetching when workspace currency matches the currency inside fetched Corpay
	if (currency === corpayFields?.bankCurrency) {
	return;
	}
	getCorpayBankAccountFields(country, currency);
	}, [corpayFields?.bankCurrency, corpayFields?.bankCountry, country, currency]);

.

The selected bank country can be overwritten by the account-holder address autocomplete. AddressSearch adds a country value to the returned address object and writes each returned key back to the form draft, using the original key when no renamedInputKeys mapping exists in AddressSearch/index.tsx

App/src/components/AddressSearch/index.tsx

Lines 284 to 296 in 9febb24

	const isValidCountryCode = !!Object.keys(CONST.ALL_COUNTRIES).find((foundCountry) => foundCountry === country);
	if (isValidCountryCode) {
	values.country = country;
	}
	if (inputID) {
	for (const [key, inputValue] of Object.entries(values)) {
	const inputKey = renamedInputKeys?.[key as keyof Omit<Address, 'current'>] ?? key;
	if (!inputKey) {
	continue;
	}
	onInputChange?.(inputValue, inputKey);
	}

. In this reimbursement flow, the generic country draft key is the bank country that drives the Corpay schema fetch.

AccountHolderDetails maps street and city, but it does not map or suppress country in AccountHolderDetails.tsx

App/src/pages/ReimbursementAccount/NonUSD/BankInfo/subSteps/AccountHolderDetails.tsx

Lines 143 to 146 in 9febb24

	renamedInputKeys={{
	street: 'accountHolderAddress1',
	city: 'accountHolderCity',
	}}

. So after selecting Czech Republic and entering the IBAN, selecting an account-holder address can write that address country into the bank-country field. That can trigger a Corpay field refetch for a different country or leave the Bank info pages using a schema that no longer matches the user's selected bank country.

The bank-address substep already avoids this class of bug by explicitly suppressing the address country write with country: '' in BankAccountDetails.tsx

App/src/pages/ReimbursementAccount/NonUSD/BankInfo/subSteps/BankAccountDetails.tsx

Lines 110 to 114 in 9febb24

	renamedInputKeys={{
	street: 'bankAddressLine1',
	city: 'bankCity',
	country: '',
	}}

. The account-holder substep needs equivalent key handling, but should preserve the holder country by mapping it to accountHolderCountry.

There is also no submit guard on the confirmation step. Confirmation replaces the summary rows with a spinner while corpayFields.isLoading, but its FormProvider still allows submit in Confirmation.tsx

App/src/pages/ReimbursementAccount/NonUSD/BankInfo/subSteps/Confirmation.tsx

Lines 65 to 84 in 9febb24

	return (
	<FormProvider
	formID={ONYXKEYS.FORMS.REIMBURSEMENT_ACCOUNT_FORM}
	submitButtonText={translate('common.confirm')}
	onSubmit={onNext}
	style={[styles.flexGrow1]}
	submitButtonStyles={styles.mh5}
	>
	<View style={styles.flexGrow4}>
	<Text style={[styles.textHeadlineLineHeightXXL, styles.ph5, styles.mb3]}>{translate('bankInfoStep.letsDoubleCheck')}</Text>
	<Text style={[styles.textSupporting, styles.ph5, styles.mb5]}>{translate('bankInfoStep.thisBankAccount')}</Text>
	{corpayFields?.isLoading ? (
	<ActivityIndicator
	size={CONST.ACTIVITY_INDICATOR_SIZE.LARGE}
	style={styles.flexGrow1}
	reasonAttributes={corpayFieldsLoadingReasonAttributes}
	/>
	) : (
	items
	)}

. That lets CreateCorpayBankAccount run while the Corpay schema is loading or stale.

A second schema-freshness issue is that BankInfo currently compares the selected BBA currency with Corpay response metadata bankCurrency in BankInfo.tsx

App/src/pages/ReimbursementAccount/NonUSD/BankInfo/BankInfo.tsx

Lines 88 to 99 in 9febb24

	// When workspace currency is set to EUR we need to refetch if country from Step 1 doesn't match country inside fetched Corpay data
	if (currency === CONST.CURRENCY.EUR && country !== corpayFields?.bankCountry) {
	getCorpayBankAccountFields(country, currency);
	return;
	}
	// No fetching when workspace currency matches the currency inside fetched Corpay
	if (currency === corpayFields?.bankCurrency) {
	return;
	}
	getCorpayBankAccountFields(country, currency);

. For EUR/non-eurozone countries like Czech Republic, the requested BBA currency can be EUR while Corpay's returned bank metadata can represent the bank's local currency. Backend response metadata should not be used as the frontend request identity.

What changes do you think we should make in order to solve the problem?

First, fix the draft key collision in AccountHolderDetails. Map the AddressSearch country output to accountHolderCountry. This keeps the selected bank country stable and still saves the holder's country from autocomplete.

Second, add explicit request metadata to ONYXKEYS.CORPAY_FIELDS, for example requestedCountry and requestedCurrency. getCorpayBankAccountFields currently only merges isLoading / isSuccess in its optimistic, success, and failure data in BankAccounts.ts

App/src/libs/actions/BankAccounts.ts

Lines 833 to 864 in 9febb24

	const onyxData: OnyxData<typeof ONYXKEYS.CORPAY_FIELDS> = {
	optimisticData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.CORPAY_FIELDS,
	value: {
	isLoading: true,
	isSuccess: false,
	},
	},
	],
	successData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.CORPAY_FIELDS,
	value: {
	isLoading: false,
	isSuccess: true,
	},
	},
	],
	failureData: [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.CORPAY_FIELDS,
	value: {
	isLoading: false,
	isSuccess: false,
	},
	},
	],
	};

. It should also write the requested country/currency in those same Onyx updates.

Then make BankInfo consume Corpay fields only when the loaded schema belongs to the latest selected bank country/currency. The ready condition should be based on:

• requestedCountry === country
• requestedCurrency === currency
• isLoading === false
• isSuccess === true
• formFields is present

Only when that condition is true should BankInfo derive inputKeys, calculate startFrom, render the Bank info substeps, or submit CreateCorpayBankAccount.

Do not use bankCurrency === currency as the schema-ready check. Keep bankCountry / bankCurrency as Corpay response metadata, and exclude requestedCountry / requestedCurrency from the create payload because they are frontend request-tracking fields.

Add submit-boundary protection as well:

• disable the Confirmation submit button while Corpay fields are loading or missing
• make BankInfo.submit return early when the ready condition is false
• optionally merge the final finishData passed by useSubPage over the draft-derived values before submit as defense in depth against one-render-late draft updates

What alternative solutions did you explore? (Optional)

I considered only waiting for setDraftValues() before advancing substeps and merging finishData into BankInfo.submit. That can reduce stale draft timing issues, but it does not fix the actual country corruption or schema freshness problem.

I considered only disabling Confirm while corpayFields.isLoading. That prevents one premature submit path, but it still allows the account-holder address to overwrite the selected bank country and fetch the wrong schema.

I considered using bankCountry / bankCurrency as freshness markers. That is unsafe because those fields are backend response metadata, not request identity, and can differ from the selected BBA country/currency semantics for EUR/non-eurozone bank accounts.

Fixed Demo:

Screencast.From.2026-07-06.17-44-28.mp4

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user on a EUR workspace goes through Workflows → Add Bank Account → Connect Manually, selects Czech Republic, enters a valid IBAN, and taps Confirm on the confirmation page, the IBAN row is missing from the summary and the request fails with an "Auth CreateCorpayBankAccount" error. After going back three times to the country/currency step and moving forward again without changing anything, the IBAN then appears and the flow proceeds normally. This affects Android, iOS, and Web. The expected behavior is that the IBAN is shown on the first pass through the confirmation page and the CreateCorpayBankAccount call succeeds without needing the back-and-forward workaround.

What is the root cause of that problem?

In src/pages/settings/Wallet/InternationalDepositAccount/subPages/CountrySelection.tsx:35, when the user first picks a country, fetchCorpayFields(selectedCountry) is called with only the country and no currency argument. The subsequent BankAccountDetails currency step at src/pages/settings/Wallet/InternationalDepositAccount/subPages/BankAccountDetails.tsx:48 only re-fetches fetchCorpayFields(bankCountry, value) when the user actively picks a different currency in onCurrencySelected — because the workspace-default (EUR/CZ) is already prefilled as formValues.bankCurrency, the guard if (formValues.bankCurrency === value) returns early and no country+currency-scoped fetch ever runs. As a result, the CORPAY_FIELDS Onyx cache used by Confirmation.tsx (lines 113 and 135) contains the country-only field descriptor set (missing the currency-scoped IBAN / preferredMethod / classification), so IBAN is not rendered in the summary and createCorpayBankAccountForWalletFlow at Confirmation.tsx:67 is called with empty classification/destinationCountry/preferredMethod, triggering the Auth CreateCorpayBankAccount error. Walking back three times and re-selecting the country hits the formValues.bankCountry === selectedCountry short-circuit at CountrySelection.tsx:31 which skips the bad fetch, so the fields fetched later during any subsequent currency interaction (or preserved from an earlier full fetch) become the ones consumed on the second pass.

What changes do you think we should make in order to solve the problem?

1. In src/pages/settings/Wallet/InternationalDepositAccount/subPages/CountrySelection.tsx:35, pass the currently selected (or workspace default) currency to fetchCorpayFields(selectedCountry, formValues.bankCurrency) so the initial fetch is scoped to both country AND currency, matching what BankAccountDetails does.
2. In src/pages/settings/Wallet/InternationalDepositAccount/subPages/BankAccountDetails.tsx:43-52, if corpayFields is empty or was fetched without a currency (or its destinationCountry/preferredMethod are missing for the current country+currency), trigger fetchCorpayFields(formValues.bankCountry, formValues.bankCurrency) on mount so the country-only case is self-healed even without a user currency change.
3. In src/pages/settings/Wallet/InternationalDepositAccount/subPages/Confirmation.tsx:66-68, guard getDataAndGoToNextStep so submission is blocked (and IBAN row absent triggers a re-fetch) when corpayFields?.classification, destinationCountry, or preferredMethod are missing, instead of firing createCorpayBankAccountForWalletFlow with empty strings that produce the auth error.
4. Optionally in fetchCorpayFields (userActions/BankAccounts), make the currency parameter required for the international deposit flow, or default it from the caller's workspace currency, so no call site can silently produce a partial CORPAY_FIELDS payload.

What alternative solutions did you explore? (Optional)

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External)