How an enablement layer sits on top of your existing rails
A technical overview of where an infrastructure layer fits between merchants and a provider's core processing, and why that separation matters.
Payment providers already operate the parts of the stack that are hardest to replace: acquiring relationships, processing, settlement and compliance. Adding merchant enablement should not require touching any of them. This overview describes how an enablement layer is positioned so it extends those rails without disrupting them.
The three layers
It helps to think in three layers. At the top are merchants and billers. At the bottom are the provider's core rails. In between sits the enablement and infrastructure layer — onboarding, acceptance, routing, tokenization, collections and workflow.
- Merchants and billers connect through documented APIs, SDKs and hosted experiences.
- The enablement layer handles acceptance, routing, tokenization and lifecycle.
- The provider's rails continue to own processing, settlement and compliance.
Why the separation matters
Keeping these layers distinct is a deliberate architectural choice. It lets an institution adopt capability incrementally, change one layer without rewriting the others, and avoid the risk of re-platforming a system that already works.
What this enables
With the layer in place, changes that used to require merchant-by-merchant work — adding a payment method, adjusting routing, enabling a new segment — become central configuration. That is the difference between a project and a capability.
For the developer-facing detail of how this is exposed, see the developer platform documentation.