Why merchant management matters

Merchant names influence reporting, duplicate review, categorisation hints, and logo display. Current shared code does not treat merchant governance as only a simple per-ledger text list. Instead, it uses a richer brand-governance model.

Current governance model

Shared backend and client code prove support for:

platform merchant brands,
brand merge operations,
organisation-specific brand overrides,
display-name overrides,
logo overrides,
merchant suggestions and merchant-logo resolution,
merchant / brand usage data in organisation context.

Brand merge

Shared merchant-brand APIs include an explicit merge brand operation. This is the correct conceptual model when multiple merchant spellings or aliases should resolve to one canonical brand.

Display-name and logo overrides

Organisation-scoped merchant-brand overrides can store:

a display-name override,
a logo-file override.

This allows one organisation to present a merchant differently from the platform-wide default brand metadata.

Logo resolution

Shared merchant-resolution code can derive merchant logos from:

brand-level logo assignments,
organisation-level logo overrides,
legacy merchant-logo mappings.

Where merchants show up

Even when a client does not expose a dedicated Merchant Management page, merchant and brand data still surfaces indirectly through:

receipt detail views,
top-merchants reporting,
merchant search / suggestion lists,
organisation brand-governance flows.

What this page does not assume

This page does not assume a universal per-ledger merchant list, a simple Delete Merchant action, or an end-user bulk merge screen unless your current client explicitly exposes those controls.