docs: document business beneficiary requirements

[pengying]

Summary

• Add a Business beneficiaries table to mintlify/snippets/external-accounts.mdx listing required fields per destination currency
• Add a Note callout covering the originator-side registrationNumber requirement for the Tazapay corridors (GBP, INR, BRL, DKK, PHP, HKD, IDR, MYR, SGD, THB, VND, AED)
• Reword the section lead-in to reference both tables (individual + business)

Test plan

• make build succeeds
• mint dev renders the new table and callouts without acorn errors

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ignored	Preview	Jun 2, 2026 12:32am

[pengying]

• docs: document business beneficiary requirements #535 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Greptile Summary

This PR adds a new "Business beneficiaries" section to the external accounts snippet, documenting the minimum required fields (legalName, address, registrationNumber, taxId) per destination currency, and adds a note that Tazapay-corridor originators must supply registrationNumber.

• New business beneficiaries table groups required fields by currency across five corridor groups (USD/MXN, EUR, Tazapay, African currencies), and is accompanied by an <Info> callout defining registrationNumber and taxId.
• <Note> callout highlights an originator-side registrationNumber requirement for 12 Tazapay corridors (GBP, INR, BRL, DKK, PHP, HKD, IDR, MYR, SGD, THB, VND, AED), but this is placed inside the beneficiary-fields section where sender-side readers are unlikely to find it.
• EIN example in the registrationNumber definition is inaccurate — EIN is a US federal tax identifier, not a company registration number, and listing it there risks developers routing it into the wrong field.

Confidence Score: 3/5

Documentation-only change that introduces a new required-fields table; two content issues need resolution before the docs accurately guide developers.

The EIN example in the registrationNumber definition is factually misleading — EIN is a US tax identifier, not a registration number, so developers following the docs could wire up the wrong field and get unexpected API rejections. Additionally, the originator registrationNumber requirement for Tazapay corridors is documented inside the beneficiary section, where the sending-side developer is unlikely to look, creating a discoverability gap that would cause silent transaction failures.

mintlify/snippets/external-accounts.mdx — specifically the new Info and Note callouts added in the Business beneficiaries section.

Important Files Changed

Filename	Overview
mintlify/snippets/external-accounts.mdx	Adds a Business beneficiaries required-fields table and related callouts; contains a potentially inaccurate EIN example (EIN is a tax ID, not a registration number) and places an originator-side requirement inside a beneficiary-focused section.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Business Beneficiary] --> B{Destination Currency?}
    B --> C[USD / MXN]
    B --> D[EUR]
    B --> E["GBP, INR, BRL, DKK, PHP, HKD, IDR, MYR, SGD, THB, VND, AED"]
    B --> F["NGN, ZAR, KES, TZS, RWF, ZMW, UGX, BWP, MWK, XOF, XAF"]
    C --> C1["Required: legalName, address"]
    D --> D1["Required: legalName, address, registrationNumber"]
    E --> E1["Required: legalName, address"]
    E1 --> E2["Originator must also provide registrationNumber"]
    F --> F1["Required: legalName, address, registrationNumber, taxId"]

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
mintlify/snippets/external-accounts.mdx:916
The EIN (Employer Identification Number) is a federal **tax** identification number issued by the IRS — it is not a company registration or incorporation number. US businesses register at the state level with no single federal registration identifier. Listing EIN as the canonical example for `registrationNumber` could cause developers to pass their EIN into the wrong field, potentially triggering validation failures in corridors that distinguish between the two. A more accurate example might be a state entity number, or the example could simply be omitted for the US and clarified that `registrationNumber` and `taxId` may overlap per jurisdiction.

```suggestion
  `registrationNumber` is the business's official registration or incorporation number (e.g., CNPJ in Brazil, company registration number in the UK). `taxId` is the business's tax identification number (e.g., EIN in the US) where it differs from the registration number.
```

### Issue 2 of 2
mintlify/snippets/external-accounts.mdx:911-913
**Originator requirement buried in beneficiary section**

This `<Note>` describes an originator/sender requirement (`registrationNumber` on the sending business), but it appears inside the "Business beneficiaries" section, which developers read to understand what fields the **receiving** business needs. A developer building the payer side of a Tazapay corridor may not look here — and if they miss the requirement, their transactions will fail. Consider moving this callout to wherever originator/sender fields are documented, or at minimum using a `<Warning>` (per the style guide, `<Warning>` is for "critical information about potential issues") to make sure it isn't skimmed.

_{Reviews (1): Last reviewed commit: "docs: document business beneficiary requ..." | Re-trigger Greptile}

[greptile-apps]

The EIN (Employer Identification Number) is a federal tax identification number issued by the IRS — it is not a company registration or incorporation number. US businesses register at the state level with no single federal registration identifier. Listing EIN as the canonical example for registrationNumber could cause developers to pass their EIN into the wrong field, potentially triggering validation failures in corridors that distinguish between the two. A more accurate example might be a state entity number, or the example could simply be omitted for the US and clarified that registrationNumber and taxId may overlap per jurisdiction.

Suggested change

	`registrationNumber` is the business's official registration or incorporation number (e.g., EIN in the US, CNPJ in Brazil, company registration number in the UK). `taxId` is the business's tax identification number where it differs from the registration number.
	`registrationNumber` is the business's official registration or incorporation number (e.g., CNPJ in Brazil, company registration number in the UK). `taxId` is the business's tax identification number (e.g., EIN in the US) where it differs from the registration number.

Prompt To Fix With AI

This is a comment left during a code review.
Path: mintlify/snippets/external-accounts.mdx
Line: 916

Comment:
The EIN (Employer Identification Number) is a federal **tax** identification number issued by the IRS — it is not a company registration or incorporation number. US businesses register at the state level with no single federal registration identifier. Listing EIN as the canonical example for `registrationNumber` could cause developers to pass their EIN into the wrong field, potentially triggering validation failures in corridors that distinguish between the two. A more accurate example might be a state entity number, or the example could simply be omitted for the US and clarified that `registrationNumber` and `taxId` may overlap per jurisdiction.

```suggestion
  `registrationNumber` is the business's official registration or incorporation number (e.g., CNPJ in Brazil, company registration number in the UK). `taxId` is the business's tax identification number (e.g., EIN in the US) where it differs from the registration number.
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Originator requirement buried in beneficiary section

This <Note> describes an originator/sender requirement (registrationNumber on the sending business), but it appears inside the "Business beneficiaries" section, which developers read to understand what fields the receiving business needs. A developer building the payer side of a Tazapay corridor may not look here — and if they miss the requirement, their transactions will fail. Consider moving this callout to wherever originator/sender fields are documented, or at minimum using a <Warning> (per the style guide, <Warning> is for "critical information about potential issues") to make sure it isn't skimmed.

Prompt To Fix With AI

This is a comment left during a code review.
Path: mintlify/snippets/external-accounts.mdx
Line: 911-913

Comment:
**Originator requirement buried in beneficiary section**

This `<Note>` describes an originator/sender requirement (`registrationNumber` on the sending business), but it appears inside the "Business beneficiaries" section, which developers read to understand what fields the **receiving** business needs. A developer building the payer side of a Tazapay corridor may not look here — and if they miss the requirement, their transactions will fail. Consider moving this callout to wherever originator/sender fields are documented, or at minimum using a `<Warning>` (per the style guide, `<Warning>` is for "critical information about potential issues") to make sure it isn't skimmed.

How can I resolve this? If you propose a fix, please make it concise.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
Grid	🟢 Ready	View Preview	Jun 2, 2026, 12:40 AM