Overview

Card data levels — Level 1 (L1), Level 2 (L2), and Level 3 (L3) — are commercial data tiers used primarily for Business-to-Business (B2B) and Business-to-Government (B2G) payments. Each level represents a progressively richer set of transaction data that can improve interchange qualification, satisfy buyer reconciliation requirements, and support government procurement workflows.

Authorize.net supports submitting L2 and L3 data when the processor or acquirer connection permits. L2 data can generally be submitted through the Virtual Terminal and hosted payment products. L3 data, which includes full line-item detail, requires integration with the Authorize.net Application Programming Interface (API) using createTransactionRequest.

Visa Commercial Enhanced Data Program (CEDP) formalizes the validation rules for Product 2 (P2) and Product 3 (P3) data. The purchaseLevel field is required for CEDP declaration when using the FDIGlobal processor. Availability of enhanced data features depends on your processor and acquirer configuration. Confirm enablement before relying on interchange benefits.

This article applies to: Merchants using Authorize.net who process commercial card transactions (B2B or B2G) and want to submit L2 or L3 data via the API or Virtual Terminal.

This article does not apply to: Business-to-Consumer (B2C) transactions, or merchants on processors that have not enabled enhanced data.

Card Data Level Definitions

Each card data level builds on the previous, adding more detailed transaction information.

Submitting Enhanced Data: Where to Use L2 vs. L3

Virtual Terminal and Hosted Payment Products

The Virtual Terminal and hosted products — Accept Hosted, Payment Links, and Invoices — support L2 order-level fields only. If you need to submit full line-item detail, you must use the API.

API Integration (Recommended for Full L2 and L3)

The Authorize.net API allows developers to build payment processing directly into a website, application, or back-office system. Submitting L2 and L3 data through the API using createTransactionRequest provides the most complete support for enhanced commercial data fields.

API support includes:

• Invoice-level summary fields (tax, PO number, customer reference)
• Tax objects
• Line-item arrays with product-level detail
• Shipping and freight objects
• Duty objects
• Ship-to address information

Refer to the Authorize.net API Reference for complete field-level specifications and sample requests.

Key API Fields for L2 and L3

Actual required fields depend on card brand, processor, and acquirer configuration. The fields listed below are commonly used to qualify transactions for L2 or L3 processing but are not universally required.

Common L2 Fields (Examples)

• transactionRequest.poNumber
• transactionRequest.tax.amount
• transactionRequest.shipping.amount
• transactionRequest.duty.amount

Common L3 Fields (Examples)

• transactionRequest.purchaseLevel — Required for CEDP declaration when using FDIGlobal. Set to "3" for L3 transactions on FDIGlobal. Not required for TSYS.
• transactionRequest.lineItems.lineItem[*].name
• transactionRequest.lineItems.lineItem[*].description
• transactionRequest.lineItems.lineItem[*].quantity
• transactionRequest.lineItems.lineItem[*].unitPrice
• transactionRequest.lineItems.lineItem[*].productCode / .productSKU

Sample API Payloads

L2 — Minimal Example (JSON)

{
  "createTransactionRequest": {
    "merchantAuthentication": { "name": "APIID", "transactionKey": "APIKey" },
    "transactionRequest": {
      "transactionType": "authCaptureTransaction",
      "amount": "102.50",
      "poNumber": "456654",
      "tax": { "amount": "4.26" },
      "shipping": { "amount": "4.26" },
      "duty": { "amount": "8.55" },
      "billTo": {
        "firstName": "Ellen",
        "lastName": "Johnson",
        "zip": "44628",
        "country": "US"
      },
      "shipTo": {
        "firstName": "China",
        "lastName": "Bayles",
        "zip": "44628",
        "country": "US"
      }
    }
  }
}
  

L3 — Minimal Example (JSON)

{
  "createTransactionRequest": {
    "merchantAuthentication": { "name": "APIID", "transactionKey": "APIKey" },
    "transactionRequest": {
      "transactionType": "authCaptureTransaction",
      "amount": "250.00",
      "purchaseLevel": "3",
      "poNumber": "PO-7890",
      "lineItems": {
        "lineItem": [
          {
            "itemId": "1",
            "name": "Widget A",
            "description": "Widget A - 10-pack",
            "quantity": "10",
            "unitPrice": "20.00",
            "productCode": "default",
            "productSKU": "WIDGET-A-10",
            "extendedAmount": "200.00"
          },
          {
            "itemId": "2",
            "name": "Shipping",
            "description": "Standard Ground",
            "quantity": "1",
            "unitPrice": "50.00",
            "productCode": "shipping_only",
            "extendedAmount": "50.00"
          }
        ]
      }
    }
  }
}
  

Benefits and Impacts

• Interchange qualification: Complete L2 and L3 data can route transactions to commercial interchange categories. Potential cost savings depend on your pricing model — interchange-plus vs. flat-rate or tiered.
• Buyer requirements: Many corporate and government buyers require L2 and L3 data for reconciliation and approval. Missing data can delay or block acceptance.
• Operational impact: Submitting enhanced data increases integration complexity, including line-item accuracy, tax and duty handling, and may require invoicing system integration.

What You Should Know and Do

• Confirm processor support. Enhanced data transmission is enabled per connection. Verify with your acquirer or processor before relying on interchange benefits.
• Use the API for L3. Use createTransactionRequest to submit line-item arrays and full L3 data. Hosted and Virtual Terminal flows are typically sufficient for L2 only.
• Validate upstream data. Ensure invoice data — quantities, SKUs, tax, freight, duty, and PO numbers — is accurate. Authorize.net does not validate CEDP compliance on your behalf.
• Include billing and shipping fields. Mastercard commonly requires shipTo.zip and shipTo.country when sending L2 or L3 data. Include these fields when available.
• Confirm your pricing model with your acquirer. Determine whether your account uses interchange-plus pricing (where qualification matters) or flat or tiered pricing (which may not benefit from enhanced data).

Processor Support and Enablement

Support for L3 and Visa CEDP depends on processor implementation and Authorize.net enablement. If your processor is not listed, contact Authorize.net Support.

Processor support may vary by card brand and transaction type. If your processor is not listed above, contact Authorize.net Support.

What Authorize.net Does Not Do

It is important to understand the boundaries of Authorize.net's role in enhanced data processing:

• Authorize.net does not determine interchange qualification. Card networks and processors make that determination.
• Authorize.net does not certify that submitted data meets Visa CEDP validation rules. You and your processor are responsible for ensuring compliance.

Best Practices

• Source data from invoicing systems to avoid mismatches between payment and accounting records.
• Include ship-to ZIP code and country when sending L2 or L3 data to meet Mastercard requirements and improve routing.
• Use purchaseLevel to declare P2 or P3 for Visa CEDP where required by your processor. This field is required for FDIGlobal only.
• Send per-line tax amounts when available. They improve matching and may be required for full L3 qualification.
• Log submitted payloads securely so you can troubleshoot interchange qualification issues with your acquirer.

Troubleshooting and Common Scenarios

Frequently Asked Questions

• • Do I need to use the API to submit Level 3 data, or can I use the Virtual Terminal?
  • L3 line-item data requires API integration using createTransactionRequest. The Virtual Terminal and hosted products — Accept Hosted, Payment Links, and Invoices — support L2 order-level fields only. If you need to submit full line-item detail, you must use the API.
• • Will submitting Level 2 or Level 3 data automatically lower my interchange rates?
  • Not necessarily. Interchange qualification is determined by card networks and processors, not by Authorize.net. If your account is on flat-rate or tiered pricing, interchange qualification may not affect your effective rate. Confirm your pricing model with your acquirer.
• • What is the purchaseLevel field and when do I need to include it?
  • The purchaseLevel field is used to declare P2 or P3 data for Visa CEDP. It is required when using the FDIGlobal processor. Set purchaseLevel = 3 for L3 transactions on FDIGlobal. It is not required for TSYS.
• • Does Authorize.net validate that my submitted data meets Visa CEDP requirements?
  • No. Authorize.net transmits the data you submit but does not validate compliance with Visa CEDP rules. You and your processor are responsible for ensuring the data meets program requirements.
• • My processor is not listed in the supported processor table. Can I still submit enhanced data?
  • Support for enhanced data is connection-specific. If your processor is not listed, contact Authorize.net Support to confirm whether enhanced data submission is available for your configuration.
• • Are there specific fields required for Mastercard when sending L2 or L3 data?
  • Yes. Mastercard commonly requires shipTo.zip and shipTo.country when submitting L2 or L3 data. Include these fields in your API payload whenever they are available.
• • What happens if my corporate or government buyer requires Level 3 data and I cannot submit it?
  • Missing required enhanced data can delay or block transaction acceptance by the buyer. If your buyers require L3 data, implement API integration using createTransactionRequest and confirm that your processor connection supports L3 transmission.

Additional Resources

• Authorize.net API Reference — Complete field-level specifications and sample requests for createTransactionRequest and other payment APIs.

Glossary of Key Terms and Acronyms

The following terms and acronyms are used throughout this article.

• API — Application Programming Interface: A set of protocols that allows software systems to communicate with each other. Authorize.net APIs allow developers to build payment processing directly into a website, application, or back-office system.
• AVS — Address Verification Service: A fraud prevention tool that verifies the billing address provided matches the address on file with the card issuer.
• Acquirer: The bank or financial institution that processes card payments on behalf of a merchant.
• B2B — Business-to-Business: Transactions between two businesses.
• B2C — Business-to-Consumer: Transactions between a business and an individual consumer.
• B2G — Business-to-Government: Transactions between a business and a government entity.
• CEDP — Commercial Enhanced Data Program: Visa's formal program governing commercial card data quality and validation rules for P2 and P3 data.
• CVV — Card Verification Value: A security code printed on a card used to verify card-present or card-not-present transactions.
• Interchange: The fee paid between banks for the acceptance of card-based transactions; set by card networks such as Visa and Mastercard.
• L1 — Level 1: The baseline set of data included in every card transaction.
• L2 — Level 2: Enhanced transaction data including invoice-level summary information.
• L3 — Level 3: The most detailed tier of transaction data, including full line-item detail.
• MCC — Merchant Category Code: A four-digit code assigned to a merchant that classifies the type of business.
• P2 — Product 2: Visa's CEDP term for Level 2 data.
• P3 — Product 3: Visa's CEDP term for Level 3 data.
• PAN — Primary Account Number: The full card number printed on a payment card.
• P-Card — Purchasing Card: A type of commercial card issued to employees for business purchases.
• PO — Purchase Order: A buyer-issued document authorizing a purchase from a seller.
• Processor: The company that handles the technical transmission of payment data between the merchant, card network, and issuing bank.
• SKU — Stock Keeping Unit: A unique identifier assigned to a product for inventory and sales tracking.