Merchant Locks for Agent Spend: MCC Allowlist vs Merchant Allowlist vs Descriptor Matching

If you’re building agent payments, you’ll quickly hear “merchant controls” described as if they’re one thing.

They’re not.

There are three distinct mechanisms:

1. ▸MCC/category allowlists (coarse boundaries)
2. ▸merchant allowlists (precise boundaries)
3. ▸descriptor matching (best-effort verification)

This post compares the three and recommends defaults that prevent merchant drift.

1) MCC/category allowlists

What it is: allow only certain merchant categories (e.g., travel, software).

Pros

• ▸enforced at the boundary
• ▸stops obvious out-of-scope spend

Cons

• ▸category codes are imperfect
• ▸some merchants are misclassified
• ▸“retail” is too broad to be safe

Best use: outer guardrail, not your primary control.

2) Merchant allowlists

What it is: allow only specific merchants (or merchant IDs) for a card/intent.

Pros

• ▸precise
• ▸prevents drift even when categories are broad

Cons

• ▸requires knowing the intended merchant
• ▸some platforms don’t expose stable merchant identifiers

Best use: primary control for ecommerce and known vendors.

3) Descriptor matching

What it is: compare the posted descriptor to an expected string.

Pros

• ▸simple
• ▸helps catch obvious mismatches

Cons

• ▸descriptors vary
• ▸subsidiaries and payment processors obscure names
• ▸not reliable enough as a boundary

Best use: verification signal, not an authorization gate.

Recommended defaults (copy/paste)

For safe agent spend:

• ▸If expectedMerchant is known → require merchant allowlist
• ▸If merchant isn’t known → restrict by MCC/category and cap spend
• ▸Always verify descriptor post-purchase against intent
• ▸Add velocity caps to prevent retry-loop duplicates

See: Merchant Drift.

Bottom line

To prevent drift, you want:

• ▸merchant allowlists as the primary lock
• ▸MCC allowlists as the outer boundary
• ▸descriptor matching as a verification signal

That stack stops the failures that monitoring can’t.