Capture the merchant identity
Collect the legal name, trading name, country, tax ID, registration number and registered address.
MERCHANT ONBOARDING & ACQUIRING
Merchant onboarding: verify the legal business.
Add company and tax-ID checks to merchant onboarding. Match legal names, VAT numbers and EINs before underwriting, activation and settlement review.
START WITHMerchant identity + country + tax IDREVIEWResolved legal entity + identity discrepancies
Design the control around your systems and policy.Define countries, inputs, match rules, exceptions, evidence and delivery before integration.
Reviewed
THE PRACTICAL ANSWER
Where does company verification fit in merchant onboarding?
Verify the merchant's legal business near the start of the onboarding process, before underwriting and settlement setup. Collect the legal and trading names separately, then reconcile the country, registration number, VAT number or EIN and address. VATFind provides company-record evidence that the application can use to select the correct entity and investigate differences before the remaining merchant-risk checks.
- A merchant applies under a trading name that differs from the contracting company.
- The merchant’s submitted tax ID must be reconciled with company registration details.
- An acquirer, PSP or marketplace needs consistent legal-entity data across onboarding systems.
THE WORKFLOW
The merchant onboarding process
Resolve the legal business
Match the submitted identifiers to the most likely source-labelled company record.
Compare application fields
Surface legal-name, identifier, address and status differences for underwriting review.
Pass evidence downstream
Send the resolved entity and exception signals into KYB, risk and merchant-activation rules.
WHAT VATFIND DOES
VATFind verifies which legal company is associated with the VAT number or EIN.
VATFind takes the submitted identifier and country, matches it to a source-labelled company record, and returns the legal name, registration number, address, company context, source and retrieval time. The workflow receives an explicit match, discrepancy, ambiguity, no-match or unavailable state instead of a generic pass/fail answer.
Evidence meaning: a verified association means the submitted VAT number or EIN is linked to the returned company record. It is not, by itself, confirmation of current tax-registration status, tax compliance or approval of the wider transaction.
For API checks, use vat_number outside the US and tax_identifier for US EINs. Optional fields can be absent when a source does not provide them.
- 01Merchant legal entity
- The registered company associated with the submitted business identity.
- 02Tax-ID association
- Whether the number is linked to the returned company record.
- 03Registration context
- Company number, legal form, address, incorporation date and status when available.
- 04Application discrepancies
- Differences between submitted fields and the resolved company record.
- 05Source evidence
- Source and retrieval context for underwriting and audit workflows.
CHOOSE THE RIGHT APPROACH
Keep the merchant, trading name and settlement party clear
Trading identity
The store name or website tells you how the business presents itself. Keep it alongside the legal company.
Legal merchant
The entity entering the processing agreement needs a consistent company record and jurisdiction-specific identifiers.
Settlement party
The destination account and payee require separate verification and approval within your payment workflow.
CONTROL OWNERSHIP
Give each team one clear responsibility.
A reliable workflow names who owns the input, who interprets the company evidence and who makes the wider decision. That separation prevents a data result from becoming an unexplained approval.
Merchant operations
Resolve the contracting business before activation and settlement setup.
Underwriting
Interpret identity discrepancies inside the wider merchant risk policy.
Payments compliance
Ensure subsequent ownership, sanctions and risk checks use the same legal entity.
DECISION DESIGN
Define the evidence and action at each stage.
| Stage | Evidence to retain | Controlled action |
|---|---|---|
| Merchant application | Legal and trading names, country, registration number, tax ID and address. | Require structured business fields instead of one free-text company name. |
| Entity resolution | Matched company, incorporation context, returned identifiers and discrepancies. | Create the canonical merchant party or escalate ambiguity. |
| Underwriting handoff | Resolved entity ID, source, retrieval time and exception reasons. | Run ownership, product, geography, transaction and settlement controls against that entity. |
EXAMPLE WORKFLOW
A marketplace seller applies under its store name
A seller's store name differs from the company on its onboarding documents. Search the submitted company and tax ID in the registration country, then compare the returned address and registration number. Ask the seller to explain the store-to-company relationship when it is unclear. Pass the resolved legal company into underwriting and preserve the store name as a separate field. This gives the next reviewer a consistent identity without assuming the trading-name difference is fraudulent.
See the API requests and responsesIMPLEMENTATION CHECKLIST
Merchant onboarding checklist
- Map trading names and websites to—but do not replace—the contracting legal entity.
- Keep the application value beside the normalised company field.
- Define policy for branches, sole traders and companies with several registrations.
- Prevent an identity match from being interpreted as underwriting approval.
- Recheck identity when the settlement entity or legal details change.
WHAT TO MEASURE
Prove the control is useful.
Track operating quality rather than claiming that a company match guarantees the downstream outcome.
- Merchants resolved before activation
- Applications escalated for true identity ambiguity
- Downstream checks linked to one canonical merchant entity
READ THE RESULT CORRECTLY
Company identity is not merchant risk approval.
A company-record match does not establish transaction risk, expected volumes, MCC suitability, sanctions clearance, beneficial ownership, bank-account ownership or the merchant’s right to process payments. Those controls remain separate.
Review data and limitationsFREQUENTLY ASKED QUESTIONS
Merchant onboarding questions
Why is a tax ID useful in merchant onboarding?
It gives the workflow a jurisdiction-specific identifier that can help connect the application to the registered legal entity instead of relying on a trading name alone.
Does a match mean the merchant should be approved?
No. It resolves company identity only. Underwriting must still assess ownership, products, geography, transaction risk, sanctions, fraud and other policy requirements.
What if the trading name and legal name differ?
Treat the difference as something to explain, not an automatic failure. Confirm that the trading business belongs to the resolved contracting entity.
Can the workflow support API onboarding?
Yes, subject to agreed country coverage, input fields, matching rules, exception handling and evidence requirements.
What company details should a merchant onboarding checklist collect?
Collect the legal name, trading name, registration country, company number, tax identifier and registered address. Keep the applicant and settlement details in separate fields so later checks can assess their relationship to the business.
How can a payment service provider automate merchant verification?
Connect the application to the REST API, map the returned company fields to the submitted data, and define which differences require review. Use the resolved entity in subsequent risk checks; a company match should not automatically authorise merchant activation.