Level II and Level III fields allow merchants to pass more detailed information about a transaction to the card networks. By submitting additional fields like tax details, invoice number, product descriptions, and line-item breakdowns, the merchants can qualify for lower interchange fees on eligible business or corporate card transactions.

• Level II data focuses on summary-level information such as customer reference, tax amount, and purchase identifiers.
• Level III data adds granular detail such as the individual product lines, quantity, unit price, and shipping or duty charges.

These fields are primarily applicable to U.S. domestic Visa and Mastercard transactions. If enhanced data is incomplete or invalid, the transaction may still process but will not qualify for enhanced interchange.

A few Business examples are enlisted below:

• Corporate Purchase: A company buys 10 office monitors for $5,000. The merchant includes tax and line-item details to qualify for Level 3 rates.
• B2B Software Renewal: A SaaS vendor charges a corporate client $1,000 plus applicable tax and shipping, submitting invoice and tax details as Level 2 data.
• E-Commerce Order with Multiple Items: A merchant includes full product, discount, and freight details for a multi-item order to meet Level 3 requirements.

ℹ️

This feature requires prior enablement and configuration. Please contact the Account Management team to get started.

How it Works

1. Collect required Level II/III fields during checkout.

2. Make a POST request to /checkout/v3/payment endpoint with including the Level II/III fields.

   Parameter	Required	Description
   amount	✓	Amount to charge (in USD currency)
   cardAccount	✓	Valid Payment Card details or a vaulted token Note: You can vault the card for future use using Card Vaulting guide
   merchantId	✓	The Merchant's unique identifier that is used to process the payment.
   tenderType	✓	Set to CARD for card transactions.
   paymentType		Type of transaction. It is defaulted to Sale
   customerName		The name of the customer. Recommended for guest checkout where the card is not vaulted.
   posData		An object containing Point of Sale data. While optional, we highly recommend including this object for all keyed (card-not-present/online) transactions to improve approval rates and potentially lower processing fees. You can view more details of the recommended POS data based on presentment type here.

3. Once the payment request is submitted, our system performs a series of system-level validations before sending the transaction to the card network. These validations check for:

   1. Missing or invalid required fields
   2. Incorrect parameter formats or values
   3. Merchant configuration or permission issues.
   
   

   If any validation fails, the request is rejected immediately, and an error response is returned. You must correct the issue and resubmit the request. For a complete list of validation errors and how to resolve them, refer to the System Error Codes guide.

4. If all system-level validations pass, our system processes the payment and returns a response indicating the outcome. The Processor forwards data to card networks for interchange qualification. Reduced interchange fees are applied automatically if all conditions are met.

5. You can learn the outcome of the request via GET /checkout/v3/payment/{id} or wait for the Payment webhook You can determine the result by checking the status and responseCode fields in the response.

   1. status: The primary outcome of the transaction, either APPROVED or DECLINED.
   2. responseCode: A detailed code explaining the reason for the status. See our comprehensive Response code guide guide for full list

6. For every approved payment, it is critical to store two identifiers

   1. id : The unique Payment ID. Use this for retrieving or voiding the transaction before it settles.
   2. paymentToken: The secure Transaction Token. Use this for follow-up actions like refunds or adjustments after the transaction has settled.

You can also Retrieve or Update the Level III - Line Data Items included within a Payment.

• Use the GET /checkout/v3/payment/{id}/purchase endpoint to view all the Line Items data for a Payment.
• Use the POST /checkout/v3/payment/{id}/purchase endpoint to update any Line Item data.
• Use the POST /checkout/v3/payment/{id}/L3 endpoint to update any of the L3 data fields such as Freight & Shipping information.

Level I, II and III Data Fields

PCE transmits L2/L3 data, but card brands and processors determine the final interchange category. Ensure data accuracy and retain documentation supporting tax, freight, and itemization.

Key Validations

• Tax for L2 pricing: send a non-zero tax value to qualify for the lowest L2 tiers (Visa/MC). Zero tax is allowed, but may not yield the best L2 rate unless you also pass L3.
• Reconciliation: All amounts must align to -

Σ(unitPrice × quantity) + Σ(taxAmount) − Σ(discountAmount) + shipAmount == amount

• Tax identification flag: (taxExempt) uses enum:
  • 0 no tax info,
  • 1 tax amount provided,
  • 2 item exempt/non-taxable.
• The sum of all line items, plus tax and freight, must equal the total transaction amount.
• Use valid ISO country and currency codes.
• tax present and > 0 for lowest L2 tiers (Visa/MC)
• taxExempt values limited to 0|1|2 and consistent with item taxation
• shipToCountry is ISO alpha‑3 (e.g., USA)
• Line items roll up to amount via the reconciliation formula
• Auth/Capture gap ≤ 2 days (where applicable)

Missing or invalid data may cause the transaction to be downgraded to a higher interchange rate.

See Also

• Address Verification System (AVS)
• Payments lifecycle