Level 2 and Level 3 Data for B2B Card Payments

What Level 2 and Level 3 data actually are

Every card transaction carries data. A consumer buying coffee sends almost none of it: merchant name, amount, date, card number. That is Level 1, and it is what the card networks assume by default. Level 2 and Level 3 are what happens when a merchant sends substantially more — first the commercial context of the purchase, then a full itemized breakdown of what was bought.

Interchange (the portion of a card fee that moves from the acquiring bank to the cardholder's issuing bank, set by the card network and not negotiable by the merchant, the processor, or the acquirer) is not a single number. It is a matrix of hundreds of categories, and a transaction lands in one of them based on card type, merchant category, how the card was presented, and how much data came with it. Enhanced data moves a commercial card transaction into a cheaper cell of that matrix. Nothing else about the sale changes.

The logic is not a reward for good behavior. Issuing banks price for uncertainty, and a purchasing card transaction that arrives with a purchase order number, a tax amount, a commodity code and eleven line items is one the issuer's corporate client can reconcile automatically, audit, and is far less likely to dispute. Level 3 is a trade: the merchant does more work at settlement, and the issuer charges less.

The fields, level by level

The exact field list varies by network, by processor, and by the interchange program a transaction is being qualified into, and the networks revise their specifications on a regular cycle. What follows is the structure that has been stable across Visa, Mastercard, American Express and Discover for years — but the authoritative list is always the current specification from the merchant's own processor, not a blog post and not this page.

Two things about that table deserve emphasis. Level 3 is not "Level 2 plus a description field" — it is a structured itemized invoice inside the payment message, each line carrying a quantity, a unit of measure drawn from a valid code set, a unit cost and an extended total that must reconcile against the transaction amount. And the tax field breaks things more often than any other. Many programs require a tax amount greater than zero and within a plausible band relative to the sale, unless the transaction is explicitly flagged tax-exempt; a merchant that hardcodes tax to zero on taxable sales fails silently.

Mastercard describes its commercial data tiers as Data Rate I, II and III rather than Levels 1, 2 and 3; American Express and Discover maintain their own enhanced-data programs with overlapping but not identical field requirements. A processor that has certified a merchant for Visa Level 3 has not necessarily certified the same merchant for the Amex equivalent.

Which cards qualify, and which never will

This saves the most wasted engineering effort, and it is almost never said plainly: Level 2 and Level 3 data does nothing for a consumer card. Not a smaller saving — no saving. Enhanced data qualifies transactions into commercial card interchange programs, and a personal Visa or Mastercard is not in one.

The cards that respond to enhanced data are commercial products issued to organizations rather than individuals:

• Purchasing cards and procurement cards — issued to a company for decentralized supplier spend, and the category where Level 3 matters most. These are the cards the programs were built for.
• Corporate cards — issued to employees of larger organizations, typically with central billing and mandated reconciliation.
• Government purchase cards — US federal agencies buy through a government-wide charge card program, and suppliers are routinely required to be Level 3 capable as a condition of being paid this way.
• Small-business cards — generally recognized for Level 2 treatment, with Level 3 handling that differs by network and by program. Do not assume a business card behaves like a purchasing card.

One related program matters disproportionately for anyone invoicing large amounts. The networks maintain large-ticket interchange categories for high-value commercial transactions, generally priced as a lower percentage plus a higher fixed amount than standard commercial interchange, and those categories typically require enhanced data to qualify. A percentage rate applied to a $180,000 invoice is a large absolute number, and moving that transaction into a large-ticket program can change it materially.

What it is worth — and who actually keeps the money

The interchange difference between a commercial card settled with no enhanced data and the same card settled at the Level 3 program is meaningful — for a B2B distributor running most of its receivables on cards, it is a line item worth an engineering sprint. Interchange tables change on the networks' own publication cycle, typically twice a year, so any specific figure quoted anywhere should be treated as stale. Work it structurally instead.

Suppose, purely illustratively, that a wholesale supplier runs $4 million a year through commercial cards and improves interchange by three quarters of a percentage point on the transactions that qualify. That is $30,000 a year, recurring, against a one-time integration. Now run the same illustration at a quarter of a point and $400,000 of qualifying volume: $1,000 a year, which will not pay for the certification testing. The prize is a function of commercial card mix and average ticket, and both should be measured before anything is committed.

This is the strongest practical argument for interchange-plus pricing in B2B, and it is why processors serving that segment tend to publish their margins. Helcim publishes an interchange-plus margin table by volume tier; Stax Payments prices as a fixed monthly subscription with interchange passed through at cost. Under either structure, a Level 3 qualification shows up directly in the merchant's effective rate. Under a blended flat rate, it does not show up at all.

Why most merchants never capture it

Level 3 has an unusually wide gap between "available" and "working." The failure modes are consistent enough to list.

Confusing gateway support with actual submission

The mistake most businesses make here is reading "supports Level 3 processing" on a gateway's feature page and assuming their transactions are qualifying. Support means the API accepts the fields; it does not mean anything is populating them. Authorize.net, NMI and the major acquirer gateways all expose Level 2 and Level 3 objects, and a large share of merchants integrated to them send nothing in those objects, because the cart, ERP or billing system upstream was never wired to pass the data through.

Sending fields that are present but invalid

A populated field is not a valid field. Placeholder customer codes, unit-of-measure values that are not in the accepted code set, product codes left blank, line totals that do not reconcile to the transaction amount, and tax hardcoded to zero on a taxable sale all produce the same outcome: the transaction is accepted, settles normally, and quietly qualifies at a worse interchange category than the merchant believes it did. There is no error message. The only evidence is in the interchange detail on the statement.

Downgrade triggers that have nothing to do with Level 3

Enhanced data does not exempt a transaction from every other qualification requirement. Settling late — batching days after authorization rather than within the window the network expects — downgrades a transaction regardless of how many line items it carried. So does a keyed transaction submitted without address verification data, an authorization amount that does not match the settled amount, or a partial capture that breaks line-item reconciliation. Refunds and partial refunds are a common breakage point in implementations only ever tested on clean full sales.

Never verifying the result

The final failure is not measuring. A merchant that has built Level 3 should be able to pull an interchange-detail report and see which interchange categories its commercial card transactions are landing in, transaction by transaction. If a processor cannot produce that report, that is itself a finding.

The other side of the table: why your customer wants to pay by card

Level 3 is usually framed as a merchant cost-reduction project. It is worth understanding the transaction from the buyer's side, because that explains why the pressure to accept cards for large invoices keeps increasing.

Corporate accounts payable departments have been steadily moved onto commercial card and virtual card programs, and those programs are monetized through interchange. Corpay's Corporate Payments business is explicit about the model: it sells accounts payable automation and virtual commercial cards, monetized substantially through the interchange earned on supplier payments. The buyer gets a rebate, extended float, and automated reconciliation. The interchange funding that rebate is paid by the supplier.

So when a customer's AP team asks to pay a $90,000 invoice by virtual card instead of ACH, the supplier is being asked to fund the buyer's card program. That is not necessarily a bad deal — faster payment and eliminated collections effort have real value — but it should be priced as a decision rather than absorbed silently. Level 3 qualification is the supplier's main lever for reducing that cost without refusing the card; the alternatives are a surcharge where network rules and state law permit one, or a stated preference for bank rails on large invoices.

How to actually get Level 3 working

A practical sequence, in the order that avoids wasted work:

1. Measure the commercial card mix first. Pull twelve months of transactions and identify what proportion of volume, and of transaction count, sits on commercial cards. If commercial cards are a rounding error, stop here.
2. Confirm the pricing model. Verify in writing that the merchant agreement passes interchange through at cost. If it is flat-rate or tiered, renegotiate the pricing before writing a line of integration code, because otherwise the savings will not reach the merchant.
3. Obtain the current field specification from the processor. Not a general article; the processor's own Level 2 and Level 3 specification for each network, including the accepted unit-of-measure and commodity code sets.
4. Find where the line-item data actually lives. This is usually the hard part: itemized detail sits in the ERP, order management or invoicing system, while the payment integration sits downstream of it with only a total. Bridging that gap is the real project. Acquirers with established ERP integrations — CardConnect publishes SAP and Oracle E-Business Suite integrations — exist because of exactly this problem.
5. Certify and test the awkward cases. Test partial captures, partial refunds, full refunds, tax-exempt sales, freight-only lines and multi-line orders that include a discount. These are what break in production.
6. Verify against interchange detail, then keep verifying. Confirm from interchange-level reporting that transactions land in the intended categories, and re-check after any change to the cart, ERP, tax engine or processor. A schema change upstream can silently switch Level 3 off, and nothing will alert anyone.

Level 3 sits in a gap: too technical for payments marketing, too commercially specific for engineering documentation. The result is that a recurring, measurable cost reduction goes uncollected by a large share of the businesses entitled to it — and collected instead by the processors that quoted them a single blended rate.

Frequently asked questions