A logo in a transaction feed is not just decoration. It changes whether users trust the row. It also creates failure cases: wrong chain, low-resolution favicon, dark logo on dark UI, unreviewed marketplace seller, or a local merchant with no verified asset.
UBER TRIP HELP.UBER.COM CAA client app might need a small transaction icon, a receipt detail mark, or a search result logo. Those are different asset uses. The enrichment response should describe the variants instead of forcing the client to guess from one URL.
Data shape
{
"display_name": "Uber",
"confidence": 0.91,
"logos": [
{
"url": "https://cdn.txnkit.dev/logos/curated-seed-20260524/pilot-001/uber/icon-64.png",
"format": "png",
"width": 64,
"height": 64,
"theme": "light",
"shape": "square",
"purpose": "transaction_icon",
"source": "reviewed_seed",
"confidence": 0.95
}
]
}The point is not to return a logo for every descriptor. The point is to return reviewed logo variants when available and to omit or warn when evidence is incomplete.
When to use it
Use logo metadata when your UI has repeated transaction rows, merchant detail screens, search results, or receipt views. The response should let the client choose a variant based on size, background, shape, purpose, and confidence.
When not to use it
Do not fetch logos live during transaction enrichment. Do not scrape arbitrary domains from the request path. Do not upscale tiny favicons into polished-looking assets. Do not attach a logo when the merchant identity itself is low confidence.
Privacy caveat
Logo sourcing should be offline and admin-reviewed. It should not receive full statements, card numbers, account numbers, customer PII, or raw customer transaction history. Online enrichment should return metadata from reviewed records and stay away from live logo-provider calls.