Raw network descriptors are cryptic. Astrada Enrichment matches each transaction to a verified business — persistent identity, clean name and logo, precise category, exact location, and risk signals — fast enough to use at authorization.
We don't just clean up messy strings. Each transaction is matched against a database of verified businesses — so the record you receive describes the merchant, not the processor's abbreviation of it.
// what the network sends "descriptor": "TST* HNK 042 NEW YO", "mcc": "5812" // what your platform receives { "merchant": { "id": "mch_8f3ka92", // persistent across MIDs & rebrands "name": "Hanoi Kitchen", "logo": "https://cdn…/hanoi-kitchen.png", "website": "hanoikitchen.nyc" }, "industry": "Restaurants › Vietnamese", // not MCC-based "third_party": { "name": "Toast", "type": "platform" }, "location": { "address": "114 Ludlow St", "city": "New York", "lat": 40.7191, "lng": -73.9883 }, "risk": { "high_risk_entity": false, "card_acceptance_history": "extensive" }, "match_score": 98.4 }
Every field below arrives on the same API as your real-time network feed — no second integration, no second vendor.
A persistent, unified merchant ID for every business — stable across MIDs, locations, channels, and rebrands. Use it for spend analytics, merchant-level controls, and allow/block lists that don't break when a descriptor changes.
A custom category tree up to four tiers deep — with IDs and iconography — that doesn't rely on self-assigned MCC codes. Every transaction gets a category, matched or not.
When an intermediary is involved — a POS platform, marketplace, delivery service, or BNPL provider — it's identified and returned separately from the underlying merchant, so both sides of the transaction are visible.
Physical transactions resolve to an exact geolocation: street address, city, region, postal code, and latitude/longitude — not just a city guess. Built for receipt matching and location-based risk checks.
Brand logos, merchant websites, and phone numbers on matched transactions — the details that make a feed instantly recognizable and cut "what is this charge?" tickets.
Even unmatched transactions come back cleaned: normalized capitalization and structure, noise removed, misplaced data sorted into the right fields. Nothing raw ever reaches your UI.
Enrichment returns in real time — fast enough to sit inside the authorization decision, not after it. Pair these signals with spend controls to stop bad transactions before they settle.
| Signal | What it flags |
|---|---|
| high_risk_entity | Merchants previously alleged of fraud or scams — the transactions most likely to be disputed |
| irregular_web_presence | Risky content on the merchant's site, like warnings not to charge back |
| negative_online_sentiment | Poor consumer sentiment associated with the merchant — a step-up confirmation candidate |
| risky_industry | Industries correlated with elevated dispute rates, based on our categorization — not MCC |
| card_acceptance_history | How long the merchant has accepted card payments, from extensive to very_limited |
Merchant-level data and line-item detail land on the same transaction record: recognizable to users, itemized for the books.
Every transaction resolved to a verified business, with the identity and context your platform needs.
Line-item settlement detail, itemized on transactions that support it — straight from the network.
Clean names, logos, and locations mean users recognize their purchases — fewer support tickets, faster approvals, shorter dispute cycles.
Persistent merchant IDs and four-tier categories make GL coding, policy rules, and merchant-level reporting reliable — no regexes on descriptors.
Real-time enrichment puts merchant identity and risk signals inside the auth decision — block high-risk entities, lock cards to merchants, enforce category policy in real time.
Enrichment ships on the same API as your network feed. Turn it on with a config change — no second integration.