Stripe Level 3 Data, and the QuickBooks Fee It Changes

Two businesses run the same sale on the same day. Same product, same price, same buyer, both charging through Stripe. One of them pays more to process it than the other.

Nothing about the sale is different. What is different is how much detail each one attached to the payment request.

This is Level 2 and Level 3 card data, and it is one of the very few places in payments where the fee is a function of the data you send rather than the amount you charge. Stripe supports it through a feature it calls payment line items. The effect arrives in QuickBooks as a processing fee that is slightly smaller than it otherwise would have been, with nothing in your books to say why.

Most of what is written about Level 2 and Level 3 online is also out of date, because Visa retired half of it in April 2026.

If what you actually want is for your Stripe fees to land in QuickBooks against the right account, whatever interchange did, you can start a free trial.

Read this section first, because most Stripe businesses can stop here

The conditions are narrow, and Stripe states them plainly. If you do not meet all of them, sending line item data will not lower a single fee.

You have to be on interchange-plus pricing. Stripe describes the benefit as "Cost savings for eligible commercial cards for IC+ users", and defines IC+ as "A pricing plan where businesses pay the variable network cost for each transaction plus the Stripe fee rather than a flat rate for all transactions."

This is the condition that disqualifies most readers, and it deserves to be blunt. On Stripe's standard blended pricing, you pay the same published rate whether or not you send line item data. The interchange saving is real, but it accrues where the price you pay actually tracks interchange. If your Stripe pricing is a flat percentage plus a fixed amount, this whole topic is an engineering project with no effect on your fee. Our guide to Stripe's fee structure covers which pricing model you are likely on.

The buyer has to be paying with a commercial card. For Level 2, Stripe says "Only Business, Purchasing, and Corporate cards are eligible." For the Level 3 tier, Visa Product 3 covers "Purchasing, Corporate, and Business cards" and Mastercard Level 3 covers "Purchasing and Corporate cards only." A consumer Visa is not eligible at any level, so a business selling to the public gains nothing here.

The geography is restricted. Stripe supports the program for "US domestic transactions (US users accepting US issued cards, excluding US territories), and intra-EU transactions (EU businesses accepting EU cards)."

The network matters. It is "Only supported for Visa, Mastercard, and American Express", and Stripe notes that on Amex, "cost savings requires direct agreement with American Express."

Your merchant category code has to be eligible. Stripe publishes exclusion lists per network. Restaurants (5812), hotels (7011), airlines and several transport and rental categories are excluded, and the Level 3 exclusion list is longer than the Level 2 one.

It runs through the PaymentIntents API. The data is carried on the PaymentIntent, so a business collecting card payments some other way is not passing it.

If you are a B2B seller on interchange-plus pricing, invoicing US or EU business customers who pay with corporate or purchasing cards, keep reading. Everyone else can safely file this away.

What the two levels actually are

Strip away the card-network vocabulary and the distinction is simple. Stripe puts it in two lines:

• Level 2 is "sales tax charged on transactions".
• Level 3, now Product 3, is "line item level breakdown such as product code, quantity, unit cost".

That is the entire idea. Level 2 tells the issuer what tax was on the sale. Level 3 tells the issuer what was actually sold, item by item.

The reason issuers pay for this is that a corporate card program needs to police spending. A card statement line reading "$4,182.00, ACME SUPPLY" tells a controller nothing about whether the purchase was a legitimate business expense. A line item breakdown showing twelve units of a specific SKU at a specific unit cost does. Detail lowers the issuer's risk, and the interchange schedule prices that difference.

Visa retired Level 2 in April 2026

This is the fact that dates most other writing on the subject, and it is worth stating before any of the field detail.

Stripe's documentation carries the note directly: "Visa Level 2 was sunset in April 2026 and is no longer available. Visa savings are now available through Product 3 (CEDP) only."

CEDP is Visa's Commercial Enhanced Data Program, which Stripe describes as replacing "their U.S. Level 2/3 interchange programs".

The practical consequence for anyone planning work here: on Visa, there is no longer a cheaper intermediate tier you can reach by sending tax data alone. You either send the full line item breakdown and qualify for Product 3, or you send nothing that qualifies. Mastercard still operates a Level 2 tier. Any implementation guide, ours included, that describes Visa Level 2 as a lighter-weight option to start with is describing a program that no longer exists.

The fields, and which tier needs which

Stripe splits its field documentation into two useful categories. A "Required field" is one you must pass for Stripe's own validation to accept any line item data at all. "Required for L2 or L3" is one you must pass to actually receive the network rate.

For Level 2 on Mastercard, the minimum is short:

Field	Purpose
amount_details[tax][total_tax_amount]	The total tax on the transaction
payment_details[order_reference]	"A unique value assigned by the business to identify the transaction"

For Level 3 and Product 3, the list is the real work:

Field	Constraint Stripe documents
line_item[product_name]	Required for L3. Max 1024 chars, but "Cards truncates to 26 alphanumeric characters"
line_item[unit_cost]	Required for L3. In the smallest currency unit, value must be at least 0
line_item[quantity]	Required for L3. Must be greater than 0
line_item[product_code]	Required for L3. "Max length 12 chars"
line_item[unit_of_measure]	Required for L3. "Max length 12 chars", alphanumeric
line_item[tax][total_tax_amount] or the transaction-level equivalent	Required for L3
payment_details[order_reference]	Required for L3, "truncated to 25 alphanumeric characters, excluding spaces"

Three of those constraints will bite a real catalogue, and they are worth checking before anyone writes code.

Product names are truncated to 26 alphanumeric characters for cards. Not 1024. If your product names are descriptive, the issuer sees the first 26 characters, and "Annual Maintenance Contract, Tier 2, West" and "Annual Maintenance Contract, Tier 3, West" are indistinguishable by the time they arrive.

Product codes are capped at 12 characters. Plenty of internal SKU schemes are longer than that.

Units of measure are capped at 12 alphanumeric characters. Stripe gives "gallons, feet, meters, generic measurements (such as each)" as examples. A services business that has never had a unit of measure has to invent one, and it has to be consistent, because it is now part of a qualification test rather than a label.

There is also a ceiling on the line items themselves. Stripe "Currently supports 200 line items", with a caveat that matters for anyone selling on Amex: "American Express Specification restricts us to send them only the first 4 line items."

Sales tax carries its own rules. For Level 2 on Mastercard the tax must fall between 0.1% and 30%, and on Visa between 0.1% and 22%, with named MCC exceptions. For Level 3, Stripe says tax is "Not required for Level 3/Product 3 rates. 0 is acceptable if no sales tax is collected but an accurate value must be reported."

That last clause is easy to skim past. Zero is acceptable, guessing is not.

Nothing tells you when you fail to qualify

This is the part that makes the whole subject hard to manage, and Stripe is admirably direct about it:

"Stripe API doesn't reject line items that don't meet the network MCC and/or tax requirements, but these transactions don't qualify for the corresponding Level 2/3 savings."

Read that as an operational warning. A payment with line item data that misses a requirement is not an error. It succeeds. The customer is charged, the charge settles, the money arrives, and the transaction simply does not qualify. There is no failed webhook, no exception in your logs, and nothing on the QuickBooks side that looks different from a qualifying one.

So a team can build the whole integration, ship it, and never learn that a truncated product code or an out-of-band tax rate is quietly disqualifying every transaction. The only evidence is a fee that did not go down, which is a very hard thing to notice.

There is a second, louder failure mode. Stripe runs arithmetic validation on the amounts, and documents two error codes:

• amount_details_amount_mismatch: "The sum of the line items does not match the amount on the PaymentIntent."
• amount_details_tax_shipping_discount_greater_than_amount: "The sum of tax + shipping - discount is greater than the amount on the PaymentIntent."

By default this validation is enforced and a mismatch is rejected. You can turn it off by setting enforce_arithmetic_validation to false, and Stripe then records what it found rather than blocking the payment. Its documentation says the error object "populates when the amount details has a validation error that wasn't enforced because the enforce_arithmetic_validation parameter was set to false."

Turning enforcement off is reasonable if your line item detail is approximate and you would rather take the payment. Just be clear about the trade. You have converted a hard failure into a field that nobody reads.

Two smaller traps worth knowing. Transaction-level tax and line-item-level tax are mutually exclusive, and so are transaction-level and line-item-level discounts. You pick one shape and use it consistently.

What any of this does to your QuickBooks file

Here is the honest answer, and it is narrower than most readers expect.

Acodei's product documentation describes no handling of Stripe's line item detail object. There is no setting that sends Level 3 data, no field that stores it, and no behaviour that preserves it on a synced record. Acodei does not populate this data and does not optimise for it. If you want line item detail on your payments, that is work in your payment integration, upstream of any accounting sync.

What the sync sees is the outcome. By the time a fee reaches your books, interchange has already been decided by the card networks, and Stripe has already deducted its charge. Acodei records what Stripe charged.

That is worth saying plainly because it sets the expectation correctly: Level 3 data is a payments project with an accounting side effect, not an accounting project.

The accounting side effect is real, though, and it lands in a specific place.

Where the fee actually lands, and why the saving is invisible

Acodei creates a QuickBooks product called "Stripe Fees – Acodei" during onboarding and maps it to an account you choose. Every Stripe fee is assigned to that product, which avoids maintaining a separate product per fee type.

From there, how the fee appears depends on a setting. Under Account Mapping, then Fee Management, Acodei documents three placements:

1. As a line item on the Sales Receipt. This is the default. The fee is recorded as a negative line using the mapped Stripe-fee product, which nets the receipt down to what actually entered your Stripe balance.
2. As a line item on the Bank Deposit. Available with Undeposited Funds. This keeps sales receipts free of fees and applies them when the deposit is recorded, so each receipt shows gross sales.
3. As an Expense. Available by default on the non-Undeposited-Funds workflow, and with Undeposited Funds only when Invoice Sync is enabled. The fee posts as a separate Purchase or Expense and the receipt stays gross.

Fees are never added to the invoice itself. Acodei's documentation is explicit that putting them there would throw off the invoice total and cause a payment receipt mismatch.

Now the point. In every one of those three shapes, a fee that qualified for a lower interchange rate looks exactly like a fee that did not. It is the same product, the same account, the same line. It is just a smaller number.

Nothing in QuickBooks records which card type was used, which tier the transaction qualified for, or whether line item data was sent at all. There is no marker to filter on and nothing to report against. If you spend a quarter implementing Level 3 data, your fee expense account will trend slightly down, mixed in with every other thing that moves that number: sales volume, card mix, refunds, dispute fees, and Stripe's own product fees.

This is not a gap in the sync. It is a property of the data. The qualification decision happens at the card networks and is not carried on anything that reaches your accounting system.

If you want to measure the effect, measure it on the Stripe side, where the balance transaction for each charge carries the actual fee taken. Compare effective rate for commercial-card transactions before and after the change, and hold your card mix constant while you do it. Our Stripe fee reconciliation guide covers the mechanics of getting fee data lined up in the first place.

One configuration detail that will bite you

If you run Acodei in daily summary mode, there is a setting that changes how useful your fee number is for this.

Acodei documents that fees are split into two categories following Stripe's balance transaction taxonomy. Transactional fees are the fee on a charge, payment, or refund balance transaction. Non-transactional fees are standalone entries such as stripe_fee, network_cost, and application_fee, along with adjustments in the fee reporting category, which is where Billing, Radar, and Stripe Tax product charges live. On the daily summary, per-user flags route each category either onto the summary line items or into a separate Purchase, so transactional fees can be netted on the summary while Stripe's service fees post as expenses. Acodei documents that the default preserves the older behaviour of one combined Purchase.

That split matters for exactly the measurement problem above. Interchange only moves the transactional half. Leave both categories combined and your monthly fee number blends per-transaction processing cost with your Stripe subscription charges, so the interchange effect gets buried under a Billing fee that has nothing to do with card data. Separating them gives you a cleaner number to watch.

One more operational note. Acodei's documentation states that changing your fee method does not retroactively update historical transactions. If you change it, older records keep their old shape until you resync them. Decide on the shape before you start measuring, not halfway through.

What to do this week

If you are on interchange-plus pricing and sell to businesses:

1. Check your card mix first. Pull your Stripe charges and find what share came from commercial cards. If it is a rounding error, stop. Everything below is effort against a fraction of a fraction.
2. Check your MCC against Stripe's exclusion lists for both networks. If you are excluded, stop.
3. Audit your catalogue against the three limits. Product codes at 12 characters, units of measure at 12, and product names that stay distinct within the first 26 alphanumeric characters. This is usually the real project.
4. Decide about arithmetic validation deliberately. Leaving it enforced is the safer default. If you turn it off, put the error field somewhere a human sees it.
5. Separate your fee categories in Acodei before you start, so the number you are watching is the number interchange actually moves.
6. Measure in Stripe, not in QuickBooks. Your books will show the result. They will never show the cause.

If you sell to consumers, or you are on blended pricing, the honest recommendation is to skip this entirely and spend the time on something that moves a larger number.

Frequently asked questions

Does sending Level 3 data lower my Stripe fees?

Only on interchange-plus pricing. Stripe documents the cost saving as applying to "eligible commercial cards for IC+ users", where IC+ means you pay the variable network cost per transaction plus Stripe's fee. On standard blended pricing you pay the published rate regardless, so line item data changes nothing about what you are charged.

Is Level 2 still available?

On Mastercard, yes. On Visa, no. Stripe's documentation states that "Visa Level 2 was sunset in April 2026 and is no longer available. Visa savings are now available through Product 3 (CEDP) only." Visa's Commercial Enhanced Data Program replaces its previous US Level 2 and Level 3 interchange programs.

Which cards qualify?

Commercial cards only. Stripe lists Business, Purchasing, and Corporate cards as eligible for Level 2. For the higher tier, Visa Product 3 covers Purchasing, Corporate, and Business cards, while Mastercard Level 3 covers Purchasing and Corporate cards only. Consumer cards do not qualify at any level.

What happens if my line item data does not meet the requirements?

Nothing visible. Stripe states that its API "doesn't reject line items that don't meet the network MCC and/or tax requirements, but these transactions don't qualify for the corresponding Level 2/3 savings." The payment succeeds and simply does not qualify, which is why this needs checking deliberately rather than waiting for an error.

Does Acodei send Level 3 data to Stripe for me?

No. Acodei's product documentation describes no handling of Stripe's line item detail, in either direction. Sending that data is work in your payment integration. Acodei records the fee Stripe charged, after interchange has already been determined.

Will I see the interchange saving in QuickBooks?

Not as a distinct figure. The fee arrives as one amount and is recorded against the mapped Stripe fee product, either as a negative line on the sales receipt, a line on the bank deposit, or a separate expense. A qualifying transaction and a non-qualifying one produce the same record shape with different numbers, and nothing marks which was which.

How many line items can I send?

Stripe "Currently supports 200 line items." There is an important exception for American Express, where Stripe notes the "American Express Specification restricts us to send them only the first 4 line items."

Should I turn off arithmetic validation?

Only with a reason. By default Stripe rejects a payment whose line items do not sum to the PaymentIntent amount. Setting enforce_arithmetic_validation to false lets it through and records the problem in an error field instead, with codes including amount_details_amount_mismatch. That is a legitimate choice when your line detail is approximate, but it moves a hard failure into a field nobody is watching unless you build the alerting.

---

Acodei syncs your Stripe activity into QuickBooks and records fees where you tell it to, on the sales receipt, the bank deposit, or as a separate expense, so the number you are trying to watch is actually the number you are looking at. Start a free trial or see how Stripe to QuickBooks sync handles fees end to end.

Sources: Stripe's payment line items documentation and PaymentIntent object reference, both fetched September 2026.