What is Level 2 card data?

Level 2 card data is enhanced transaction information sent with certain commercial card payments. It adds business-oriented reference details to the basic facts of a transaction so the organizations involved can receive more context than the purchase amount, date, and merchant identity alone.

Current Visa documentation describes Level II capability through sales-tax and customer-code information. The March 2026 GSA SmartPay master contract similarly defines Level 2 as information added to Level 1 data, including sales-tax amount, company information, and other elements defined by the applicable card brands or similar entities. These sources support a useful general definition, but they do not create one universal field list for every merchant, card, provider, or transaction.

Level 2 adds business context to a card transaction

A basic card record identifies the payment at a high level. A business buyer or supplier may also need a reference that helps connect that payment to an account, order, department, or internal record. Level 2 data is the additional layer used to carry some of that context through the commercial card transaction flow.

Basic transaction details

The core record generally identifies facts such as the transaction amount, purchase date, and merchant. Exact record contents depend on the payment environment.

Enhanced business details

Level 2 may add a sales-tax amount and a customer code or similar company reference, subject to the applicable program and provider definitions.

Operational connection

The merchant still needs a consistent way to associate the payment with its customer, invoice, order, or other source record.

Level 2 data should therefore be understood as transaction detail, not as a replacement for invoicing, order management, or accounting records. It can support a clearer data trail when the right non-sensitive references are captured accurately and transmitted through the configured payment workflow.

The exact data set is not universal

It is tempting to treat Level 2 as a single checklist that works the same everywhere. The official definitions do not support that assumption. GSA's definition expressly allows other data elements to be defined by card associations, brands, or similar entities, while Visa's supplier-matching documentation describes specific Level II indicators within Visa's own commercial merchant data.

For merchants, that means a general article can explain the category but cannot confirm what a particular terminal, gateway, virtual terminal, processor, card program, or account configuration transmits. Field names, validation behavior, supported transaction types, and reporting output can differ. Those details should be checked against current documentation for the merchant's actual payment service and, when needed, confirmed with the responsible provider.

The distinction also prevents a common operational mistake: seeing a field on a screen does not by itself prove that the value is transmitted as Level 2 data. Staff should verify where the field goes, whether it is retained in reports, and how it appears after the transaction is processed.

A simple example of the data flow

Consider a supplier accepting a commercial card payment for an invoice. The staff member selects the customer and enters the payment through the approved interface. Alongside the ordinary transaction information, the workflow may request a customer reference and the sales-tax amount. The payment service then handles those values according to its documented configuration.

Afterward, the supplier should be able to locate the transaction and match it back to the correct invoice or customer record. The buyer may receive enhanced transaction detail through its own issuer or reporting environment. Each side sees the information available through its systems; neither side should assume that screen labels or reports are identical.

This example illustrates the purpose without promising a specific product behavior. Businesses evaluating the larger payment context can read what commercial cards are and how B2B credit card processing works.

Good data starts with a clear source record

Enhanced fields are most useful when staff know which business record supplies each value. A customer reference might come from a buyer instruction, customer profile, invoice, purchase order, or internal account record. A sales-tax amount should come from the merchant's completed transaction documentation rather than an improvised note.

Define the source of each field before asking staff to enter it. Use consistent names, explain when a value is required by the configured workflow, and document how exceptions are handled. If a customer sends several possible reference numbers, the merchant should confirm which one belongs with the payment instead of guessing.

Quality checks can stay simple: compare the payment record with the source invoice, confirm that the intended non-sensitive reference appears in the resulting report, and keep a written procedure for corrections. These steps help the business judge whether its workflow preserves useful context without making claims about systems it has not reviewed.

Keep sensitive payment information out of general records

Business reference fields should contain only the information needed to identify and reconcile the transaction. Do not place full card numbers, security codes, passwords, bank credentials, complete account numbers, secret API keys, or other payment secrets in customer-code fields, invoice notes, email, shared documents, or general contact forms.

Enter payment credentials only through the merchant's approved payment interface. Use safe sample values when training staff or testing how a non-sensitive reference appears in reports. Access to payment functions should follow the roles and instructions available in the merchant's actual systems.

For definitions encountered during a workflow review, the payment processing glossary provides additional background. The B2B commercial cards FAQ hub groups related educational topics.

A practical review path for merchants

Map the transaction: Identify where a business customer orders, receives an invoice, and supplies payment.
Name the needed reference: Decide which customer, invoice, order, or department identifier staff must retain.
Locate the source: Document where each non-sensitive value originates and who is responsible for checking it.
Review current documentation: Confirm which Level 2 fields the configured payment service accepts, validates, transmits, and reports.
Test safely: Use non-sensitive sample references and verify the stored transaction and reporting result.
Train the team: Explain what belongs in each field and what sensitive information must never be entered there.
Recheck after changes: Review the workflow when the merchant changes providers, interfaces, account settings, or reporting tools.

This path keeps the decision grounded in the merchant's real workflow. It also separates verified product behavior from general educational guidance, which is important whenever several payment organizations and business systems participate in one transaction.

Start with the fields your business already uses

List the non-sensitive references used to match commercial card payments with customers, invoices, and orders. Then compare that list with the current documentation for your payment interface and reports. The goal is a clear, repeatable record trail, not collecting extra information without a defined purpose.

For a general conversation about a commercial card acceptance workflow, contact Payments Max. Share business contact details and a high-level process description only; do not submit card credentials or sensitive account information.

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.