Normalization vs. merchant identification: why the distinction matters.

Normalization changes text; identification makes a claim. Removing processor syntax, repeated punctuation, reference fragments, and casing noise can produce a better display candidate. It does not automatically establish which company, storefront, seller, or legal entity created the charge.

PAYPAL *ACME-SUPPLY

A normalizer can detect the PayPal wrapper and extract “Acme Supply.” That is immediately useful as a fallback label. Identification requires more: a reviewed alias or merchant record, evidence for the relevant country or context, and enough confidence to attach stronger metadata.

Two evidence levels

{
  "normalization": {
    "processor_hint": "paypal",
    "identity_candidate": "Acme Supply",
    "signals": ["applied_processor_paypal_star"]
  },
  "identification": {
    "reviewed_match": false,
    "display_name": "Acme Supply",
    "website": null,
    "confidence": 0.56,
    "warnings": ["local_merchant_identity_not_verified"]
  }
}

This separation prevents a common product error: turning clean typography into false certainty. Client UI can display the normalized candidate while withholding a website, reviewed logo, chain identity, or stronger category assertion. If a reviewed match is later available, the same response contract can return richer fields without changing what “normalization” means.

The distinction also makes debugging easier. A bad fallback label points to parsing or normalization. A wrong website or brand points to matching, evidence, or promotion. Those are different failures and should not be hidden behind one opaque “merchant enrichment” step.

When to use it

Use the distinction whenever a transaction feed can improve readability before full merchant resolution. It is valuable for local merchants, marketplace sellers, payment facilitators, and new descriptors that are not yet represented in reviewed data.

When not to use it

Do not expose a normalized candidate as verified identity. Do not use it for legal entity resolution, tax classification, AML screening, fraud attribution, or claims that a logo or website belongs to the charged party. Those require a separate evidence standard.

Privacy caveat

Normalization should run only after privacy validation. Reject card numbers, account numbers, customer PII, bank credentials, customer contact details, full statements, and multi-transaction payloads before parsing. Read the PII-safe enrichment guide for the intended request boundary.