What is Level 3 card data?

Level 3 card data is enhanced transaction information that can describe the individual goods or services within certain commercial card purchases. It adds line-item and order context beyond the basic facts of a payment, helping a business buyer receive a more detailed record of what was purchased.

The March 2026 GSA SmartPay master contract defines Level 3 as information added to Level 1 and Level 2 transaction data. Its examples include unit cost, quantity, unit of measure, product codes and descriptions, shipping postal codes, freight, duty, order date, discount amount, and order number. Visa Acceptance Solutions also describes Level III data as information provided for purchase or procurement card transactions and forwarded to the purchasing company. These sources establish the general concept, but they do not make every field or workflow universal.

Level 3 describes what made up the purchase

A basic transaction record can identify a merchant, amount, and date. Commercial purchasing teams often need more context to connect a payment with the goods or services behind it. Level 3 is the enhanced data layer that can carry that item-oriented detail through a supported commercial card transaction.

Transaction context

The payment record starts with ordinary transaction facts and may include business references associated with the customer or order.

Line-item context

Level 3 can add descriptions, product codes, quantities, units of measure, and unit costs for items represented by the transaction.

Order context

Depending on the applicable program, additional information may describe an order number, order date, shipping locations, freight, duty, or discounts.

This added detail does not replace an invoice, purchase order, fulfillment record, or accounting ledger. Instead, it can help the organizations involved associate a commercial card payment with the underlying purchase information already maintained by the merchant and buyer.

Level 3 is different from a merchant classification

The phrase can be confusing because the word "level" appears in several unrelated payment-industry classifications. On this page, Level 3 means enhanced commercial transaction data. It does not describe a merchant's size, security-validation category, business quality, or account status.

Level 3 data also should not be treated as a universal promise about a card, terminal, gateway, virtual terminal, processor, or account. Visa's current documentation says Level II and Level III processing support is processor- and card-specific. Merchants therefore need to check the documentation for their actual payment service before deciding which fields are available, required, transmitted, or returned through reporting.

A visible field on a payment screen is not enough to prove how that value travels. The field may remain only in a local order system, appear in a merchant report, or be handled differently for different transaction types. Verification should follow the complete path from source record to processed transaction and resulting report.

A practical example of Level 3 data

Imagine a supplier receives an order containing several office products. The supplier's order record already identifies each item, its quantity, unit of measure, unit cost, and description. The buyer pays with a commercial purchase card through the supplier's approved payment interface.

If the configured workflow supports the applicable enhanced-data process, the payment request can carry selected order and line-item details alongside the transaction. The buyer may then receive that enhanced information through its issuer or reporting environment, making the payment easier to associate with the original purchase. The supplier should still keep its ordinary invoice, fulfillment, and accounting records.

The example explains the data relationship without asserting how a particular product behaves. Readers who want the preceding layer can review what Level 2 card data means. For broader context, see what commercial cards are.

Accurate enhanced data starts upstream

A merchant cannot create a reliable Level 3 record from vague notes at the payment step. The business first needs a clear source for product descriptions, quantities, units, order identifiers, shipping information, and other non-sensitive details used by its configured workflow.

Map each payment field to the system that owns the value. Product descriptions and quantities may come from an order system, while an order number may come from an invoice or customer instruction. Staff should not invent a missing value merely to complete a screen. If field definitions are unclear, the merchant should use current documentation and ask the responsible payment-service provider how the configured workflow handles them.

Data quality can be checked with non-sensitive examples. Compare the source order with the payment record, review how item details appear after processing, and document which team corrects mismatches. Repeat the review after changes to payment services, account settings, order software, or reporting tools.

Keep payment secrets out of item details

Level 3 fields are for purchase and order context, not for storing payment credentials. Do not place full card numbers, card security codes, passwords, bank credentials, complete account numbers, secret API keys, or other payment secrets in product descriptions, item notes, customer references, invoice comments, email, shared documents, or general contact forms.

Payment credentials should be entered only through the merchant's approved payment interface. Training and workflow tests should use safe sample orders and non-sensitive references. Access to payment and reporting tools should follow the roles and instructions provided for the merchant's actual systems.

The payment processing glossary explains related terminology, while the B2B commercial cards FAQ hub collects additional educational topics.

A review checklist for merchants

Map the order flow: Identify where items, quantities, descriptions, and order references originate.
Define each value: Give staff a documented source and meaning for every non-sensitive field they use.
Review current documentation: Confirm which fields the configured payment service accepts, validates, transmits, and reports.
Test the full path: Use a safe sample order and compare the source record, processed transaction, and resulting report.
Protect sensitive data: Keep card credentials and account secrets out of line-item and reference fields.
Handle exceptions: Decide what staff should do when a source value is missing, ambiguous, or rejected.
Recheck after changes: Repeat the review when payment tools, account settings, order systems, or reporting processes change.

This process helps a business distinguish a useful enhanced-data workflow from a collection of extra fields with no verified destination. It also keeps general education separate from claims about a specific product or provider.

Start with one real order workflow

Select a representative commercial order and trace its non-sensitive details from the source record through payment and reporting. That review shows which information the business already maintains, where gaps exist, and which product-specific questions need authoritative answers.

For a general conversation about a commercial card acceptance workflow, contact Payments Max. Share business contact information and a high-level process description only; do not submit payment 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.