A Technical and Financial Guide for Microsoft Dynamics 365 Administrators and Finance Operations Teams

For teams managing payment infrastructure inside Microsoft Dynamics 365 environments, processing fees are often treated as a fixed cost. Invoices go out, payments come in, fees are settled. But a significant and largely invisible expense hides inside every B2B card transaction: interchange rates set at the wrong data level, because the payment layer never reaches into the ERP to retrieve the data that would qualify for a lower rate.

This guide covers the technical mechanics of Microsoft Dynamics 365 B2B Level 2 and Level 3 payment data — what the data levels require, why most Microsoft Dynamics 365 environments default to Level 1 even for corporate card transactions, and exactly how the SensePass connector bridges the gap to qualify B2B transactions for the lowest applicable interchange tier. We also quantify what that means financially.

For foundational context on how payment gateways connect to Microsoft Dynamics 365 in the first place, see the Microsoft Dynamics 365 payment gateway integration guide.

Payment Data Levels: Technical Definitions

Interchange rates set by Visa and Mastercard are not flat. They vary based on the richness of structured data submitted with each transaction at settlement. Understanding the field requirements at each level is the starting point for understanding why most B2B businesses leave money on the table.

Level 1 (L1) — Baseline Transaction Data

The minimum required for any card transaction to be authorized and settled:

• Merchant name and Merchant Category Code (MCC)
• Transaction amount and currency
• Transaction date
• Card number and expiration

This is what the majority of payment systems submit by default. With no additional context provided, card networks apply their highest interchange tier. Consumer credit and debit transactions are priced here.

Level 2 (L2) — Enhanced Purchasing Data

Adds structured fields on top of L1, enabling corporate and government purchasing cards to qualify for reduced interchange:

• Tax amount — submitted as a discrete field, not embedded in the transaction total
• Customer code / PO reference — a buyer-supplied reference, typically a purchase order number
• Merchant postal code — zip code of the merchant location

When these fields are present and correctly formatted, qualifying card types (corporate, government, purchasing) can settle at L2 interchange rates. Savings over L1 typically range from 0.25% to 0.5% depending on card type and network.

Level 3 (L3) — Full Line-Item Detail

The most complete data submission. Adds to L2:

• Line-item descriptions — individual product or service descriptions per line
• Commodity / product codes — standard classification codes (UN/SPSC or similar)
• Quantity and unit of measure — per line item
• Unit price — individual item price before tax
• Ship-to postal code — destination zip code
• Freight amount — shipping charge as a discrete field
• Duty amount — applicable for international transactions
• Order/invoice reference — merchant-side transaction identifier

When all required L3 fields are present at settlement, qualifying card types settle at the lowest available interchange tier. Savings over L1 commonly reach 0.5% to 1.5%, and in some purchasing card categories, higher.

The savings come from the card network’s published interchange schedule — not from the processor. Processors who support L3 submission pass the lower network rate through to the merchant. The technical requirement is that all fields are populated, correctly typed, and submitted via the processor’s L3-capable API endpoint at settlement.

Why Most Microsoft Dynamics 365 Environments Default to L1

The data required for L2 and L3 is present in virtually every Microsoft Dynamics 365 B2B environment. Tax amounts, PO references, line-item detail, product codes, ship-to addresses — all of it is captured at the sales order and invoice level as a matter of standard ERP operation.

The problem is architectural: a disconnection between the payment processing layer and the Microsoft Dynamics 365 data layer.

Standard payment gateways — including most certified Dynamics payment partners — accept a transaction authorization, capture the payment amount, and close the settlement without reading the order data sitting inside Microsoft Dynamics 365 environments. They have no mechanism to access the line-item records, tax fields, or customer codes that would qualify the transaction for L2 or L3.

The result: businesses using corporate purchasing cards — which are contractually eligible for L2/L3 rates — continue paying L1 interchange because the enrichment never happens.

For a broader overview of how this fits into the cost structure of Microsoft Dynamics 365 credit card processing, including where fees originate and what levers merchants can realistically control, the SensePass cost guide covers each component in detail.

How the SensePass Connector Implements Microsoft Dynamics 365 B2B Level 2 and Level 3 Payment Data

SensePass is a payment connector built for Microsoft Dynamics 365 that operates at the intersection of Microsoft Dynamics 365’s transaction data and the payment processor’s API. Its L2/L3 implementation has three functional layers: B2B identification, data assembly, and enriched submission.

Layer 1: B2B Transaction Identification

Not every payment in a Microsoft Dynamics 365 environment is a B2B transaction. Many businesses serve a mix of individual and corporate customers. SensePass resolves this by evaluating the customer record and payment method at the point of transaction initiation.

The connector checks whether the paying entity is flagged as a business customer in Microsoft Dynamics 365’s customer records. If confirmed as B2B, the transaction is routed through the L3 enrichment pipeline. If identified as B2C, it is processed at standard L1 — no enrichment, no incorrect data submitted to a consumer card.

Classification is automatic. No manual flagging is required from the AR team or the customer.

Layer 2: L3 Data Assembly from Microsoft Dynamics 365 Records

Once a transaction qualifies for L3 enrichment, SensePass reads the required fields directly from the existing Microsoft Dynamics 365 transaction. No duplicate data entry, no parallel system, no manual export.

L3 Required Field	Microsoft Dynamics 365 Data Source
Tax amount	Invoice tax line (separate from total)
Customer reference / PO number	PO field on the associated Sales Order
Line-item descriptions	Item lines on the Sales Order / Invoice
Commodity / product codes	Item record (custom field or standard code)
Quantity and unit of measure	Invoice line-item data
Unit price (pre-tax)	Invoice line-item data
Ship-to postal code	Shipping address on the transaction
Freight amount	Shipping charge line on the Invoice
Merchant postal code	Company record / subsidiary address
Order reference	Microsoft Dynamics 365 transaction number

The connector reads natively from Microsoft Dynamics 365 — no ETL process, no middleware, no manual data transfer step.

Layer 3: Enriched Submission to the Processor

The assembled L3 payload is submitted to the payment processor using the processor’s L3-capable API endpoint at settlement. This is a technical requirement: not all processors support Level 3 data submission, and those that do require fields to be mapped to their specific schema. SensePass handles field mapping, formatting, and endpoint routing to ensure the submission meets the processor’s L3 qualification criteria.

At settlement, the card network processes the transaction at the enriched data tier and applies the lower interchange rate.

This flow also connects directly to automated payment reconciliation in Microsoft Dynamics 365, ensuring that lower-fee settlements post accurately to the GL with full metadata, without manual ledger entries.

Financial Impact Model

The realized savings from L2/L3 submission depend on transaction volume, average order value, card mix (proportion of purchasing vs. consumer cards), and which processor and network are in use. The following model represents a realistic mid-market scenario:

Parameter	Value
Annual B2B card payment volume	$3,000,000
Current blended interchange rate (L1)	2.70%
L3 rate — purchasing card category	1.90%
Effective rate differential	0.80%
Estimated annual interchange savings	$24,000
Implementation overhead	Zero (reads existing Microsoft Dynamics 365 data)
Workflow change required	None

For enterprise-scale environments processing $10M+ in B2B card receivables annually, the savings case compounds significantly. At a 0.80% rate differential, $10M in volume yields $80,000 per year in recurring interchange savings — automatically.

The key variable is card mix. The L2/L3 benefit applies specifically to corporate, purchasing, and government cards. Consumer credit cards do not carry these rate tiers. Businesses where the majority of B2B customers pay with corporate purchasing cards will see the highest impact.

Implementation Considerations for Microsoft Dynamics 365 Administrators

Before deployment, the following technical points are worth evaluating:

Processor L3 support. Level 3 data submission requires a processor with L3-capable API endpoints for the relevant card types. SensePass supports L3 submission across compatible processors. Confirming your current or intended processor’s L3 support for purchasing cards is a useful pre-deployment step. For a full comparison of Microsoft Dynamics 365 payment gateway options and their B2B capabilities, the SensePass gateway guide covers the ecosystem in detail.

Microsoft Dynamics 365 data completeness. Since L3 enrichment reads directly from existing Microsoft Dynamics 365 records, the quality of those records determines the quality of the submission. Transactions missing item codes, incomplete shipping fields, or absent PO references may submit at L2 rather than L3. A targeted data quality review of item records, customer records, and sales order field completion is recommended before go-live.

Card type mapping. Ensuring that incoming corporate and purchasing cards are correctly identified at the customer level in Microsoft Dynamics 365 improves classification accuracy. SensePass handles the B2B/B2C determination logic, but clean customer data strengthens the match.

No AR workflow disruption. The connector operates entirely at the payment processing layer. Existing AR workflows, invoice generation, payment application, and bank reconciliation processes inside Microsoft Dynamics 365 environments are unaffected. The change is invisible to the finance team’s daily operations.

GL posting. Lower interchange fees mean lower fee amounts posting to your payment processing GL accounts. The automated reconciliation layer in SensePass handles this posting natively — no manual adjustment required.

For teams managing high-volume B2B receivables who want to understand the full scope of strategies available to reduce Microsoft Dynamics 365 credit card processing fees — including processor negotiation, ACH migration, and payment method diversification alongside L2/L3 — the SensePass cost optimization guide covers each in detail.

Summary

Microsoft Dynamics 365 B2B Level 2 and Level 3 payment data represents a built-in cost-reduction mechanism in the card network interchange schedule that most B2B businesses never access. The reason is a structural gap: standard payment gateways don’t read ERP data, and the ERP doesn’t push it to the payment layer. The result is that corporate purchasing cards — designed for L2/L3 — settle at L1 rates by default.

SensePass closes this gap natively inside Microsoft Dynamics 365 environments. By automatically identifying B2B transactions, assembling the complete L3 data payload from existing Microsoft Dynamics 365 records, and submitting it to the processor at the correct API endpoint, it enables merchants to capture interchange savings that would otherwise remain unrealized — with no workflow changes, no additional data entry, and no disruption to existing AR operations.

For finance and operations teams already running SensePass for Oracle Microsoft Dynamics 365, L2/L3 processing is a native capability of the connector. For teams evaluating SensePass, the Microsoft Dynamics 365 payment gateway page covers the full integration scope, including setup timelines, processor compatibility, and supported payment methods.

For a full breakdown of how payment processing fees are structured across interchange, assessments, and processor markup — and where L2/L3 fits within that picture — see the SensePass fee breakdown guide.

→ See how SensePass connects to your Microsoft Dynamics 365 environment