Dynamics NAV payment processing

Where Payment Hub fits

Is there any good news? Yes. While 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. A NAV-to-Business Central migration is a project in its own right, usually measured in months.

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 (includes the customers, accounts, invoices, card tokens, etc.) follows forward. 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.

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.

For the years before Business Central

Dynamics NAV, still called Navision by many long-time users, is in its last extended-support years: NAV 2017 runs to January 2027 and NAV 2018 to January 2028. Its natural next step is Business Central. Integrating Payment Hub with NAV adds the receivables side now, through NAV's SOAP and OData web services, and keeps it when you move: