[Due for payment 2026-08-17] [$250] 'Name can only include letters' error message displayed for the name on card field

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.28-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @Getrudygidashang
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Login as workspace admin (Role updated by owner)
2. Go to Workspace > Members > Click on Owner row > Transfer Ownership
3. Prompted to add payment method
4. Add Card Number
5. Add Card Name with letter and number
6. Focus on other field
7. Observe the error message for Card name field

Expected Result:

Card name can include numbers (The same card was added successfully in Classic)

Actual Result:

The card name field showed an error "Name can only include letters"
Same error message observed when trying to a card for subscription

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Upwork Automation - Do Not Edit

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

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Name on card" field is validated with isValidLegalName, which only permits Latin letters and spaces — no digits:

• PaymentCardForm.tsx:186 rejects the value and sets the addPaymentCardPage.error.invalidName ("Name can only include letters") error.
• isValidLegalName (ValidationUtils.ts:427-429) tests against ALPHABETIC_AND_LATIN_CHARS (CONST/index.ts:4875) = /^[\p{Script=Latin} ]*$/u, which matches letters and spaces only.

Since a name containing numbers fails this regex, the error fires — even though Classic accepts numbers in the card name. This validator is intentionally letters-only because it is a general legal name check (also used for signer info and full-name steps), so it should not simply be loosened. The card-name field is reusing the wrong validator.

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

Give the "Name on card" field its own validator that allows letters and numbers (plus spaces), instead of reusing isValidLegalName:

1. Add a NAME_ON_CARD regex to CONST.REGEX that permits Latin letters, digits, and spaces (e.g. /^[\p{Script=Latin}\p{Nd} ]*$/u).
2. Add an isValidNameOnCard helper in ValidationUtils.ts that tests against it.
3. Use isValidNameOnCard at PaymentCardForm.tsx:186 instead of isValidLegalName.

This scopes the change to the card-name field only. PaymentCardForm backs both the Add Payment Card flow (Transfer Ownership / subscription) and the Add Debit Card flow, so both get the fix. The other isValidLegalName callers (SignerInfo, FullNameStep) keep their letters-only behavior.

Investigation details & alternatives considered

• Alternative — loosen ALPHABETIC_AND_LATIN_CHARS or isValidLegalName directly: rejected. That regex/validator is shared by legal-name fields (SignerInfo/subSteps/Name.tsx, EnterSignerInfo/subSteps/Name.tsx, FullNameStep.tsx) where numbers should stay disallowed. A dedicated validator avoids that regression.
• Existing ALPHANUMERIC_WITH_SPACE_AND_HYPHEN regex (/^[A-Za-z0-9 -]+$/) is ASCII-only and would drop accented Latin characters currently accepted, so it isn't a drop-in.
• Symptom coverage: the reporter saw the same error on both Transfer Ownership and subscription card entry — both routes render PaymentCardForm and hit the same line 186, so a single fix covers both.

---

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

[nabi-ebrahimi]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 18:48:28 UTC.

Proposal

What is the root cause of that problem?

The Name on card field is being validated with the wrong kind of name validator.

All affected entry points eventually render the shared PaymentCardForm, and its validate function checks values.nameOnCard with isValidLegalName():

App/src/components/AddPaymentCard/PaymentCardForm.tsx

Lines 183 to 188 in 5633c0f

	const validate = (values: FormOnyxValues<typeof ONYXKEYS.FORMS.ADD_PAYMENT_CARD_FORM>): FormInputErrors<typeof ONYXKEYS.FORMS.ADD_PAYMENT_CARD_FORM> => {
	const errors = getFieldRequiredErrors(values, REQUIRED_FIELDS, translate);
	if (values.nameOnCard && !isValidLegalName(values.nameOnCard)) {
	errors.nameOnCard = translate(label.error.nameOnCard);
	}

isValidLegalName() is intended for legal/KYC-style person names, not cardholder/card display names. It validates against CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS:

App/src/libs/ValidationUtils.ts

Lines 424 to 428 in 5633c0f

	/**
	* Checks that the provided legal name doesn't contain special characters
	*/
	function isValidLegalName(name: string): boolean {
	return CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS.test(name);

App/src/CONST/index.ts

Lines 4871 to 4875 in 5633c0f

	},
	REGEX: {
	SPECIAL_CHARS_WITHOUT_NEWLINE: /((?!\n)[()-\s\t])/g,
	DIGITS_AND_PLUS: /^\+?[0-9]*$/,
	ALPHABETIC_AND_LATIN_CHARS: /^[\p{Script=Latin} ]*$/u,

That regex is:

/^[\p{Script=Latin} ]*$/u

So it allows Latin-script letters and spaces only. Digits are not Latin-script characters, so a value like Test 123, ACME 2 LLC, or John Smith 2 fails immediately on the client and the form shows the current invalidName copy: Name can only include letters.

This is why the behavior is consistent across the reported flows. The subscription add-card page and the workspace owner-transfer payment-card page both submit the same nameOnCard value as addressName after this shared form validation passes:

App/src/pages/settings/Subscription/PaymentCard/index.tsx

Lines 88 to 99 in f71766d

	const addPaymentCard = useCallback(
	(values: FormOnyxValues<typeof ONYXKEYS.FORMS.ADD_PAYMENT_CARD_FORM>) => {
	const cardData = {
	cardNumber: getMCardNumberString(values.cardNumber),
	cardMonth: getMonthFromExpirationDateString(values.expirationDate),
	cardYear: getYearFromExpirationDateString(values.expirationDate),
	cardCVV: values.securityCode,
	addressName: values.nameOnCard,
	addressZip: values.addressZipCode,
	currency: values.currency ?? CONST.PAYMENT_CARD_CURRENCY.USD,
	};
	addSubscriptionPaymentCard(accountID ?? CONST.DEFAULT_NUMBER_ID, cardData, fundList);

App/src/pages/workspace/members/WorkspaceOwnerPaymentCardForm.tsx

Lines 70 to 82 in f71766d

	const addPaymentCard = useCallback(
	(values: FormOnyxValues<typeof ONYXKEYS.FORMS.ADD_PAYMENT_CARD_FORM>) => {
	const cardData = {
	cardNumber: getMCardNumberString(values.cardNumber),
	cardMonth: getMonthFromExpirationDateString(values.expirationDate),
	cardYear: getYearFromExpirationDateString(values.expirationDate),
	cardCVV: values.securityCode,
	addressName: values.nameOnCard,
	addressZip: values.addressZipCode,
	currency: values.currency,
	};
	addBillingCardAndRequestPolicyOwnerChange(policyID, currentUserAccountID, currentUserEmail, cardData);
	},

So the request never reaches the payment-card API for names containing digits. Classic accepting the same card strongly points to this being an over-strict NewDot client-side validation rule, not a backend rejection.

The important distinction is that isValidLegalName() itself is not broken. It is still the right validator for legal-name fields such as signer info and full-name flows, where digits should remain invalid. The bug is that PaymentCardForm reused that legal-name validator for a card-name field.

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

Add a card-specific validator and use it only for nameOnCard.

1. Add a dedicated regex in CONST.REGEX, for example:

PAYMENT_CARD_NAME: /^[\p{Script=Latin}0-9 ]*$/u

This preserves the current Unicode Latin support, so names like José García or Müller that pass today continue to pass, while adding support for ASCII digits. We should not reuse ALPHANUMERIC_WITH_SPACE_AND_HYPHEN because that regex is ASCII-only and would regress accented Latin names that the current validator already accepts.

2. Add a helper in ValidationUtils, for example isValidPaymentCardName(), that tests against this new regex.

3. Update PaymentCardForm to validate INPUT_IDS.NAME_ON_CARD with isValidPaymentCardName() instead of isValidLegalName().

This keeps the behavior scoped to the shared card form and fixes all affected card-entry surfaces at the single convergence point, without weakening validation for legal-name/KYC flows.

4. Update the invalid-name copy for both card variants because Name can only include letters will no longer be true. A copy like this would match the new validation rule:

Name can only include letters and numbers

The relevant English strings are under addDebitCardPage.error.invalidName and addPaymentCardPage.error.invalidName:

App/src/languages/en.ts

Lines 2509 to 2544 in f71766d

	addDebitCardPage: {
	addADebitCard: 'Add a debit card',
	nameOnCard: 'Name on card',
	debitCardNumber: 'Debit card number',
	expiration: 'Expiration date',
	expirationDate: 'MMYY',
	cvv: 'CVV',
	billingAddress: 'Billing address',
	growlMessageOnSave: 'Your debit card was successfully added',
	expensifyPassword: 'Expensify password',
	error: {
	invalidName: 'Name can only include letters',
	addressZipCode: 'Please enter a valid zip code',
	debitCardNumber: 'Please enter a valid debit card number',
	expirationDate: 'Please select a valid expiration date',
	securityCode: 'Please enter a valid security code',
	addressStreet: "Please enter a valid billing address that's not a PO box",
	addressState: 'Please select a state',
	addressCity: 'Please enter a city',
	genericFailureMessage: 'An error occurred while adding your card. Please try again.',
	password: 'Please enter your Expensify password',
	},
	},
	addPaymentCardPage: {
	addAPaymentCard: 'Add payment card',
	nameOnCard: 'Name on card',
	paymentCardNumber: 'Card number',
	expiration: 'Expiration date',
	expirationDate: 'MM/YY',
	cvv: 'CVV',
	billingAddress: 'Billing address',
	growlMessageOnSave: 'Your payment card was successfully added',
	expensifyPassword: 'Expensify password',
	error: {
	invalidName: 'Name can only include letters',
	addressZipCode: 'Please enter a valid zip code',

The same wording should be mirrored through the existing locale files, or handled through whatever localization process is expected for this repo, so we do not leave stale “letters only” copy in non-English builds.

5. Add focused regression coverage:

• Unit coverage for the new validator:
  • accepts Test 123
  • accepts ACME 2 LLC
  • accepts an accented Latin name such as José García
  • rejects unsupported/special-character values such as Test@123
• Keep or add coverage proving isValidLegalName('John 2') still fails, so we do not accidentally loosen legal-name validation.
• Extend PaymentCardFormTest to verify that entering a name with digits does not show the invalid-name error, while an unsupported special-character value still does.

The existing PaymentCardFormTest already renders the subscription add-card page, so it is a good place to add form-level validation coverage:

App/tests/unit/PaymentCardFormTest.tsx

Lines 52 to 83 in f71766d

	describe('Subscription/AddPaymentCard', () => {
	const Stack = createStackNavigator();
	const hydrateAddPaymentCardForm = async () => {
	await Onyx.merge(ONYXKEYS.FORMS.ADD_PAYMENT_CARD_FORM, {});
	await waitForBatchedUpdates();
	};
	const renderAddPaymentCardPage = async (initialRouteName: typeof SCREENS.SETTINGS.SUBSCRIPTION.ADD_PAYMENT_CARD) => {
	const rendered = render(
	<ComposeProviders components={[OnyxListItemProvider, LocaleContextProvider, CurrentReportIDContextProvider, HTMLEngineProvider]}>
	<PortalProvider>
	<NavigationContainer>
	<Stack.Navigator initialRouteName={initialRouteName}>
	<Stack.Screen
	name={SCREENS.SETTINGS.SUBSCRIPTION.ADD_PAYMENT_CARD}
	component={AddPaymentCard}
	/>
	</Stack.Navigator>
	</NavigationContainer>
	</PortalProvider>
	</ComposeProviders>,
	);
	await waitForBatchedUpdatesWithAct();
	return rendered;
	};
	describe('AddPaymentCardPage Expiration Date Formatting', () => {
	const runFormatTest = async (input: string, formattedAs: string) => {
	await hydrateAddPaymentCardForm();
	await renderAddPaymentCardPage(SCREENS.SETTINGS.SUBSCRIPTION.ADD_PAYMENT_CARD);
	const expirationDateField = await screen.findByTestId('addPaymentCardPage.expiration');

What alternative solutions did you explore? (Optional)

A broader OldDot-parity solution would be to avoid frontend character allowlist validation for nameOnCard unless we can confirm the exact OldDot/backend rule.

After additional testing in Classic, the accepted values are not limited to Latin letters, digits, spaces, or even “at least one Latin character”. Classic accepts values such as:

• 测试
• محمد
• sdfgkj <sdf>
• Test 123

So these narrower validators would still be incorrect for full Classic parity:

• /^[\p{Script=Latin}0-9 ]*$/u rejects 测试, محمد, and sdfgkj <sdf>
• /\p{Script=Latin}/u rejects 测试 and محمد

That means the safest generic approach is:

1. Stop using isValidLegalName() for nameOnCard.
2. Keep the required-field validation from getFieldRequiredErrors().
3. Do not add a new guessed frontend character allowlist.
4. If additional format validation is required, base it on the exact confirmed OldDot/backend/payment-processor contract.

With that approach, NewDot would no longer block values that Classic already accepts, such as:

• Test 123
• ACME 2 LLC
• José García
• 测试
• محمد
• sdfgkj <sdf>

The invalid-name copy should also avoid describing an allowlist unless one is confirmed. A generic message like this would be safer:

Please enter a valid name on card

Fixed Demo

Screen.Recording.2026-07-07.at.10.58.43.PM.mov

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 14:43:06 UTC.

Proposal

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

When adding a payment card (Transfer Ownership, Subscription, or the Wallet debit card flow), typing a name that contains a number shows the error "Name can only include letters". Real cards can have digits in the embossed name, and Classic accepts the exact same card, so users get blocked on a valid entry.

What is the root cause of that problem?

The name-on-card field is validated with the wrong validator. In src/components/AddPaymentCard/PaymentCardForm.tsx:186, validate runs isValidLegalName(values.nameOnCard). That function (src/libs/ValidationUtils.ts:427) tests CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS, which is /^[\p{Script=Latin} ]*$/u (src/CONST/index.ts:4875) — Latin letters and spaces only, no digits. It's a human legal-name check, meant for fields like first/last name, and it was applied to the card name. Any digit fails the regex and produces the error. All three card entry points share this one validate (Transfer Ownership → WorkspaceOwnerPaymentCardForm, Subscription → Subscription/PaymentCard, and AddDebitCardPage), so the same block hits everywhere. The backend clearly allows digits since Classic saves the card, so this gate is entirely on the frontend.

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

Give the card name its own validator that allows digits, and only touch the card form. I'd add an alphanumeric regex in src/CONST/index.ts next to the existing one:

ALPHANUMERIC_AND_LATIN_CHARS: /^[\p{Script=Latin}\d ]*$/u,

Then add isValidCardName in ValidationUtils.ts that tests it, and swap line 186 in PaymentCardForm.tsx from isValidLegalName to isValidCardName. I'd keep it scoped to the card form on purpose: isValidLegalName still has three real consumers that must reject digits — FullNameStep, EnterSignerInfo/subSteps/Name, and NonUSD/SignerInfo/subSteps/Name — so broadening the shared validator would regress those person-name fields. The error copy for the card form should also read "Name can only include letters and numbers" so the message matches the new rule. tests/unit/PaymentCardFormTest.tsx currently only covers expiration formatting and has no name case, so I'd add a test that a numeric name submits without error, plus isValidCardName cases in ValidationUtilsTest.ts ('John 123' → true, 'John' → true, emoji/special chars → false).

What alternative solutions did you explore? (Optional)

Broadening isValidLegalName (or its regex) to allow digits would fix this field in one line, but it regresses the three legal-name callers above where digits should stay invalid, so I rejected it. I also checked whether this was a native or backend issue; it isn't — the validation is a pure client-side regex, and Classic accepting the same card confirms the server permits digits.

[oqildev]

Proposal

What is the root cause of that problem?

Both entry points in the report — "Add debit card" during Transfer Ownership and the subscription "Add payment card" — render the same PaymentCardForm. Its validate runs the name-on-card value through isValidLegalName:

App/src/components/AddPaymentCard/PaymentCardForm.tsx

Lines 186 to 188 in 110c724

	if (values.nameOnCard && !isValidLegalName(values.nameOnCard)) {
	errors.nameOnCard = translate(label.error.nameOnCard);
	}

isValidLegalName returns true only for strings matching CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS, i.e. letters (including Latin accented letters) and spaces — digits are excluded:

App/src/libs/ValidationUtils.ts

Lines 424 to 429 in 110c724

	/**
	* Checks that the provided legal name doesn't contain special characters
	*/
	function isValidLegalName(name: string): boolean {
	return CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS.test(name);
	}

So as soon as a name containing a digit is entered and the field blurs, isValidLegalName fails and validate sets errors.nameOnCard = translate(label.error.nameOnCard), which resolves via the CARD_LABELS map to addDebitCardPage.error.invalidName / addPaymentCardPage.error.invalidName = "Name can only include letters":

App/src/components/AddPaymentCard/PaymentCardForm.tsx

Lines 79 to 116 in 110c724

	const CARD_LABELS: CardLabels = {
	[CARD_TYPES.DEBIT_CARD]: {
	[CARD_TYPE_SECTIONS.DEFAULTS]: {
	cardNumber: 'addDebitCardPage.debitCardNumber',
	nameOnCard: 'addDebitCardPage.nameOnCard',
	expirationDate: 'addDebitCardPage.expirationDate',
	expiration: 'addDebitCardPage.expiration',
	securityCode: 'addDebitCardPage.cvv',
	billingAddress: 'addDebitCardPage.billingAddress',
	},
	[CARD_TYPE_SECTIONS.ERROR]: {
	nameOnCard: 'addDebitCardPage.error.invalidName',
	cardNumber: 'addDebitCardPage.error.debitCardNumber',
	expirationDate: 'addDebitCardPage.error.expirationDate',
	securityCode: 'addDebitCardPage.error.securityCode',
	addressStreet: 'addDebitCardPage.error.addressStreet',
	addressZipCode: 'addDebitCardPage.error.addressZipCode',
	},
	},
	[CARD_TYPES.PAYMENT_CARD]: {
	defaults: {
	cardNumber: 'addPaymentCardPage.paymentCardNumber',
	nameOnCard: 'addPaymentCardPage.nameOnCard',
	expirationDate: 'addPaymentCardPage.expirationDate',
	expiration: 'addPaymentCardPage.expiration',
	securityCode: 'addPaymentCardPage.cvv',
	billingAddress: 'addPaymentCardPage.billingAddress',
	},
	error: {
	nameOnCard: 'addPaymentCardPage.error.invalidName',
	cardNumber: 'addPaymentCardPage.error.paymentCardNumber',
	expirationDate: 'addPaymentCardPage.error.expirationDate',
	securityCode: 'addPaymentCardPage.error.securityCode',
	addressStreet: 'addPaymentCardPage.error.addressStreet',
	addressZipCode: 'addPaymentCardPage.error.addressZipCode',
	},
	},
	};

That's the wrong validator for this field. isValidLegalName exists for legal person names, where digits don't belong. A card's embossed name can legitimately contain digits (business cards like "ACME 2 LLC"), which is why the same card saved fine in Classic — the backend accepts it. Since the debit-card and subscription flows both funnel through this single validate, this one validator choice produces both reported symptoms.

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

Validation-layer fix in PaymentCardForm.validate. Replace isValidLegalName in the nameOnCard branch (

App/src/components/AddPaymentCard/PaymentCardForm.tsx

Lines 186 to 188 in 110c724

	if (values.nameOnCard && !isValidLegalName(values.nameOnCard)) {
	errors.nameOnCard = translate(label.error.nameOnCard);
	}

) with a check that allows digits, matching what the backend/Classic already accepts.

I'd add a isValidCardName helper in ValidationUtils backed by a regex that permits letters, digits, spaces and the punctuation that appears on cards (., -, ') while still rejecting emojis and special characters — modeled on the existing isValidPersonName (

App/src/libs/ValidationUtils.ts

Lines 431 to 436 in 110c724

	/**
	* Checks that the provided name doesn't contain special characters or numbers
	*/
	function isValidPersonName(value: string) {
	return /^[^\d^!#$%*=<>;{}"]+$/.test(value);
	}

), which already excludes only digits/special chars, so I'd drop the \d exclusion for the card variant. Reusing isValidCompanyName (emoji-only rejection, digits allowed) is a lighter alternative if we don't want new copy.

This only loosens an over-strict client check, so there's no offline/optimistic-rollback concern — the backend already accepts these names. The addPaymentCardForm error copy stays as-is for the cases that remain invalid (emojis/special characters); I would not touch isValidLegalName itself.

What alternative solutions did you explore? (Optional)

Only rewording the error to "Name can only include letters and numbers" without touching the validator. Rejected: the regex at

App/src/libs/ValidationUtils.ts

Lines 427 to 429 in 110c724

	function isValidLegalName(name: string): boolean {
	return CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS.test(name);
	}

still rejects digits, so the name stays blocked and the copy would be false.

Relaxing isValidLegalName directly. Rejected: it's shared by legal-name forms where excluding digits is intentional, so widening its regex would leak digit-tolerance into unrelated fields. Scoping to a card-specific validator keeps the blast radius to PaymentCardForm.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 14:39:05 UTC.

Proposal

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

When adding a payment/debit card (via Transfer Ownership, the subscription add-card flow, or Add Debit Card), typing a "Name on card" value that contains both letters and numbers (e.g. a business card name like ACME 2 LLC or JOHN SMITH 3) triggers the validation error "Name can only include letters" and blocks the card from being added. Classic accepts these names, and payment processors legitimately allow digits in the embossed cardholder name, so the field is over-restrictive.

What is the root cause of that problem?

All three reported flows render the same shared component, PaymentCardForm, and its single validate function is what rejects the name. The name-on-card check calls isValidLegalName, which is the wrong validator for a cardholder name:

App/src/components/AddPaymentCard/PaymentCardForm.tsx

Lines 186 to 188 in 110c724

	if (values.nameOnCard && !isValidLegalName(values.nameOnCard)) {
	errors.nameOnCard = translate(label.error.nameOnCard);
	}

isValidLegalName in src/libs/ValidationUtils.ts (lines 427-429) tests the value against CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS, which only permits Latin-script letters and spaces — no digits, no punctuation:

ALPHABETIC_AND_LATIN_CHARS: /^[\p{Script=Latin} ]*$/u,

App/src/CONST/index.ts

Line 4875 in 110c724

ALPHABETIC_AND_LATIN_CHARS: /^[\p{Script=Latin} ]*$/u,

Because \p{Script=Latin} matches no digit characters, any name containing 0-9 fails the test, and errors.nameOnCard is set to label.error.nameOnCard — which resolves to addDebitCardPage.error.invalidName / addPaymentCardPage.error.invalidName, both defined as the literal string 'Name can only include letters' in src/languages/en.ts (lines 2520 and 2543). That is exactly the copy the user sees. The debit variant (AddDebitCardPage), the subscription variant (settings/Subscription/PaymentCard), and the Transfer Ownership variant (WorkspaceOwnerPaymentCardForm) all mount this same PaymentCardForm, so they all share this one broken check — which is why the issue reproduces in both the Transfer Ownership and subscription flows.

The reason we can't just loosen isValidLegalName globally is that it is intentionally reused by genuine legal-name fields where alphabetic-only is correct: FullNameStep.tsx (lines 100 and 117), ReimbursementAccount/EnterSignerInfo/subSteps/Name.tsx (line 28), and ReimbursementAccount/NonUSD/SignerInfo/subSteps/Name.tsx (line 30). A legal signer name should not contain digits, so relaxing the shared validator would regress those forms. The bug is that a person-name validator was applied to a card-name field, not that the validator itself is wrong.

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

Scope the fix to the card-name field only by introducing a card-specific validator and using it at the single call site. Add isValidCardName to ValidationUtils.ts backed by a new CONST.REGEX entry that keeps the existing accented-Latin support (so José still works) while allowing digits, spaces, and the punctuation that legitimately appears in embossed names:

// CONST/index.ts REGEX
CARD_NAME: /^[\p{Script=Latin}0-9 .,'&-]*$/u,
// ValidationUtils.ts
function isValidCardName(name: string): boolean {
    return CONST.REGEX.CARD_NAME.test(name);
}

Then change line 186 of PaymentCardForm.tsx from isValidLegalName(values.nameOnCard) to isValidCardName(values.nameOnCard). Because this touches only the shared card form's validate, all three flows are fixed at once, and the legal-name fields listed above keep calling isValidLegalName untouched — no regression risk. Since the error copy "Name can only include letters" is now inaccurate, update addDebitCardPage.error.invalidName and addPaymentCardPage.error.invalidName (and their equivalents in the other language files under src/languages/) to something like "Please enter a valid name". This is a pure client-side validation relaxation, so it works offline with no API implications; QA should verify letters+digits (e.g. ACME 2 LLC) now passes while genuinely invalid characters (e.g. <, ;, {}) still error, and that the signer/full-name legal fields remain digit-restricted.

What alternative solutions did you explore? (Optional)

Reusing the existing CONST.REGEX.ALPHANUMERIC_WITH_SPACE_AND_HYPHEN (/^[A-Za-z0-9 -]+$/) instead of a new regex — rejected because it is ASCII-only and would newly reject accented Latin cardholder names (e.g. José, Müller) that the current code accepts, trading one over-restriction for another.

[samranahm]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-08 03:00:35 UTC.

Proposal

What is the root cause of that problem?

When a user adds a payment card (Transfer Ownership or subscription), the Name on card field shows "Name can only include letters" if the name contains a digit.

The shared form is PaymentCardForm.tsx. Its validate callback checks the name with isValidLegalName, which uses CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS — Latin letters and spaces only, no digits.

Real card names often include numbers (and sometimes apostrophes). Classic accepts them. New Expensify blocks them because the wrong validator is used for this field.

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

1. Add a card-name regex in CONST/index.ts:

CARD_NAME: /^[\p{Script=Latin}\d' -]+$/u,

This allows Latin letters (including accented ones), digits, spaces, hyphens, and apostrophes, same Unicode approach as ALPHABETIC_AND_LATIN_CHARS, plus digits and '.

2. Add isValidCardName in ValidationUtils.ts:

function isValidCardName(name: string): boolean {
    return CONST.REGEX.CARD_NAME.test(name);
}

3. In PaymentCardForm.tsx, swap isValidLegalName for isValidCardName on nameOnCard:

if (values.nameOnCard && !isValidCardName(values.nameOnCard)) {
    errors.nameOnCard = translate(label.error.nameOnCard);
}

**4. Update error copy in all locals from "Name can only include letters" to "Name contains invalid characters" so the message matches the relaxed rule.

This keeps required-field validation as-is and only changes format checking for the card name field. Names like John Smith 123, O'Brien, or José García 2 pass; characters like @ or _ still fail.

What alternative solutions did you explore? (Optional)

• Reusing CONST.REGEX.ALPHANUMERIC_WITH_SPACE_AND_HYPHEN (/^[A-Za-z0-9 -]+$/) — fixes digits but still rejects accented Latin names and apostrophes.

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Solution Verification Result

Kapture.2026-07-08.at.07.59.24.mp4

[lorretheboy]

Proposal

What is the root cause of that problem?

Every "add a card" flow (Transfer Ownership payment card, subscription payment card, and the Add Debit Card flow) mounts the shared PaymentCardForm. Its validate runs the name-on-card value through isValidLegalName:

App/src/components/AddPaymentCard/PaymentCardForm.tsx

Lines 186 to 188 in 110c724

	if (values.nameOnCard && !isValidLegalName(values.nameOnCard)) {
	errors.nameOnCard = translate(label.error.nameOnCard);
	}

isValidLegalName only accepts strings matching CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS, i.e. Latin letters and spaces — digits are excluded:

App/src/libs/ValidationUtils.ts

Lines 427 to 429 in 110c724

	function isValidLegalName(name: string): boolean {
	return CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS.test(name);
	}

App/src/CONST/index.ts

Line 4875 in 110c724

ALPHABETIC_AND_LATIN_CHARS: /^[\p{Script=Latin} ]*$/u,

So the moment a name containing a digit is entered and the field blurs, the check fails and the form shows "Name can only include letters" and blocks submission — even though the backend/Classic accept digits in the embossed name. The deeper mismatch is one of mechanism: the NAME_ON_CARD input is a free-text field with no input handling, so any character can be typed and the form only complains after the fact. The two other structured card fields in this same form don't work that way — they sanitize what the user types in real time via onChangeText so an invalid character can never land in the value.

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

Bring the name-on-card field in line with how this same form already treats the card-number field: sanitize on input instead of validating on blur.

The card-number field is already controlled and filters disallowed characters as the user types, so the value is always valid and no error copy is needed:

App/src/components/AddPaymentCard/PaymentCardForm.tsx

Lines 225 to 248 in 110c724

	const onChangeCardNumber = useCallback((newValue: string) => {
	// Replace all characters that are not spaces or digits
	let validCardNumber = newValue.replaceAll(/[^\d ]/g, '');
	// Gets only the first 16 digits if the inputted number have more digits than that
	validCardNumber = validCardNumber.match(/(?:\d *){1,16}/)?.[0] ?? '';
	// Remove all spaces to simplify formatting
	const cleanedNumber = validCardNumber.replaceAll(' ', '');
	// Check if the number is a potential Amex card (starts with 34 or 37 and has up to 15 digits)
	const isAmex = /^3[47]\d{0,13}$/.test(cleanedNumber);
	// Format based on Amex or standard 4-4-4-4 pattern
	if (isAmex) {
	// Format as 4-6-5 for Amex
	validCardNumber = cleanedNumber.replaceAll(/(\d{1,4})(\d{1,6})?(\d{1,5})?/g, (match, p1, p2, p3) => [p1, p2, p3].filter(Boolean).join(' '));
	} else {
	// Format as 4-4-4-4 for non-Amex
	validCardNumber = cleanedNumber.match(/.{1,4}/g)?.join(' ') ?? '';
	}
	setCardNumber(validCardNumber);
	}, []);

Apply the same pattern to NAME_ON_CARD:

1. Make the name field controlled and add an onChangeName handler that strips any character outside the set a card name can legitimately contain (accented Latin letters, digits, spaces, and the punctuation that appears on embossed names), e.g. newValue.replaceAll(/[^\p{Script=Latin}0-9 .,'&-]/gu, ''). This is the direct analogue of onChangeCardNumber and keeps accented names like José working while allowing ACME 2 LLC.

2. Wire that handler onto the existing NAME_ON_CARD input, which currently has no onChangeText/value:

App/src/components/AddPaymentCard/PaymentCardForm.tsx

Lines 279 to 290 in 110c724

	<InputWrapper
	InputComponent={TextInput}
	inputID={INPUT_IDS.NAME_ON_CARD}
	defaultValue={data?.nameOnCard}
	label={translate(label.defaults.nameOnCard)}
	aria-label={translate(label.defaults.nameOnCard)}
	role={CONST.ROLE.PRESENTATION}
	containerStyles={[styles.mt5]}
	spellCheck={false}
	forwardedFSClass={CONST.FULLSTORY.CLASS.MASK}
	autoComplete="cc-name"
	/>

3. Remove the now-redundant isValidLegalName name check from validate (the required-field check for NAME_ON_CARD in REQUIRED_FIELDS stays):

App/src/components/AddPaymentCard/PaymentCardForm.tsx

Lines 186 to 188 in 110c724

	if (values.nameOnCard && !isValidLegalName(values.nameOnCard)) {
	errors.nameOnCard = translate(label.error.nameOnCard);
	}

Because the value can no longer contain a disallowed character, the "Name can only include letters" error becomes unreachable and there is no copy to keep accurate — the field simply refuses bad characters as they're typed, exactly like the card number and expiration fields already do. isValidLegalName is untouched, so the legal-name forms (FullNameStep, signer-info steps) keep rejecting digits. All three card flows are fixed at once since they share this one component.

What alternative solutions did you explore? (Optional)

• Replacing isValidLegalName at line 186 with a new card-specific blur-time validator (e.g. isValidCardName/isValidPaymentCardName) that permits digits, and rewording the invalidName copy to "Name can only include letters and numbers." This works, but it keeps the after-the-fact error model and adds a new validator + new copy string in every language file; the input-sanitization approach removes the misapplied validator instead of adding another and matches the pattern already established for the sibling fields in this exact form.
• Loosening ALPHABETIC_AND_LATIN_CHARS / isValidLegalName directly. Rejected: that regex backs the legal-name/signer-info steps where excluding digits is intentional, so widening it would regress unrelated fields.

[dilshodmackbook-sketch]

Proposal

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

When adding a payment/debit card (Transfer Ownership flow or Subscription > Add payment card), entering a "Name on card" that contains a number shows the error "Name can only include letters", even though the same card name is accepted in Classic.

What is the root cause of that problem?

The "Name on card" field in PaymentCardForm (used by both the debit-card and subscription payment-card flows) is validated with isValidLegalName:

App/src/components/AddPaymentCard/PaymentCardForm.tsx

Lines 186 to 188 in 110c724

	if (values.nameOnCard && !isValidLegalName(values.nameOnCard)) {
	errors.nameOnCard = translate(label.error.nameOnCard);
	}

isValidLegalName tests the value against CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS:

App/src/libs/ValidationUtils.ts

Lines 427 to 429 in 110c724

	function isValidLegalName(name: string): boolean {
	return CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS.test(name);
	}

App/src/CONST/index.ts

Line 4875 in 110c724

ALPHABETIC_AND_LATIN_CHARS: /^[\p{Script=Latin} ]*$/u,

That character class is /^[\p{Script=Latin} ]*$/u. The mechanism here is that digits belong to Unicode Script=Common, not Script=Latin, so 0-9 can never match this class — any digit fails the test and the form sets the invalidName error ("Name can only include letters").

isValidLegalName is a validator for legal person names (it's also used by FullNameStep and the bank-account signer-info steps, where digits should indeed be rejected). The card form reuses it for a cardholder name, but names embossed on cards legitimately contain numbers (e.g. business cards like 3M CORP, or JOHN SMITH 2), and Classic accepts them.

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

Give the card name its own validator that extends the existing charset with digits — keeping \p{Script=Latin} so accented names (José García) that pass today keep passing, with no regression.

Add a regex to CONST.REGEX:

ALPHANUMERIC_AND_LATIN_CHARS: /^[\p{Script=Latin}0-9 ]*$/u,

Add a dedicated validator in ValidationUtils.ts:

/**
 * Checks that the provided card name contains only letters, numbers, and spaces
 */
function isValidCardName(name: string): boolean {
    return CONST.REGEX.ALPHANUMERIC_AND_LATIN_CHARS.test(name);
}

Use it in PaymentCardForm.tsx:

if (values.nameOnCard && !isValidCardName(values.nameOnCard)) {
    errors.nameOnCard = translate(label.error.nameOnCard);
}

And update the copy for addDebitCardPage.error.invalidName and addPaymentCardPage.error.invalidName in en.ts (plus the other language files) so the message matches the new rule:

invalidName: 'Name can only include letters and numbers',

This keeps isValidLegalName untouched for the legal-name flows, so nothing else changes behavior. If we also want to accept common cardholder punctuation (hyphens, apostrophes, periods), the character class extends trivially — happy to align it with whatever the backend accepts.

What specific scenarios should we cover in automated tests to prevent reintroducing the issue in the future?

Unit tests for isValidCardName in tests/unit/ValidationUtilsTest.ts:

• Accepts names with digits: JOHN SMITH 2, 3M CORP
• Accepts plain and accented Latin names: John Smith, José García (regression guard — these pass today and must keep passing)
• Rejects special characters (John@Smith), emoji, and non-Latin scripts

And a form-level test that PaymentCardForm validation produces no nameOnCard error for a name containing digits.

What alternative solutions did you explore? (Optional)

• Add 0-9 to ALPHABETIC_AND_LATIN_CHARS itself — rejected because that regex backs isValidLegalName, which is also used by FullNameStep and the reimbursement-account signer-info name steps, where digits must remain invalid.
• Reuse an ASCII-only pattern such as the existing ALPHANUMERIC_WITH_SPACE_AND_HYPHEN (/^[A-Za-z0-9 -]+$/) or an inline /^[a-zA-Z0-9 ]*$/ — simpler, but it would reject accented Latin names like José that the current validation accepts, introducing a regression for names that work today.
• Drop the character-class check for the card name entirely and keep only the required-field validation (the backend accepted the card in Classic) — simplest, but we'd lose early feedback for clearly invalid input like emoji, so a dedicated validator feels safer.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-07 14:39:17 UTC.

Proposal

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

Entering a name that contains any digit in the "Name on card" field (add payment card during Transfer Ownership, and also the subscription add-card page) shows the validation error "Name can only include letters" as soon as the field loses focus, even though card names with numbers are valid and the exact same card is accepted in Expensify Classic.

What is the root cause of that problem?

This is a purely client-side over-validation. The evidence chain:

1. All three "add a card" surfaces render the one shared form component PaymentCardForm: the Transfer Ownership payment step (WorkspaceOwnerPaymentCardForm.tsx#L88-L90), the subscription add-payment-card page (PaymentCard/index.tsx#L124-L125), and the wallet add-debit-card page (AddDebitCardPage.tsx#L70-L72).

2. That form's shared validate gates the name field with isValidLegalName (PaymentCardForm.tsx#L186-L188).

3. isValidLegalName tests CONST.REGEX.ALPHABETIC_AND_LATIN_CHARS (ValidationUtils.ts#L427-L429), which is /^[\p{Script=Latin} ]*$/u (CONST/index.ts#L4875) — it matches ONLY Latin-script letters and spaces. Any digit fails the regex, so "John Smith 2" is rejected.

4. Both card variants map the failure to the same copy — debit: PaymentCardForm.tsx#L90 → en.ts#L2520; payment: PaymentCardForm.tsx#L108 → en.ts#L2543.

The STRUCTURAL cause: the card form borrowed a person's-legal-name validator — written for the bank-account/signer full-name flows, where digits are correctly banned — for the "name on card" field, whose domain is different (embossed card names legitimately contain digits, e.g. business cards). This chain explains every symptom detail: the error appears on blur with no network call (validation is client-side), it reproduces identically on the Transfer Ownership and subscription surfaces (one shared validate), and the same card is accepted by Classic (the backend accepts digits — only this NewDot form rejects them).

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

Allow digits at the single convergence point all three surfaces read:

1. Add a card-name regex to CONST.REGEX next to ALPHABETIC_AND_LATIN_CHARS:

ALPHANUMERIC_AND_LATIN_CHARS: /^[\p{Script=Latin}0-9 ]*$/u,

2. Add a dedicated validator in ValidationUtils.ts beside isValidLegalName:

function isValidCardName(name: string): boolean {
    return CONST.REGEX.ALPHANUMERIC_AND_LATIN_CHARS.test(name);
}

3. Swap the call at PaymentCardForm.tsx#L186 to !isValidCardName(values.nameOnCard) — this fixes all three surfaces (wallet debit card, subscription, transfer ownership) in one place.
4. Update the now-stale copy for addDebitCardPage.error.invalidName and addPaymentCardPage.error.invalidName to "Name can only include letters and numbers" in en.ts and every locale mirror (es, de, fr, it, ja, nl, pl, pt-BR, zh-hans).

Regression safety in one sentence: isValidLegalName and its regex are untouched, so the bank-account legal-name flows keep their intentionally stricter letters-only rule.

Why the obvious one-line fix does NOT work: the spot-fix is to add 0-9 to ALPHABETIC_AND_LATIN_CHARS (or loosen isValidLegalName itself), but that validator is shared by the VBA/signer legal-name steps — FullNameStep.tsx#L100 and #L117, NonUSD SignerInfo Name.tsx#L30, and EnterSignerInfo Name.tsx#L28 — where a legal first/last name like "John 123" must stay rejected for bank compliance, so loosening the shared validator silently breaks those flows. Equally, replacing the regex with plain ASCII [A-Za-z0-9 ] would newly reject accented card names like "Shāhrukh" that \p{Script=Latin} deliberately supports — the digits must be added alongside the Unicode Latin class, not instead of it.

What alternative solutions did you explore? (Optional)

1. Loosen isValidLegalName / ALPHABETIC_AND_LATIN_CHARS directly — rejected: it is shared with the legal-name flows listed above; digits would leak into bank-account signer names.
2. Drop the client-side name check and let the backend decide — rejected: we lose instant field-level feedback, and Classic parity shows a simple allow-digits rule is all that's needed.
3. Also allow common embossed punctuation (., ', -, /) — plausible follow-up (e.g. "O'Brien"), but the issue and Classic parity only establish digits, so I'd keep the scope to digits and note this for the reviewer rather than widen the charset speculatively.

[abbasifaizan70]

Proposal

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

Entering a "Name on card" that contains a digit (e.g. ACME 2 LLC, JOHN SMITH 2) shows "Name can only include letters" and blocks adding the card, even though Classic accepts the same card.

What is the root cause of that problem?

PaymentCardForm.tsx (line 186) validates nameOnCard with isValidLegalName, whose regex (ALPHABETIC_AND_LATIN_CHARS, Latin letters and spaces only) was written for legal person-name fields. A cardholder name is a different domain: embossed names routinely contain digits and punctuation, and can be business names, not just person names — the repro string ACME 2 LLC is literally a company name. Since all three add-card surfaces (Transfer Ownership, subscription, wallet debit card) share this one validate, the wrong validator produces every reported symptom, and the backend is not involved (Classic parity proves it accepts these names).

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

Reuse the validator the codebase already has for exactly this class of names, instead of inventing a new one:

1. In PaymentCardForm.tsx:186, replace isValidLegalName(values.nameOnCard) with the existing isValidCompanyName(values.nameOnCard) (src/libs/ValidationUtils.ts:413). It rejects only emojis (CONST.REGEX.ALL_EMOJIS) and already validates the app's business-name fields (NameBusiness.tsx:40, NonUSD Name.tsx:32) — names that, like card names, legitimately contain digits, accents, apostrophes, hyphens, ampersands, and slashes.
2. Update the two invalidName strings in en.ts (lines ~2520 and ~2543) and their locale mirrors to match the actual rule, e.g. "Please enter a valid name" — mirroring the existing bankAccount.error.companyName copy pattern ("Please enter a valid business name").
3. Tests: ACME 2 LLC, O'BRIEN, MR & MRS SMITH, JEAN-LUC 3 produce no nameOnCard error; an emoji still errors; and isValidLegalName keeps rejecting digits so the signer/full-name flows are provably untouched.

How this differs from the existing proposals, and why it's the better fit. Every proposal so far introduces a brand-new regex plus a new ValidationUtils helper — and tellingly, they disagree with each other about the charset (letters+digits only; letters+digits+.,'&-; any-script \p{L}\p{N}.'-). That disagreement is the point: there is no client-side spec to derive the charset from, so each variant hand-picks one and still rejects a legitimate embossed name the backend accepts — the digits-only variants reject O'BRIEN and MR & MRS SMITH exactly the way today's code rejects ACME 2 LLC, recreating this same bug for the next character class. The server is the only authority on what a card name may contain, and this very form already carries a warning born from that lesson — the zip-code check at lines 209–211 is marked "do not touch — this can block users from adding payment cards" after issue #55493, an earlier case of client validation on this form outrunning the backend. Reusing isValidCompanyName keeps a cheap guard against clearly-broken input (emojis) while adding zero new validation surface: no new regex to maintain, no new helper, no new charset to get wrong. One proposal mentioned this reuse in passing as a "lighter alternative"; this proposal makes the affirmative case that it is the correct primary fix, and completes it with the copy and test changes that aside omitted.

What alternative solutions did you explore? (Optional)

• A new card-name regex/validator (the approach of the other proposals) — workable, but any charset we invent client-side will eventually disagree with the backend again; see above.
• Loosening isValidLegalName/ALPHABETIC_AND_LATIN_CHARS — regresses the signer-info and full-legal-name flows where digit rejection is intentional.
• Dropping the name check entirely (required-field only) — closest to backend truth, but loses the cheap emoji guard that isValidCompanyName provides for free, with no upside over reusing it.
• Sanitizing input on onChangeText like the card-number field — already proposed by another contributor; silently deleting characters a user types into a name field is also worse UX than an explicit error for the rare invalid case.