Supported
Extended Support Ends
Users Worldwide
Migration Path
Timeline
Dynamics NAV + Payment Hub, payment infrastructure for Navision's final chapter
Dynamics NAV, most long-time users still call it Navision, was originally created in Denmark in 1984 by PC&C A/S as a single-user accounting package called PCPlus. It became Navision, grew through the 1990s, was acquired by Microsoft on July 11, 2002, and became the foundation of what Microsoft now calls Dynamics 365 Business Central. Over its 40+ year arc, NAV accumulated more than 1 million registered users worldwide, one of the largest ERP installed bases in history. NAV 2018 was the last version Microsoft released before converting the product line to BC.
NAV customers are now in their final extended-support window. NAV 2015's security updates ended January 2025. NAV 2016 ends April 2026 (which is right now, as we write this). NAV 2017 ends January 11, 2027. NAV 2018, the last version Microsoft released, ends January 11, 2028. After those dates, NAV receives no Microsoft support of any kind: no security patches, no tax updates, no technical support. The migration clock is running.
That timeline puts NAV customers in a similar position to GP customers, but with one important difference: the migration destination is cleaner. Dynamics 365 Business Central isn't a completely different ERP the way BC-vs-GP is, BC is literally the cloud continuation of NAV, inheriting NAV's data model, page structure, and business logic. Microsoft provides a specific Cloud Migration Tool for NAV→BC. Customizations convert from NAV's C/AL language to BC's AL language through documented tooling. The typical NAV→BC migration takes about 6 months with 87% of customers reporting improved cash flow and 86% reporting IT cost reduction afterward.
Payment Hub fits this context: integrate with NAV today through SOAP and OData web services (the NAV-era standard), benefit from customer portal, real-time cash application, 19+ gateway choices, and Level III interchange optimization during the remaining NAV runtime. When you migrate to BC, the Payment Hub layer follows, Clarity Connect swaps its NAV connector for BC's REST API v2.0 connector, and the customer-facing portal, saved tokenized methods, and subscription enrollments all stay in place.
NAV version support dates, where your version stands
Microsoft ended mainstream support for NAV 2018 (the last version released) in January 2023. Extended support, security updates only, is ending on a per-version schedule. Here's what's still supported and for how long.
The practical implication: if you're running NAV 2015 or 2016, you're either out of support or about to be, and Microsoft's recommended path is Business Central (the direct successor). NAV 2017 customers have until January 2027, about 9 months as of this writing. NAV 2018 customers have until January 2028, about 21 months. After those dates, NAV receives no support of any kind. Migration planning that previously seemed "eventually" is now genuinely time-bound.
For customers running older NAV versions (NAV 2013 or 2013 R2), Microsoft's migration tool requires an upgrade to NAV 2018 first before migrating to Business Central. That adds an intermediate step but doesn't prevent the eventual migration, it just means more runway required. Payment Hub works across all these versions and through the migration path.
The NAV → Business Central bridge, Payment Hub on both sides
Unlike GP→BC (where the data model changes substantially), NAV→BC is a more natural upgrade. BC inherits NAV's core entities, Customer, Sales Invoice, Payment Journal, General Ledger, which means Payment Hub's hand-off is the cleanest migration scenario we support.
Payment Hub running on Dynamics NAV
- Integrates via SOAP + OData web services
- Reads Customer, Sales Invoice, Sales Line entities
- Posts Cash Receipt Journal via codeunit web service
- Customer portal reads live NAV data
- L3 enrichment from Sales Invoice Line details
- 19+ gateways, ACH, wallets, all available
- Subscription billing runs against NAV customers
- Multi-company NAV databases supported
Tool · natural
data-model upgrade
Payment Hub running on Business Central
- Clarity Connect swaps NAV web services → BC REST API v2.0
- Customer portal URL unchanged · users unchanged
- Saved tokenized payment methods carry forward
- Subscription enrollments continue uninterrupted
- Same gateway relationships &, merchant accounts
- L3 logic applies to BC's Sales Invoice Line data
- Same team-facing views &, audit trail
- Migration focuses on ERP, payment layer just works
Because NAV and BC share the same underlying entity model (Customer, Sales Invoice, Payment Journal all exist in both systems with compatible structures), Payment Hub's connector swap is nearly transparent. The portal URL, customer accounts, saved methods, subscription enrollments, and transaction history all carry forward. Your customer's AP team logs in the week before migration and the week after migration and sees the same portal with the same data, the only difference is that the back-end is now writing to BC instead of NAV.
This matters strategically because it removes one of the common migration risks: the "will our customers still be able to pay us during cutover?" question. For NAV→BC migrations running Payment Hub, the answer is yes, the payment layer is stable throughout because it's not actually being migrated. Only the ERP beneath it is changing.
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 Dynamics NAV
The integration uses NAV's documented web-services stack, SOAP web services (available since NAV 2009) and OData web services (added in later versions). Microsoft has continuously supported this integration pattern through the end-of-life timeline, so your Payment Hub integration remains stable on the NAV platform through each version's support window.
SOAP web services for real-time posting
Payment Hub uses NAV's SOAP web services, exposed via the Web Services page, to call codeunits and pages for cash receipt posting, payment application, customer lookup, and invoice state queries. Full WSDL-defined contract. Available on every supported NAV version since 2009.
OData for fast tabular reads
For high-volume data reads (customer lists, open invoice queries, line-item fetches for L3 enrichment), Payment Hub uses NAV's OData web services. OData is substantially faster than SOAP for tabular queries. Supports both XML and JSON. Default port 7048.
Level III from Sales Invoice Line
Payment Hub pulls line-item data from NAV's Sales Invoice Line and Sales Line entities through OData, item description, quantity, unit of measure, unit price, line amount, VAT/tax breakdown, customer code, destination location, and packages the Level III envelope for the gateway. 0.3–1.0% savings on qualifying commercial cards.
Tokenized method vault
Customer card and ACH credentials tokenize at the gateway vault, never stored in NAV, on Payment Hub servers, or in NAV's SQL database. Tokens link to NAV Customer records via standard web-services fields. Raw PAN stays out of your environment.
Multi-company NAV databases
NAV's multi-company pattern (multiple companies within one NAV database) maps into Payment Hub's routing table. Each NAV company can have its own merchant ID, Cash GL, VAT / tax setup, and gateway. Per-company routing is automatic based on the originating transaction.
European VAT &, multi-currency
NAV's European heritage means strong multi-currency and VAT handling. Payment Hub respects NAV's VAT posting setup, EU-specific rules (PSD2 SCA for European card acceptance where applicable), and multi-currency captures with proper NAV exchange-rate handling.
Works with NAV ISV products
NAV's extensive ISV community, Continia (document capture, payment management), eOne (SmartConnect), Insight Works (warehouse, manufacturing), Lanham, Jet Reports / Jet Analytics, LS Retail (retail POS), Sana Commerce (B2B eCommerce), Tasklet Factory, and others, coexists with Payment Hub through the same web-services layer. No conflicts with existing C/AL extensions.
Migration-ready data layer
All Payment Hub-side data (portal accounts, saved tokens, subscription enrollments, transaction history, L3 metadata) lives on Payment Hub infrastructure, not in NAV's SQL database. When you migrate from NAV to BC, this data carries forward automatically as Clarity Connect swaps ERP connectors. No payment-history loss during the ERP cutover.
The integration workflow, from NAV Sales Invoice to posted Cash Receipt
A concrete walk-through: a Dynamics NAV 2018 customer (mid-market European distribution company running a multi-company NAV database) receives a €6,240 Sales Invoice, pays it through the Payment Hub customer portal using a saved Visa Corporate card, and watches the Cash Receipt Journal line post to the correct NAV company in real time.
NAV generates the Sales Invoice
Your AR team posts Sales Invoice S-INV103245 in NAV (company DE-01), €6,240 covering 7 line items (Dutch auxiliary goods distributor), 21% Dutch BTW VAT, shipping from the Rotterdam warehouse, Net 30 terms. The invoice becomes available through NAV's OData Sales Invoice endpoint. Customer balance for Acme BV updates by €6,240.
NAV Sales &, Receivables OData endpointCustomer sees it in the Payment Hub portal
Acme BV's AP manager logs into your branded Payment Hub portal. Clarity Connect queries NAV's Customer and Sales Invoice entities via OData, €6,240 new invoice visible, total outstanding €18,520 across 4 open invoices, saved Visa on file, available credit €140 from a prior credit memo. Live data from NAV company DE-01.
Live NAV data Multi-companyCustomer selects the invoice and applies credit
AP manager selects S-INV103245 to pay and applies the €140 credit. Net pay: €6,100 against the saved Visa Corporate card. Payment Hub recognizes the commercial BIN and flags for L3 enrichment. European transaction, PSD2 SCA (Strong Customer Authentication) triggers for the Visa. Customer approves via 3-D Secure 2 on their banking app.
Credit applied PSD2 SCAClarity Connect pulls L3 data via OData
Payment Hub queries NAV's Sales Invoice Line entity for the 7 line items, unit of measure, unit price, VAT amounts, customer code, destination location. All 20+ L3 fields packaged into the gateway envelope in under 500ms. VAT breakdown replaces US sales-tax in the L3 envelope for European card brands.
Line-item fetch EU L3 envelopeGateway authorizes at L3 interchange
Whichever gateway you've configured, Adyen (European-friendly choice for NAV customers), Worldpay, Cybersource, or any of the 19+, receives the full L3 envelope. Visa qualifies the transaction at the Level III interchange category. Savings vs. L1 baseline: approximately €70 on this €6,100 transaction.
Adyen · Worldpay · etc. ~€70 savedClarity Connect posts Cash Receipt Journal via SOAP
Payment Hub calls the Cash Receipt Journal codeunit web service, €6,240 payment (€6,100 card + €140 credit memo application), applied to S-INV103245 via NAV's standard Apply Entries process. Rotterdam-branch bank account selected, VAT posting honored. Sales Invoice closes. Total elapsed time: under 3 seconds from customer click to NAV update.
Cash Receipt Journal SOAP codeunitCustomer sees success, NAV sees activity
Portal confirms "Payment successful, €6,240 applied to S-INV103245." Receipt emails automatically. Your AR team running NAV's Role Center sees the Cash Receipt Journal line in the day's transaction list. Acme BV's balance drops to €12,420. Sales Invoice shows paid. L3 savings of ~€70 logged in Payment Hub's reporting.
Portal confirm NAV updatedFast-forward: BC migration arrives
When you migrate from NAV to Business Central using Microsoft's Cloud Migration Tool, Clarity swaps the ERP connector in Clarity Connect, from NAV's SOAP/OData web services to BC's REST API v2.0 with OAuth 2.0 via Microsoft Entra ID. Acme BV's AP manager logs into the same portal URL, sees the same saved Visa, sees the same payment history. The data-model overlap between NAV and BC means fewer translation edge cases than other migrations. Zero customer disruption during cutover.
NAV → BC swap Zero disruptionPayment Hub use cases on Dynamics NAV
All 11 Payment Hub use cases work on NAV. Patterns most common on NAV, given its distribution / manufacturing / European-enterprise focus, are highlighted, but all are available.
Pay-link emails, portal, L3-enriched commercial-card acceptance for every NAV-generated Sales Invoice. The core workflow.
Fills biggest NAV gap Self-Service Payment PortalNAV doesn't ship a modern customer portal. Payment Hub adds the branded portal your customers expect in 2026.
High ROI on NAV Level III InterchangeNAV's distribution / manufacturing focus lines up with L3's highest-impact verticals. $15K–$50K/year typical savings.
Cash app ERP Payment ReconciliationReal-time Cash Receipt Journal posting via SOAP codeunit. End the manual cash-application bottleneck on NAV.
Recurring Subscription BillingNative recurring, scheduled, and automated billing. Pairs with NAV's Recurring Sales Invoice patterns where used.
Multi-invoice Consolidated Invoice PaymentCustomers pay multiple NAV Sales Invoices in one transaction. Payment Hub splits clean per-invoice.
Aging reduction AR Collections AutomationDunning cadences with direct pay-links. NAV's native Reminder functionality gets much more effective. DSO reduction 5–12 days typical.
Multi-company NAV Multi-Location PaymentsPer-company NAV database routing. Multi-country NAV deployments across EU / US entities fully supported.
Sales order flow Order-to-CashPayment embedded in NAV's Sales Order workflow. Deposits, authorization-capture, partial-shipment captures on production orders.
Card-present Counter Sales &, RetailFor NAV customers running LS Retail or counter operations, certified terminals + NAV Customer lookup at counter.
Sana / web orders eCommerce CheckoutClarity eCommerce architecture pairs with NAV (optionally via Sana Commerce) for B2B storefront checkout with real-time inventory.
Technical details, for NAV admins &, Partners
The engineering reality of how Clarity Connect integrates Payment Hub with Dynamics NAV, for NAV administrators, IT teams, and Microsoft Partners managing NAV customers through the sunset window.
- Primary integration layer, SOAP web services. NAV has supported SOAP web services since NAV 2009. Payment Hub publishes and consumes codeunit and page web services through NAV's Web Services table. Full WSDL-defined contracts, XML message format, over HTTP/HTTPS.
- Secondary integration layer, OData web services. OData added in later NAV versions (NAV 2013+ for basic OData, enhanced in 2015 and 2016). Used for high-volume tabular reads (customer list, open invoices, line-item L3 enrichment fetches). Supports XML and JSON. Faster than SOAP for query-style operations. Default port 7048.
- Authentication. Windows integrated authentication for on-prem NAV in domain-joined environments. Basic auth over HTTPS for partner-hosted scenarios. NavUserPassword (username/password auth) where configured in NAV's Service Tier settings.
- No C/AL customizations installed. The integration runs from Clarity's infrastructure. No custom C/AL code installed in your NAV dictionary, no modifications to standard posting routines, no NAV Development Environment changes. Your NAV code base stays vanilla, which matters for migration because your existing C/AL modifications will already have enough conversion work to do as they move to AL in BC.
- Deployment model. Works with NAV on-premises (the dominant pattern), NAV on Azure VMs, and NAV hosted by partner MSPs. Payment Hub reaches your NAV environment through the SOAP / OData web-services endpoints via outbound-only firewall rules (inbound firewall ports are not required for most patterns).
- Version compatibility. Supports NAV 2015, NAV 2016, NAV 2017, and NAV 2018 (the last version Microsoft released). For older NAV versions still in the field (NAV 2013, 2013 R2, 2009 R2), basic integration via SOAP is available but functionality may be limited, Clarity recommends the NAV 2018 upgrade-then-migrate path in those cases.
- Multi-company NAV databases. Native support for NAV's multi-company pattern (multiple companies within one NAV database). Each company is configured in Payment Hub's routing table with its own merchant ID, Cash GL, VAT / tax posting setup, and gateway. Per-company routing is automatic.
- ISV compatibility. Works alongside common NAV ISV products, Continia (document capture, collection management, payment management), eOne SmartConnect, Insight Works (WMS, shop floor), Lanham, Jet Reports / Jet Analytics, LS Retail, Sana Commerce, Tasklet Factory, through the same web-services layer these products use.
- European &, multi-currency compliance. NAV's European heritage brings strong multi-currency, multi-VAT, and EU regulatory capabilities. Payment Hub respects NAV's VAT posting setup, honors PSD2 SCA (Strong Customer Authentication) for European card acceptance where required, and handles multi-currency captures with proper NAV exchange-rate conversion.
- PCI scope. Raw PAN never touches Payment Hub or NAV servers, card data tokenizes at the gateway vault via hosted iframe / JS-tokenization. Typical deployment stays in SAQ A / SAQ A-EP scope even on on-prem NAV.
- SOC 2 Type II. Clarity Ventures operates to SOC 2 Type II standards with annual independent audits.
- Migration-ready state. All Payment Hub state (portal accounts, saved tokens, subscription enrollments, transaction history, L3 metadata, reports) lives on Payment Hub infrastructure, not in NAV's SQL database. When you migrate to BC, this state transfers automatically. No payment-history loss in the ERP swap.
Dynamics NAV + Payment Hub FAQ
The questions NAV admins, IT teams, Microsoft Partners, and finance leaders ask before adding Payment Hub to their Dynamics NAV deployment.
Does Clarity Payment Hub integrate with Dynamics NAV (Navision)?
Yes. Clarity Payment Hub integrates with Microsoft Dynamics NAV through NAV's documented web services stack, SOAP web services (available since NAV 2009) for real-time transactional integration, and OData web services for faster query-style data access. Authentication uses NAV's standard Windows integrated auth or Basic auth over HTTPS.
The integration works with NAV 2015, 2016, 2017, and 2018, and when you migrate to Business Central (NAV's direct successor), the Payment Hub layer carries forward intact with a simple connector swap from NAV's web services to BC's REST API v2.0.
What's the NAV end-of-life timeline?
NAV 2018 was the last version Microsoft released. Mainstream support for NAV 2018 ended January 2023. Extended support (security updates only) ends on a per-version basis: NAV 2015 ended January 2025, NAV 2016 ends April 2026, NAV 2017 ends January 11, 2027, and NAV 2018 ends January 11, 2028.
After those dates, NAV receives no Microsoft support of any kind, no security patches, no tax updates, no technical support. Microsoft's recommended migration path is Dynamics 365 Business Central, which is literally the cloud-era continuation of NAV and inherits NAV's data model, making NAV→BC more of a natural upgrade than a full ERP transition.
Will Payment Hub continue to support us once we migrate to Business Central?
Yes. Payment Hub is ERP-agnostic, it runs against 25+ ERPs including Dynamics 365 Business Central (NAV's direct successor), Dynamics 365 Finance &. Operations, NetSuite, Acumatica, Sage, SAP, and more. When you migrate from NAV to BC, the Payment Hub side changes minimally: Clarity Connect swaps its NAV web-services connector for BC's REST API v2.0 connector with OAuth 2.0 authentication through Microsoft Entra ID.
Your customer portal, saved tokenized payment methods, subscription enrollments, gateway relationships, L3 enrichment logic, and AR automation all carry forward. The NAV→BC migration is often the smoothest migration scenario Payment Hub handles because the data model convergence is so tight, Customer, Sales Invoice, Payment Journal entities share the same structural bones.
How does Payment Hub integrate with NAV technically?
Through NAV's documented web services, both SOAP (for codeunits and pages, available since NAV 2009) and OData (for tabular data and queries, faster for high-volume reads). Payment Hub publishes and consumes the standard NAV web services exposed through the Web Services page.
No C/AL customizations are installed in your NAV environment. No modifications to NAV posting routines, no dictionary changes. Authentication uses NAV's standard options, Windows integrated auth for on-prem domain deployments, Basic auth over HTTPS for partner-hosted scenarios, or NavUserPassword where configured. Your NAV code base stays vanilla.
Which NAV modules does Payment Hub touch?
Primarily Financial Management (GL, AR, cash management, bank reconciliation) and Sales modules (Sales &. Receivables, Sales Orders, Invoicing). Customer master data is read through the standard Customer page web service. Cash receipts post as Cash Receipt Journal lines via the Cash Receipt Journal codeunit. Invoice applications work through NAV's native Apply Entries process.
For manufacturing / project / warehouse shops, Payment Hub integrates with the transactional touchpoints that matter for payment acceptance (production order invoicing, job invoicing, warehouse sales). Payment Hub uses the web-services API layer rather than direct SQL access.
Does Level III interchange optimization work on NAV?
Yes. Payment Hub's L3 enrichment pulls line-item data from NAV's Sales Line, Sales Invoice Line, or Service Invoice Line entities through SOAP / OData web services, item description, quantity, unit of measure, unit price, line amount, tax breakdown, customer code, destination ZIP, and the other 20+ Level III fields, and packages them into the gateway envelope.
Commercial-card transactions qualify for 0.3–1.0% interchange savings per qualifying transaction. A typical NAV-running distributor or manufacturer with $5M in annual B2B card volume recovers $15K–$50K in L3 savings annually. That saving continues after you migrate to Business Central, the enrichment logic is Payment Hub's, not NAV-specific.
Does it work with our NAV customizations and ISV products?
Yes. The NAV ISV community is extensive, Continia, eOne, Insight Works, Lanham, Jet Reports / Jet Analytics, LS Retail, Sana Commerce, Tasklet Factory, and many others. Payment Hub reads and writes through the same standard NAV web services these products use alongside their own C/AL extensions. No conflicts, no overwriting of records, no broken integrations.
Your custom C/AL modifications stay untouched because Payment Hub doesn't install code in your NAV environment. When you migrate to BC, your C/AL customizations convert to AL extensions as part of the migration process (Microsoft provides tooling for this). The Payment Hub integration itself doesn't need conversion because it was never NAV-specific code in the first place.
How does the NAV → BC migration work from a Payment Hub standpoint?
From Payment Hub's perspective, the migration is a Clarity Connect connector swap, we replace the NAV web-services connector with the BC REST API v2.0 connector, configure OAuth 2.0 auth through Microsoft Entra ID, and remap any per-company / per-entity routing from NAV's company structure to BC's. Because BC inherits NAV's entity model (Customer, Sales Invoice, Payment Journal, etc.), the mapping is largely 1:1 rather than translation-heavy.
For your customers: the portal URL stays the same, saved methods stay accessible, subscription enrollments continue, and transaction history is preserved. For your AR team: the team-facing views are unchanged, only the underlying ERP data source is different. Most NAV→BC migrations go live with Payment Hub intact over a planned weekend cutover window.
Can we accept European-specific payment methods like SEPA Direct Debit and iDEAL?
Yes. For European NAV customers, Payment Hub's gateway library includes Adyen, Worldpay, and other European-friendly gateways with native support for SEPA Direct Debit (single and recurring), iDEAL (Netherlands), Bancontact (Belgium), Giropay (Germany), SOFORT, and the broader set of EU alternative payment methods. PSD2 Strong Customer Authentication (SCA) is honored automatically through 3-D Secure 2 where required. Multi-currency captures handle EUR, GBP, and other European currencies cleanly.
For mixed US / European NAV customers, Payment Hub routes per-company: your US companies use US-appropriate gateways and methods. Your European companies use European-appropriate gateways and methods. The customer-facing experience in each region is localized.
What's the implementation timeline for NAV?
A typical Payment Hub + NAV integration goes live in 48 hours once Clarity receives NAV test-company credentials (web services URL + appropriate NAV user permissions), gateway credentials, and your baseline routing configuration (which NAV company databases map to which merchant accounts and cash GL accounts).
For multi-company NAV deployments, pilot with 1–2 companies in the first 48 hours and add additional companies in subsequent 24–48 hour batches. Your existing NAV license, modules, customizations, and ISV products stay intact. Implementation is a flat subscription.
What if we're on NAV 2016 and extended support is ending this month?
NAV 2016 extended support ends April 2026, which is effectively now. After that, NAV 2016 receives no Microsoft support of any kind. Your practical options: (1) upgrade NAV 2016 to NAV 2018 first (buying ~21 more months of support through January 2028), then migrate to BC. (2) Migrate NAV 2016 directly to BC using Microsoft's migration tooling, or (3) continue running NAV 2016 without support (accepting the operational and compliance risk).
Payment Hub works on all three paths, on NAV 2016 today, through the NAV 2018 intermediate upgrade if you take that route, and on BC whenever you arrive. Given the urgency, many NAV 2016 customers are deploying Payment Hub now to start capturing L3 savings and portal value while they plan the ERP migration separately, rather than bundling both into one project.
Who supports the integration, Clarity or our NAV Partner?
Clarity supports the integration directly. Your Microsoft NAV Partner / VAR continues to support the NAV platform itself (upgrades, service packs, tax updates, C/AL customizations, year-end procedures, training, eventual BC migration planning). Payment Hub's support covers the integration layer, payment acceptance, gateway issues, Clarity Connect, L3 enrichment, customer portal, and anything that touches Payment Hub infrastructure.
Most NAV Partners are familiar with Clarity Ventures and work collaboratively on deployments. The integration is designed to be partner-friendly, standard web services (SOAP/OData), no C/AL customizations installed, nothing that disrupts your partner's normal NAV delivery model or complicates your eventual BC migration project.