Missing Level 3 data added 180bps to a B2B card transaction

The discrepancy in the effective rate on a chunk of transactions led to a closer look at the data being used for processing. The transactions in question were for a specific type of card, within a particular MCC range, and with ticket sizes that matched the acquirer contract. However, there was a noticeable split in the fee line. The culprit was found to be the missing Level 3 data.

Commercial and purchasing cards are eligible for lower interchange fees if the merchant provides additional fields: tax amount, PO number, customer code, and for Level 3, line-item detail including SKU, quantity, unit price, and commodity code. The company's integration was only sending Level 1 data, consisting of card number, amount, and date. This was due to the checkout form only collecting this information. As a result, every one of these transactions was auto-downgraded to the standard commercial rate.

A month's worth of transactions was analyzed, revealing a significant difference in the effective rates. Transactions with full Level 3 data settled at approximately 1.8%, while those missing the data settled at around 3.6%. This gap, when multiplied by the company's six-figure monthly volume, was not just a rounding error but a significant line item that finance would need to address.

The issue was resolved by making tax amount and PO number required fields before authorization, as well as pulling line-item detail from the existing order object in the database. The rate on new transactions dropped within one billing cycle. However, a question remains about how to validate that the L2/L3 fields are actually populated before the authorization request is sent, rather than just present in the schema.