Quick answer
Level II and Level III describe increasing amounts of transaction information submitted with certain commercial-card payments. Mastercard Gateway describes Level II as standard transaction data plus enhanced information such as customer reference, invoice number, and sales-tax amount; Level III adds line-item detail. Supplying supported data may help some qualifying business, corporate, or purchasing-card transactions receive different interchange treatment, but the gateway also states that the payment service provider does not validate whether submitted data is sufficient for a specific card-scheme rate. Read the current Mastercard Gateway documentation.
In this guide
- Why approved B2B transactions can still deserve review
- Level I, Level II, and Level III data compared
- How enhanced information moves through the workflow
- Why qualification is not automatic
- Illustrative 0.50% arithmetic across B2B card volume
- Questions for the gateway, acquirer, ERP, and provider
- Local B2B processing guidance
- Seven common Level III questions
The most expensive processing problem may be one you cannot see
A malfunctioning terminal attracts attention because transactions fail. A declined card is investigated because the sale cannot continue. An approved commercial transaction may appear successful even when enhanced information is missing, incomplete, unsupported, or transmitted through a channel that does not meet a particular category’s requirements.
That does not mean the merchant is necessarily overpaying. It means approval alone does not answer questions about card type, transaction channel, data fields, gateway capability, merchant configuration, interchange category, provider markup, or downgrade reasons. Businesses processing substantial corporate, purchasing, government, or commercial-card volume may benefit from examining those questions at the transaction level.
Manufacturers, distributors, wholesalers, contractors, equipment suppliers, medical suppliers, government vendors, professional firms, and other B2B sellers commonly have invoices, purchase orders, tax records, shipping information, and line items. The important question is whether the actual payment path can collect and transmit the appropriate information accurately for eligible transactions.
Level I, Level II, and Level III data compared
The terminology is often simplified in sales conversations. A practical comparison is:
| Data level | General description | Examples that may be involved |
|---|---|---|
| Level I | Basic payment information | Amount, date, merchant information, and ordinary authorization data |
| Level II | Basic data plus enhanced business information | Customer reference, invoice number, sales-tax amount, purchase reference, or related fields |
| Level III | Level II information plus detailed order or line-item data | Product descriptions, quantities, unit prices, commodity codes, shipping details, discounts, tax, and line totals |
This table is educational, not a universal field specification. Required fields and validation vary by card scheme, card product, transaction type, gateway, acquirer, provider, merchant setup, and current rules. A field displayed in software does not prove that it is transmitted in the required format or used for a particular interchange category.
How enhanced data moves through a B2B payment workflow
Enhanced information may begin in an estimate, sales order, invoice, accounting platform, ERP, CRM, tax engine, e-commerce system, or employee entry screen. The payment application or integration must map relevant values to supported gateway fields. The gateway and provider must then transmit the transaction in a way supported by the acquirer and card scheme.
The business should identify:
- which system is the source of the customer, invoice, purchase-order, tax, product, quantity, price, shipping, and total data;
- which application initiates authorization and capture;
- whether authorization, capture, partial capture, delayed capture, refund, credit, and recurring transactions use the same data path;
- which fields are required, optional, conditionally required, or unsupported;
- how the provider reports submitted fields, qualification, category, or downgrade information;
- how payment, fee, batch, deposit, customer, and invoice records reconcile after settlement.
If information lives in several systems, staff may need a documented process or a verified integration. Manual entry can be workable for low volume but may increase effort and error opportunity as transaction volume grows. Integration can improve consistency when properly configured, but no accounting or ERP connection should be assumed to support every product, version, field, or transaction type.
Qualification and savings are not automatic
Enhanced data may support more favorable interchange treatment for some qualifying commercial-card transactions. It is not a universal discount program and does not guarantee a particular rate. Qualification can depend on card type, merchant classification, transaction timing, authorization and capture behavior, data completeness, field accuracy, tax handling, card-scheme rules, gateway support, acquirer configuration, and other factors.
A proposal that mentions “Level III savings” should be tested against the merchant’s actual card mix and transaction path. Ask the provider to explain which transactions are expected to qualify, which fields are required, how unsupported cards are treated, how results will be reported, and how total cost will be compared after implementation. Provider markup, monthly charges, gateway fees, software, integrations, equipment, disputes, refunds, and support terms remain part of the analysis.
> Midpoint B2B processing review: If your company accepts large corporate, business, government, or purchasing-card transactions, Custom Payments LLC can help organize a statement and workflow review. Request a complimentary B2B processing review or contact Robert Staschak. The review can identify questions for the provider; it cannot guarantee qualification, a rate, savings, deposit timing, compatibility, or an implementation result.
Small percentage-point differences become large mathematical amounts
The supplied brief asks for a 0.50 percentage-point illustration. Multiplying annual card volume by 0.005 produces:
| Annual B2B card volume | 0.50% mathematical amount |
|---|---|
| $500,000 | $2,500 |
| $1,000,000 | $5,000 |
| $2,000,000 | $10,000 |
| $5,000,000 | $25,000 |
| $10,000,000 | $50,000 |
These are mathematical illustrations only. They do not establish that a merchant is currently paying an unnecessary 0.50%, that transactions qualify for different treatment, or that Custom Payments LLC or any provider can deliver the illustrated difference. Actual cost depends on card mix, interchange categories, data, channels, provider pricing, account fees, software, downgrades, refunds, disputes, and written terms.
The table is useful for prioritization: a small unexplained difference can justify investigation at sufficient volume. The investigation should use transaction reports and statements, not treat the illustration as a savings projection.
What to investigate on the current setup
Card and transaction mix
Separate business, corporate, purchasing, government, and consumer-card activity where reliable reports permit it. Group transactions by channel, amount, recurring status, card-present or remote entry, and the software that originated the payment.
Gateway capability
Ask which Level II and Level III fields the exact gateway version supports, how fields are entered or mapped, which transaction types carry them, and how errors or incomplete data are reported. Confirm whether the payment link, virtual terminal, hosted page, API, ERP connection, and other channels behave differently.
Merchant and provider configuration
Verify merchant classification, account configuration, supported card products, authorization and capture settings, tax handling, settlement, reporting, and written pricing with the relevant provider. Do not change merchant information merely to pursue a category.
Accounting, ERP, and CRM workflow
Confirm the exact product, version, module, connector, fields, transaction types, implementation owner, support path, and export capability. A brand-name integration may support only part of the desired invoice-to-payment process.
Qualification and downgrade reporting
Ask for transaction-level evidence that shows the category or reason code where available. The absence of an error message does not prove that enhanced data were complete or that a transaction received a particular category.
Payment security still applies
Enhanced order data do not remove payment-security responsibilities. The PCI Security Standards Council describes PCI DSS as baseline technical and operational requirements for entities that store, process, transmit, or can affect payment account data. Use current PCI SSC merchant resources and confirm the actual environment with the provider and appropriate security professionals.
Hosted payment tools may change how card data flows through the business, but no tool automatically eliminates every PCI DSS responsibility. User access, authentication, device security, software updates, data retention, incident procedures, vendor management, and staff practices remain relevant to the actual environment.
Level II and Level III processing for Philadelphia-area businesses
Custom Payments LLC is based in Devon, Pennsylvania. Robert Staschak works with B2B companies in Philadelphia, the Main Line, Chester County, King of Prussia, and Southeastern Pennsylvania to organize questions about commercial-card acceptance, enhanced data, gateways, virtual terminals, ACH, and compatible payment connections.
The process begins with the company’s statements, transaction reports, card mix, invoice path, tax and line-item data, software list, and written provider terms. It does not begin with a promise that every transaction will qualify or that a specific amount will be saved. Businesses can also review the B2B payment-data guide, Philadelphia merchant-services guide, and Chester County merchant-services guide.
Frequently asked questions
What is Level III credit-card processing?
Level III commonly refers to submitting detailed order and line-item information with supported commercial-card transactions. Exact fields, card products, transaction types, and requirements vary, so the merchant must verify the actual gateway, provider, acquirer, and card-scheme rules.
What is the difference between Level II and Level III processing?
Level II generally adds enhanced business fields such as customer reference, invoice number, or tax information. Level III generally adds more detailed order and line-item data. The labels do not guarantee qualification or a particular rate.
Can Level III processing reduce credit-card-processing costs?
It may support different interchange treatment for some qualifying commercial transactions. Results depend on the card, transaction, data, gateway, acquirer, merchant setup, and current rules. No cost result is guaranteed.
Which businesses may benefit from investigating Level III data?
Businesses with meaningful corporate, purchasing, government, or other commercial-card volume may have a reason to investigate. Manufacturers, distributors, wholesalers, contractors, suppliers, government vendors, and professional firms are examples, but transaction-level facts determine relevance.
Do all corporate credit cards qualify for Level III processing?
No. Card product alone does not establish qualification. Transaction channel, data, timing, merchant and provider configuration, gateway capability, and current card-scheme requirements can matter.
Can Level III processing work with accounting or ERP software?
Some payment applications can connect with accounting or ERP systems, but support varies by product, version, module, connector, field, and transaction type. Confirm the complete workflow and responsibilities before implementation.
How can a business tell whether transactions are qualifying correctly?
Start with statements and transaction reports, then request gateway records, configuration details, category or downgrade reporting where available, and written provider explanations. A statement review can identify questions but may not prove every underlying data condition.
Continue the B2B payments and accounts-receivable series
Start at the ACH and B2B Payment Resource Hub, then continue with B2B payment options and collection timing, Level II and Level III commercial-card data, and accounts-receivable payment automation. Related resources include the B2B payment-data guide, ACH fees guide, recurring ACH guide, credit-card-processing guide, and payment-processing services.
Have the B2B payment path reviewed before assuming the answer
Bring recent processing statements, transaction reports, examples of commercial-card activity, invoice and purchase-order samples, tax and line-item data, gateway details, and the accounting or ERP workflow. Robert Staschak can help organize the questions that should be answered by the provider and software vendors.
Request a free B2B processing review or contact Custom Payments LLC. The review is no-obligation and does not promise qualification, a rate, savings amount, deposit schedule, software compatibility, or implementation outcome.