Why Level III interchange rates exist at all
What is an interchange rate and why do I care? Interchange is the per-transaction fee the card networks charge every merchant for every card payment. Interchange isn't one rate; it's hundreds of categories that shift based on card type, card-present vs card-not-present, and — critically for B2B and government — the quality of data submitted with each transaction.
Visa and Mastercard price commercial cards (Corporate, Business, Purchasing, Fleet, Government, GSA) lower when the merchant sends enhanced transaction data with the payment — typically 20+ fields covering line items, unit of measure, product codes, tax breakdown, freight, destination ZIP, customer code, and more. The networks want this data because commercial-card issuers and government purchasing programs need it for reporting, audit, and compliance. In exchange for your work submitting it, they price your transaction at a lower tier.
Why doesn't everybody do this then? The problem: every merchant with a significant B2B or government card program is technically eligible for Level III pricing, but many don't get it. The 20+ fields are tedious to compile per transaction, the gateway needs to support the full schema, and the data usually lives in an ERP that doesn't talk to the gateway. The result is that many merchants pay the higher commercial-card rates without knowing why.
Visa CEDP and the April 2026 schedule
In the U.S., Visa has replaced its separate Level 2 and Level 3 rates for commercial cards with the Commercial Enhanced Data Program (CEDP). Its interchange schedule effective April 18, 2026 prices Corporate and Purchasing card payments like this:
- Commercial Product 3 (CEDP, formerly Level 3): 1.75% + $0.10, for payments whose enhanced data passes Visa's validation.
- Commercial Card Not Present: 2.70% + $0.10.
- Non-Qualified, and Non-Qualified with Data: both 2.95% + $0.10. A payment whose data fails validation costs the same as one that sent none.
Three things follow for a B2B seller:
- Level 2 is gone on Corporate and Purchasing cards. The only commercial Level II row left is for fleet fuel. Business (small-business) cards still have a Business Product 2 row, so ask your acquirer which row your Business card volume settles in.
- Partial data no longer helps. Under the old program some processors gave partial credit for partial data. CEDP doesn't: the line items have to be complete and add up to the authorized amount, to the cent.
- Visa doesn't publish the criteria. Its qualification guide goes to acquirers under contract, so every public Level 3 field list, the one below included, is a processor's restatement. That's why Payment Hub takes the data from the real ERP lines rather than a typed summary.
Mastercard has no CEDP. It kept Data Rate I, II and III, which still qualify transaction by transaction on the fields sent, and it doesn't offer Data Rate III on small business cards. Rates change twice a year, and the difference only reaches you on interchange-plus pricing: on flat-rate pricing it doesn't, and on tiered pricing you can't see which category a payment settled in.
The full rate table, the fields that fail most often and how to check your statements are on the Visa CEDP page.
The 20+ fields the networks require — and where Payment Hub gets each one
Level III's field requirements differ slightly between Visa and Mastercard, but the core envelope is stable across card brands. Every field has a specific format (numeric, alphanumeric, ZIP length, ISO country code) and a specific source. If any required field is missing, wrong-format, or mismatched against a total, the transaction settles at a higher rate. On Visa's April 18, 2026 schedule, data that fails validation is priced exactly like no data at all.
| Field | Scope | What it holds | Payment Hub source |
|---|---|---|---|
| Invoice number | Header | ERP invoice reference (unique per customer) | ERP invoice record |
| Customer code / PO reference | Header | Buyer-assigned code for their procurement reporting | ERP customer / order |
| Merchant tax ID | Header | Federal tax ID of the selling merchant | Payment Hub config |
| Order date | Header | Date the order was placed / invoice was generated | ERP invoice date |
| Ship-from ZIP | Header | Originating ZIP of the shipment | ERP warehouse |
| Destination ZIP | Header | Delivery ZIP (customer ship-to) | ERP ship-to address |
| Sales tax amount | Header | Total tax applied on the invoice | ERP tax engine |
| Sales tax rate | Header | Effective rate applied, as percentage | ERP tax record |
| Freight amount | Header | Shipping cost passed to customer | ERP shipping record |
| Duty amount | Header | Customs duty (0 on domestic) | ERP (if applicable) |
| Discount amount | Header | Total discount applied at invoice level | ERP invoice |
| Currency code | Header | ISO 4217 currency identifier | ERP / gateway |
| Item description | Line | Short description of the item sold (per line) | ERP line record |
| Item quantity | Line | Number of units (per line) | ERP line record |
| Unit of measure | Line | Each, hour, pound, foot, gallon, etc. (network code list) | ERP UoM mapping |
| Unit cost / price | Line | Per-unit price on the invoice | ERP line record |
| Product code / SKU | Line | Merchant-assigned item code (e.g., SKU, part number) | ERP item master |
| Commodity code | Line | UNSPSC or network-mapped category code | ERP item / PH mapping |
| Line discount | Line | Discount at this specific line | ERP line record |
| Line tax | Line | Tax allocated to this line | ERP tax allocation |
| Line total | Line | Net line extended (qty × unit − discount + tax) | ERP line total |
Visa and Mastercard maintain the canonical field-list definitions; exact required/optional status varies by card brand and by specific commercial program. Payment Hub maintains the current network specifications and submits the correct envelope for each card brand automatically.
Where Payment Hub can't pull a field from the ERP because it's legitimately not captured in the source system (a missing ship-to ZIP on a counter walk-in, for example), Payment Hub falls back to the best-available field or flags the transaction for counter-staff review pre-authorization. Transactions with material data gaps carry a reporting flag, so controllers see the downgrade rather than discovering it three months later in a rate review.
Learn What Clarity Can Do for You
We're happy to talk with you and answer any questions. Click the button below and fill out our short form or use our live chat feature (button on the bottom right corner) to talk to an expert right away!
How Payment Hub enriches Level III automatically
Eight capabilities run the L3 enrichment pipeline. Each one is work that most merchants do manually or skip entirely — and each one is required to actually qualify for the lower interchange tier on a real-world commercial-card transaction.
- BIN lookup at authorizationPayment Hub identifies the card type at first authorization and determines L3 eligibility. Consumer cards skip L3 enrichment (no benefit). Visa/MC Commercial, Corporate, Purchasing, Fleet, Government, and Business cards trigger enrichment. No manual card-classification needed.
- ERP invoice & line-item fetchClarity Connect pulls the underlying invoice or sales order from your ERP — header fields (PO, order date, tax, freight), line items (SKU, description, qty, UoM, unit cost), and ship-to / ship-from ZIPs. NetSuite, Acumatica, Dynamics 365 BC/F&O/GP, Sage 100/300/Intacct, SAP, Epicor, Infor, SYSPRO, Workday, Oracle, and more.
- Unit-of-measure normalizationCard networks require UoM values from their standardized code list (EA, HR, LB, GAL, etc.). Your ERP might store them as free-text or a different code set. Payment Hub maps your ERP UoM catalog to the network's expected codes once at setup — so every line submits with a valid UoM automatically.
- Commodity code mappingVisa requires a commodity code on every line; Mastercard doesn't. No ERP stores one natively, so Payment Hub maintains a rules engine that maps your ERP product categories to commodity codes — configured once, applied to every transaction without any per-order keying.
- Header-to-line total reconciliationL3 submission requires line totals to reconcile to header totals (subtotal + tax + freight − discount = header amount), to the cent. ERPs often store unit prices to four or more decimal places, which is where one-cent mismatches come from. Payment Hub runs this reconciliation pre-submission; any mismatch triggers a data-quality flag before the transaction submits, so staff can investigate rather than discover a silent downgrade later.
- Per-gateway L3 envelope formattingEach gateway (Fortis, PayTrace, Nuvei, Worldpay, PNC, Cybersource, Elavon, NMI, USAePay, Global Payments, Authorize.Net) has its own L3 API schema and field-packaging expectations. Payment Hub formats the correct envelope for your specific gateway without requiring gateway-specific configuration from your team.
- Large-ticket program qualificationVisa and Mastercard both publish Large Ticket rates for high-value commercial card payments, and Visa adds Large Purchase Advantage for purchasing cards. They rely on the same enhanced data. Payment Hub submits qualifying transactions with the full L3 envelope, so eligible payments can qualify without special handling.
- Interchange category reporting & downgrade analyticsEvery transaction is reported with the interchange category it settled in and the L3 fields submitted. Controllers see where L3 worked, where data gaps caused a downgrade, and which upstream ERP fixes would recover the rate — on an ongoing basis, not just at go-live.
Level 3 data in your ERP
The line items have to come from somewhere. Here is where Payment Hub reads them in each ERP:
- Epicor Eclipse payment processing: contractor purchasing-card payments carry the order's own line items and branch ship-from.
- Epicor Prophet 21 payment processing: MRO and safety orders paid by P-card, itemized from the P21 order.
- Epicor Eagle payment processing: store invoices itemized for pro customers who pay on company cards.
- Epicor Kinetic payment processing: part numbers and units of measure from Kinetic order lines, for defense and industrial P-cards.
- Epicor E10 payment processing: OrderDtl part, quantity and unit of measure behind OEM and maintenance buyers' card payments.
- Infor SyteLine payment processing: commodity codes mapped from SyteLine item categories, on order and project invoices.
- SYSPRO payment processing: tax amounts and tax-exempt flags as SYSPRO calculated them, never a bare zero.
- Sage 100 payment processing: item codes and units of measure from Sage 100 invoice lines, whichever gateway you use.
- NetSuite payment processing: invoice item lines, with NetSuite units types mapped to the networks' unit codes.
- Sage Intacct payment processing: contract and subscription invoice lines, itemized for each entity.
- Acumatica payment processing: stock and non-stock item lines, with each item's base unit mapped once.
- Business Central payment processing: sales invoice lines with item, quantity and unit of measure codes.
- Dynamics GP payment processing: SOP invoice lines, and the same mapping carries over when you move off GP.
- Dynamics 365 Finance payment processing: free-text and sales order invoices itemized for AR, not only Commerce orders.
- Odoo payment processing: invoice lines with Odoo's units of measure mapped to the networks' codes.
- Sage 300 payment processing: Order Entry invoices and job-cost billings, with tax as your tax service calculated it.
- Sage X3 payment processing: U.S. sales invoices itemized from X3, with commodity codes mapped from product categories.
- SAP Business One payment processing: the A/R invoice rows, item codes and UoM groups from Business One.
- SAP S/4HANA payment processing: billing document items for each Company Code.
- Dynamics NAV payment processing: the NAV sales invoice lines behind each payment, until you move to Business Central.
All 25 ERP integrations are on the Payment Hub integrations page.
Level III Interchange Optimization FAQ
The questions finance, IT, and AR teams ask before turning on L3 enrichment across their gateway.
Which card types qualify for Level III rates?
Level III-eligible cards are the commercial BINs issued by Visa and Mastercard: Visa Corporate, Visa Business, Visa Purchasing, Visa Fleet, Visa GSA (government), and the equivalents on Mastercard (Corporate, Purchasing, Fleet, Government). Mastercard doesn't offer Data Rate III on small business cards; Visa now extends Product 3 to Business cards. Consumer cards do not qualify for L3 — they're priced at consumer tiers regardless of submitted data.
Do we need to change gateways or merchant accounts to get L3 rates?
No. Payment Hub works with your existing gateway (Authorize.Net, Fortis, Nuvei, PayTrace, Worldpay, PNC, Cybersource, Elavon, NMI, USAePay, Global Payments, Adyen, Braintree, Stripe, Square, and more) and your existing merchant account and negotiated rates. L3-capability depends on the gateway; the major B2B-focused gateways (Fortis, PayTrace, Nuvei, Worldpay, PNC, Cybersource, Elavon, NMI, USAePay, Global Payments, Authorize.Net) all support the full L3 field set.
What happens to transactions where L3 data is missing or invalid?
The transaction still authorizes — missing or invalid L3 data doesn't block the charge; the payment just settles at a higher rate. On Visa's April 18, 2026 schedule, a Corporate or Purchasing card payment whose data fails validation settles as Non-Qualified with Data at 2.95% + $0.10, the same as Non-Qualified. Payment Hub detects data gaps pre-submission (missing ship-to ZIP, missing line items, line-total mismatch, invalid unit-of-measure code) and either fills them from the ERP record, flags them for counter-staff / AR review, or submits the transaction at the best available tier with a reporting flag so controllers can see which transactions downgraded and why.
How do we know L3 is actually working?
Payment Hub's settlement reconciliation shows the interchange category hit on every transaction — by the networks' own category names, such as Visa's Commercial Product 3 or Non-Qualified. The dashboard aggregates this into a monthly category distribution and downgrade reasons.
How long does L3 implementation take?
A typical Payment Hub deployment goes live in 48 hours once Clarity receives ERP sandbox credentials, gateway credentials, and a validated commodity-code / UoM mapping. L3 enrichment is on by default from day one — every qualifying commercial-card transaction submits with the full envelope automatically.
Related resources
See Level 3 data built from your own ERP
Book a 30-minute walkthrough and see L3 enrichment running against a sandbox of your own ERP — line items pulled live, UoM / commodity codes mapped, envelope submitted to your gateway, interchange category reported. Live in 48 hours. Your gateway, merchant account, and rates stay intact.
Book a Live Demo