National B2B payment education
B2B, Commercial Cards & Level 2/3 Data
A practical guide to business-card acceptance, enhanced transaction data, operational ownership, and the questions merchants should resolve before implementation.
Start with the language
Separate the card program from the transaction data
Commercial-card programs support organizational purchasing and related controls. Level 2 and Level 3 describe categories of enhanced transaction information that a provider may support for eligible transactions.
Commercial card
A card used by an organization for business purchases, travel, fleet activity, or purchasing programs. Program rules and required records depend on the issuer, network, provider, and buyer.
Level 2 data
Common provider implementations add selected transaction details beyond basic payment information, such as tax or customer reference fields. Exact fields and validation rules vary.
Level 3 data
Common implementations can add line-item and order information. Product codes, quantities, units, freight, tax, and totals must be mapped and validated according to the provider's current requirements.
Qualification is separate
Sending extra fields does not by itself guarantee acceptance, qualification, pricing, or savings. Eligibility and results depend on current card, network, acquirer, gateway, provider, and transaction rules.
Decision path
Decide whether enhanced data fits the workflow
Who is the buyer?
Identify whether customers use consumer cards, business cards, purchasing cards, fleet cards, government cards, or a mixture. Do not infer card type or program rules from the company name alone.
Where does order data originate?
Map the authoritative source for purchase-order numbers, customer codes, tax, freight, product descriptions, quantities, units, and line totals. Avoid asking staff to re-key data that already exists in an order system.
Can the fields stay accurate?
Confirm required formats, conditional fields, rounding, totals, returns, partial shipments, credits, and split payments. A technically present field may still be unusable if it is incomplete or inconsistent.
Who verifies the result?
Assign responsibility for test transactions, provider responses, reconciliation, exception reports, updates, and periodic review. Use provider reporting rather than assuming that submitted data was accepted.
Implementation checklist
Questions to verify with each provider
Supported scope
Which card programs, networks, merchant categories, currencies, transaction types, entry methods, gateways, and settlement paths are supported?
Field specification
Which fields are required, optional, conditional, calculated, or prohibited? What formats, codes, precision, and cross-field checks apply?
System ownership
Which system collects each field, transforms it, sends it, stores the business record, and displays validation or rejection messages?
Testing and monitoring
How are test cases approved? Which response confirms receipt? How will staff identify missing data, changed rules, and transactions that need correction?
Security boundaries
Keep payment data exposure limited, restrict access by role, use provider-supported integrations, and never send cardholder data, passwords, bank credentials, or secret keys through general forms.
Commercial terms
Request current written pricing and qualification details directly from responsible providers. Evaluate costs separately from the technical ability to transmit enhanced data.
Responsibility map
Know who owns each decision
Merchant team
Defines the order workflow, maintains source data, trains users, reconciles activity, protects access, and escalates exceptions.
Software or integration provider
Documents field mapping, supported versions, validation behavior, update procedures, and the boundaries of its implementation.
Gateway, acquirer, or processor
Confirms supported data, transaction paths, response fields, testing, reporting, and current commercial requirements for its service.
Issuer, network, and buyer program
Set program-specific controls and requirements outside the merchant's direct control. Questions may need escalation through the buyer or responsible provider.
Related guidance
Continue your research
Common questions
B2B and enhanced-data FAQ
Does every business card use Level 2 or Level 3 data?
No. Card program, transaction eligibility, provider support, submitted fields, and validation are separate questions. Confirm the exact requirements for each payment path.
Is Level 3 always better than Level 2?
Not automatically. More fields create more mapping and data-quality work. Use the level supported and required for the actual transaction workflow.
Does enhanced data guarantee lower processing costs?
No. Do not treat data submission as a rate or savings guarantee. Request current written qualification and pricing details from the responsible providers.
What should a merchant prepare first?
Bring sample non-sensitive orders, field definitions, system owners, transaction paths, exception cases, reconciliation needs, and a list of provider questions.
Last editorial review: August 11, 2026. Sources: GSA SmartPay, Adyen provider documentation, and PCI Security Standards Council merchant guidance.
Next step
Map your B2B payment data
Payments Max can help organize order fields, systems, transaction paths, and provider questions before you compare available options.
To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.
CONTACT US