# Every transaction, resolved to a real merchant

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.

## The Upgrade

### From descriptor to verified business

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.

POST /webhooks — transaction.enriched

```
// 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
}
```

Verified merchant identity

Non-MCC categorization

Exact geolocation

Risk signals

Real time, in the auth flow

## Capabilities

### What enrichment returns

Every field below arrives on the same API as your real-time network feed — no second integration, no second vendor.

### Merchant identity

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.

### Categorization beyond MCC

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.

### Third-party extraction

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.

### Location precision

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.

### Logos, websites & contact info

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.

### Normalization on everything

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.

## Risk Signals

### Merchant risk, scored before you authorize

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              |

## Complete Picture

### Who was paid — and what was bought

Merchant-level data and line-item detail land on the same transaction record: recognizable to users, itemized for the books.

### Merchant Enrichment

#### Who was paid

Every transaction resolved to a verified business, with the identity and context your platform needs.

- Persistent merchant ID, unified across MIDs  
- Clean name, logo, website, phone number  
- Four-tier categorization, independent of MCC  
- Exact geolocation on physical transactions  
- Merchant risk signals, auth-flow ready

### Level 2/3 Data

#### What was bought

Line-item settlement detail, itemized on transactions that support it — straight from the network.

- Line items with quantities and unit prices  
- Tax amounts and rates per transaction  
- GL coding and policy at the line-item level  
- Same webhook, same transaction record

## Use Cases

### What platforms build with it

#### Recognizable spend feeds

Clean names, logos, and locations mean users recognize their purchases — fewer support tickets, faster approvals, shorter dispute cycles.

#### Accurate coding & analytics

Persistent merchant IDs and four-tier categories make GL coding, policy rules, and merchant-level reporting reliable — no regexes on descriptors.

#### Controls at authorization

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.

## Know every merchant. In real time.

Enrichment ships on the same API as your network feed. Turn it on with a config change — no second integration.