Supported
Integration
Supported
Use Cases
Timeline
Why Finance & Operations customers add Payment Hub, and what changes when they do
So it looks like Dynamics AX has finally been replaced. Dynamics 365 Finance & Operations is an enterprise ledger with a serious AR module: payment journals, settlement, credit and collections, intercompany. What it does not include is a way for a customer to pay an invoice by card or bank and have that payment arrive as a posted, settled journal without a person in the loop.
The F&O customers we work with have usually already automated the bank side. Lockbox files import. Bank statements reconcile through advanced AI reconciliation. What still runs on people is card and portal payment. A customer wants to pay an invoice on a corporate card, so someone in the shared service center takes the number over the phone, runs it in a virtual terminal, and keys a customer payment journal line the next morning from the processor's report, then settles it. Multiply that across four legal entities and a few hundred payments a month and it is a full-time role.
So how does Payment Hub help? Payment Hub closes the loop on a few fronts. The customer pays from a link on the invoice, or from a portal that reads open transactions across the entities they buy from, or the shared service center takes the card in a compliant surface. Payment Hub creates the customer payment journal in the right legal entity, posts it, and settles it against the invoice or prepayment it pays. The AR analyst reviews a posted journal instead of building one.
What shows up as an issue in the system, replicates to every customer. That's what makes settlement an enterprise problem rather than a small one. A payment that is posted but not settled correctly shows up in aging, in collections worklists, in dunning letters and in the customer's next statement. Getting the settlement right at the moment of payment, in the right entity, is worth more than the keystrokes it saves.
What stays in Finance & Operations
F&O remains the system of record. Customers, sales orders, free text and sales invoices, prepayment invoices, customer payment journals, settlements and the general ledger all stay in F&O. Payment Hub reads what it needs through data entities and writes payment journals in exactly the shape your AR team would create by hand, so every report, worklist and aging looks the same.
Your F&O configuration does not change. Legal entities, methods of payment, terms of payment, number sequences, credit management and Electronic reporting formats all stay as configured. Payment Hub adds a payment link to the invoice format you already send and a portal beside F&O, not inside it.
Where Finance & Operations runs, and what Payment Hub does in each
F&O is deployed across enterprise manufacturing, distribution, services and retail, almost always with more than one legal entity. Payment Hub works across all of these, and the payment pattern that matters most shifts with the business.
Manufacturing
Distribution
Services
Consumer Goods
& Healthcare
Holding Groups
Manufacturers and distributors on F&O carry the most open AR and get the most from the portal, consolidated invoice payment and Level III. Professional services firms run on prepayment invoices and milestone billing, and want prepayments settled correctly against the final invoice. Retail and consumer goods companies usually already run Dynamics 365 Commerce for the storefront and use Payment Hub for the B2B invoice side Commerce does not cover. Holding groups with a shared service center care most about entity routing and one reconciliation view.
Because an F&O tenant nearly always spans two of these, the full feature set is installed and each entity enables what it uses.
Payment Hub vs native Dynamics 365 payment options, honest side-by-side
Microsoft's own card processing for Dynamics 365 lives in Commerce, through the Dynamics 365 Payment Connector for Adyen and partner connectors, and it is built for point of sale and ecommerce. F&O accounts receivable has no equivalent for invoice payment. It is worth being precise about what each covers.
| Capability | Native D365 (Commerce payment connector) | Payment Hub on D365 F&O |
|---|---|---|
| Scope | ✗ Point of sale and Commerce storefront transactions | ✓ AR invoice, prepayment, order and portal payments posted as customer payment journals |
| Gateway / processor choice | ✗ Adyen through Microsoft's connector, or a partner-built connector | ✓ 19+ gateways on your merchant account: Worldpay, Adyen, Cybersource, Fortis, PayTrace, Stripe, Braintree, Authorize.Net and more |
| Customer self-service portal for AR | ✗ Not included | ✓ Branded portal reading open customer transactions across legal entities |
| Click-to-pay links on invoices | ✗ Not included | ✓ Payment link on the Electronic reporting or SSRS invoice format you already use |
| Settlement against open transactions | ✗ Not applicable to AR invoices | ✓ Payment journal settled against the invoice or prepayment at posting |
| Multi-legal-entity routing | ✓ Per-entity configuration in Commerce | ✓ Routing by legal entity, merchant account, bank and offset account from one configuration |
| Level III line-item data | ✗ Not sent for AR | ✓ Sales order line detail attached to eligible commercial card transactions |
| ACH / eCheck | ✗ Card-focused | ✓ ACH, eCheck and card on one portal, all posted as payment journals with the right method of payment |
If your business is Commerce-first and card payments happen at a register or a storefront, Microsoft's connector is the right tool for that traffic. Payment Hub is for the AR side: invoices, prepayments, statements and portals. Most enterprises on F&O end up running both, one for Commerce and one for AR, and the two do not compete.
The Missing LinkBetween Paymentsand Your ERP
Clarity Payment Hub closes that gap, connecting your orders, invoices, and payment channels into one flow.
Speak to a Platform ArchitectHow Clarity Connect integrates Payment Hub with Finance & Operations
The integration runs on the OData data entities Microsoft ships and maintains for Finance & Operations, authenticated through an Entra ID app registration. Eight capabilities make up the integration, and none of them are deployed as X++ extensions or custom models in your environment.
OData data entity integration
Payment Hub reads and writes through standard entities: CustomersV3, SalesOrderHeadersV2 and lines, customer invoice journals, open customer transactions, and CustomerPaymentJournalHeaders / Lines. Authentication is OAuth 2.0 through an Entra ID app registration scoped to the F&O environment. Every call is logged.
Posted and settled payment journals
A payment taken in the portal, on an invoice link or by the shared service center becomes a customer payment journal line in the right legal entity, posted, and settled against the invoice or prepayment it pays. Unapplied and on-account payments post with the customer set so AR can settle them from the open transactions form.
Prepayment and order-aware order-to-cash
Prepayment invoices on sales orders, milestone invoices on projects and final sales invoices are handled as separate payments that settle correctly. This battlecard marks sales order payments as standard for F&O, and the prepayment flow is why.
Level III auto-enrichment
Sales order line detail, including item, quantity, unit price, tax and ship-to, is attached to eligible commercial card transactions so they settle at Level III interchange. At enterprise volume this is usually the largest single saving.
Multi-legal-entity and shared-service routing
Each legal entity is mapped to its merchant account, bank account and offset account. Payments route to the entity that issued the invoice, and the shared service center sees every payment across entities in one reconciliation view.
Tokenized method vault
Cards and bank accounts are tokenized at the gateway and stored against the F&O customer, so portal payments, autopay and shared-service phone payments never put card data in F&O, in Dataverse or on your network.
Recurring and scheduled payments
Statement autopay, installment plans from collections and fixed monthly draws for service contracts run on the scheduler, with dunning on failed attempts and every run posting as a normal customer payment journal.
Compatible with dual-write, Power Platform and One Version
The integration sits beside dual-write to Dataverse, Power Automate flows and your ISV solutions. It uses only standard entities, so One Version updates do not affect it and no custom model has to be regression-tested each release.
The integration workflow, prepayment invoice to settled payment journal across two legal entities
A concrete walk-through. An industrial equipment group on Finance & Operations with four legal entities and a shared service center in Dallas takes a $212,000 order in its US manufacturing entity for a customer who also buys parts from its Canadian distribution entity. Terms call for a 25 percent prepayment. Payment Hub handles the prepayment, the final invoice, a parts invoice in the other entity, and the settlement of all three.
Sales creates the order and prepayment invoice in F&O
The account manager creates sales order SO-004412 in legal entity USMF for Meridian Process Systems: $212,000 for a packaged compressor skid with a 25 percent prepayment. F&O posts prepayment invoice PPI-000871 for $53,000 from the order.
USMFSales OrderPrepayment InvoicePrepayment paid from the invoice link
The prepayment invoice goes out on the standard Electronic reporting format with a Payment Hub link. Meridian's AP pays it by ACH. Payment Hub records the bank payment against the USMF bank account.
Click-to-PayACHPayment journal posted and settled in USMF
Payment Hub creates a customer payment journal in USMF through the data entities, posts it, and settles it against PPI-000871 with the ACH method of payment and the correct offset. The shared service center sees a posted, settled journal, not a report to key.
Payment JournalSettledMeanwhile, parts invoice in the Canadian entity
Meridian's Alberta plant orders spare parts from legal entity CAND. F&O invoices CAD 8,400 as sales invoice CINV-102233. The same portal login shows this invoice beside the USMF prepayment, because Payment Hub reads open transactions across entities.
CANDMulti-EntityCADSkid ships, final invoice posted
Fourteen weeks later the skid ships. F&O posts sales invoice CINV-041905 in USMF for $212,000 with the $53,000 prepayment applied, leaving $159,000 open. The invoice format carries the payment link again.
Sales InvoicePrepayment AppliedCustomer settles both entities from the portal
Meridian's treasury analyst logs into the portal, sees the USMF balance and the CAND parts invoice, and pays both: $159,000 by ACH on the saved US bank account and CAD 8,400 on a purchasing card. Level III detail from the parts order lines is attached to the card payment.
Customer PortalPay-ManyLevel IIITwo journals, two entities, both settled
Payment Hub creates and posts a customer payment journal in USMF settled against CINV-041905, and another in CAND settled against CINV-102233, each with the right bank account, currency and offset. The customer's balance is zero in both entities.
USMF + CANDAuto-SettledShared service center closes without a reconciliation pass
Every payment exists as a posted, settled customer payment journal in the entity that issued the invoice. Bank reconciliation in both entities matches the gateway settlements. Collections worklists and aging are accurate because settlement happened at payment time, not at month-end.
Shared ServicesReconciledThe detail worth noticing is settlement. In most F&O shops a card payment gets posted and settled the next day by hand, and any mistake in that step ripples into aging, collections and the customer statement. Here settlement happened at the moment of payment, in the right entity, which is the whole point of doing it through the data entities.
Payment Hub use cases on Finance & Operations
All 11 Payment Hub use cases run on F&O. The ones enterprise AR teams deploy first are highlighted here, and each links to the full use-case page.
A payment link on the invoice format, with the payment journal posted and settled on payment.
Prepayment-awareOrder-to-CashPrepayment invoices, milestone invoices and final sales invoices, each settled correctly.
Customer-facingSelf-Service Payment PortalA branded portal reading open transactions across every legal entity the customer buys from.
Shared servicesERP Payment ReconciliationEvery payment is a posted, settled journal, so bank reconciliation matches gateway settlement.
Multi-entityMulti-Location PaymentsRouting by legal entity, merchant account, bank and offset account from one configuration.
Enterprise volumeLevel III Interchange OptimizationSales order line detail on commercial and purchasing cards, so enterprise card volume settles at Level III rates.
Technical details, for F&O administrators and Microsoft partners
The engineering reality of the integration, for IT teams, F&O system administrators, the people who manage your Entra ID tenant and LCS environments, and Microsoft partners evaluating Payment Hub for a Finance & Operations customer.
- API layer. OData data entities on Finance & Operations, using the standard entities Microsoft ships: CustomersV3, SalesOrderHeadersV2 and SalesOrderLinesV2, CustomerInvoiceJournalHeaders, open customer transactions, and CustomerPaymentJournalHeaders / CustomerPaymentJournalLines with posting through the standard journal workflow. Business events can notify Payment Hub of invoice posting so links go out the moment an invoice exists.
- Authentication. An Entra ID app registration with a client secret or certificate, registered in F&O under Microsoft Entra ID applications and associated with a service user whose security roles are limited to the entities above. Secrets are stored encrypted on Payment Hub's side and rotated on your schedule.
- Data direction. Reads: customers, customer groups, open sales orders, posted invoices and prepayment invoices, open customer transactions, legal entity and bank configuration. Writes: customer payment journals (create, post, settle) and payment-method tokens stored as customer attributes. Payment Hub never writes items, prices, sales order lines, ledger journals or settlements outside the payment it created.
- Card data. No cardholder data reaches F&O, Dataverse, your Azure tenant or Payment Hub's application tier. Entry happens on a PCI DSS Level 1 hosted surface at the gateway, and F&O receives a token and a reference. Your PCI scope shrinks.
- Legal entity routing. A configuration map from legal entity to merchant account, bank account, method of payment and offset account. Adding an entity is a configuration change, and settlement currency follows the invoice currency.
- Customizations. No X++ extensions, custom models, custom entities or dual-write maps are deployed in your environment. Existing ISV solutions, dual-write, Power Automate flows and Electronic reporting formats continue unchanged, and One Version updates do not require regression testing of the integration.
- Deployment. Works with Finance & Operations in the Microsoft cloud, including LCS-managed production, sandbox and tier-2 environments. The Payment Hub service reaches the OData endpoint over TLS using the environment URL and the app registration.
- Timeline. Standard go-live is 48 hours from app registration: connect, map legal entities, add the payment link to your invoice format, test in a sandbox environment, cut over to production. Portal branding, gateway migration and shared-service enrollment are added when you want them.
- Support. Clarity supports the integration and the payment side end to end. Your Microsoft partner keeps supporting Finance & Operations exactly as they do today.
Dynamics 365 Finance & Operations + Payment Hub FAQ
The questions F&O administrators, AR and shared-service leaders, IT teams and Microsoft partners ask before adding Payment Hub to a Finance & Operations tenant.
Does Clarity Payment Hub integrate with Dynamics 365 Finance & Operations?
Yes. Payment Hub integrates with Finance & Operations through the standard OData data entities, authenticated with an Entra ID app registration. Invoice payments, prepayments, portal payments and refunds are created as customer payment journals in the right legal entity, posted, and settled against the transaction they pay.
Customers, sales orders, invoices, journals and the general ledger stay in F&O as the single source of truth.
How is this different from the Dynamics 365 Payment Connector for Adyen?
Microsoft's connector, and partner-built connectors like it, serve Dynamics 365 Commerce: point of sale and the Commerce storefront. They do not take payment on an AR invoice or post a customer payment journal. Payment Hub is built for the AR side, and most enterprises that run Commerce keep the connector for that traffic and add Payment Hub for invoices, prepayments and the portal.
Does the integration require X++ or a custom model?
No. It uses only the standard data entities Microsoft ships and maintains. Nothing is deployed to your environment, so One Version updates do not require the integration to be regression-tested, and your ISV solutions and dual-write maps are not affected.
How does Payment Hub settle payments in F&O?
Each payment becomes a customer payment journal line in the legal entity that issued the invoice, with the method of payment, bank account and offset your AR team configures. Payment Hub posts the journal and settles it against the invoice or prepayment invoice it pays. Unapplied payments post with the customer set so they can be settled from the open transactions form.
We run four legal entities with a shared service center. Does that work?
Yes, and it is the setup Payment Hub is most often deployed into on F&O. Each entity is mapped once to its merchant account, bank and offset. A customer who buys from more than one entity sees all their open transactions in one portal login, and each payment routes to the right entity. The shared service center gets one reconciliation view across entities.
How are prepayment invoices handled?
A prepayment paid through Payment Hub is posted and settled against the prepayment invoice. When the final sales invoice posts with the prepayment applied, the customer sees the net balance on the invoice link and in the portal, and that payment settles against the final invoice. Milestone invoices on projects work the same way.
Can we keep our current acquirer and merchant accounts?
Almost always. Payment Hub connects to 19+ gateways including Worldpay, Adyen, Cybersource, Fortis, PayTrace, Stripe, Braintree and Authorize.Net. If your acquirer is on the list you keep your rates and your relationships, per entity if that is how they are set up.
Does Level III interchange optimization apply at our volume?
It applies to the share of your card volume that comes from commercial and purchasing cards, which is typically most of it for an enterprise selling to other businesses. Payment Hub attaches sales order line detail to each eligible transaction so it qualifies for Level III rates. At enterprise volume the saving, generally 0.5 to 1.0 percent, is usually the largest single line in the business case.
Does it work with dual-write and Power Platform?
Yes. The integration sits beside dual-write to Dataverse and any Power Automate flows you run, and does not conflict with them. Business events can be used so Payment Hub learns of a posted invoice immediately and sends the payment link without a scheduled poll.
What environments are supported?
Finance & Operations in the Microsoft cloud, including LCS-managed production and sandbox environments. Testing happens in a sandbox with its own app registration before production is connected.
What is the implementation timeline for F&O?
Forty-eight hours from app registration is the standard go-live for the core integration: connection, legal entity mapping, payment link on your invoice format, testing in a sandbox and production cutover. Portal branding, gateway migration and shared-service enrollment are added on top without delaying the core.
Who supports the integration, Clarity or our Microsoft partner?
Clarity supports the integration and the payment side. Your Microsoft partner keeps supporting Finance & Operations exactly as they do today. We work directly with partners during rollout so nobody is guessing about where a question belongs.