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.

---

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.

---

Card-brand matrix

Use the matrix below to understand which enhanced data requirements apply by card brand. Card brands and processors determine final interchange qualification, so use this table as implementation guidance and confirm merchant eligibility before processing production volume.

---

Level I, II and III Data Fields

Use the table below to identify which fields merchants can submit at each interchange level. The L1, L2, and L3 columns mark the level at which each field is used, and fields required at a lower level also apply to higher levels. Refer to the card-brand matrix above for how Visa and Mastercard evaluate this data.

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 L3 data is also passed.

• Reconciliation: line items, tax, discounts, and shipping must roll up to the transaction amount using the formula:

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

• Tax identification flag: taxExempt uses the enum 0 (no tax info), 1 (tax amount provided), or 2 (item exempt / non-taxable). Values must be consistent with item taxation.

• ISO codes: use valid ISO country and currency codes. shipToCountry must be ISO alpha-3 (e.g., USA).

• Auth/capture and CEDP timing: for eligible Visa commercial card transactions, invoice-quality Level II/III data must be submitted within 96 hours of authorization. Keep the authorization-to-capture gap within the required processing window. Delayed capture or delayed enhanced data submission may prevent the transaction from qualifying for CEDP rates.

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

Invoice-quality data anti-patterns

For Level III data, line-item details must describe the actual goods or services purchased. Visa may reject generic placeholder values because they do not provide enough invoice-level detail for interchange qualification.

Avoid sending static or generic values in fields such as purchases.name, purchases.description, or purchases.code.

Invoice-quality data should be specific to the transaction and should match the merchant’s invoice or order record.

Good Level III line-item data includes:

• A clear product or service name
• A specific description of what was purchased
• Quantity
• Unit price
• Tax amount, when applicable
• Shipping or freight amount, when applicable
• Line-item totals that reconcile to the full transaction amount

Do not reuse the same placeholder description across unrelated transactions. Placeholder values may cause the transaction to lose enhanced interchange qualification or be downgraded to a higher interchange rate.

---

See Also

• Address Verification System (AVS)
• Payments lifecycle