What is CPA?
CPA isn’t a product or service, it’s a way of thinking about payment systems. The idea is simple: build systems from independent pieces that work together, rather than one big monolithic thing. You compose services together instead of bundling everything into a single component. Each piece does one thing well, and you can swap them out or rearrange them as your needs change.How CPA Differs from Walled Gardens
Most payment platforms are walled gardens. You get their way of doing things, bundled services you might not need, and switching costs that keep you locked in. CPA flips this around. You pick the services you actually need. You can mix services from different providers. You control your payment flows instead of adapting to someone else’s constraints. When you need to change something, you swap out a component instead of rebuilding everything.Why CPA Matters
Payment systems are messy. Everyone builds their own orchestration layers, optimized for their specific needs. Integration is painful. Scaling is hard. Changing anything requires rebuilding large parts of the system. Walled garden platforms make this worse. They lock you into their way of doing things. You adapt to them, not the other way around. CPA fixes this by letting you build from independent pieces. Change one component without touching the rest. Swap providers when you need to. Keep control of your architecture instead of being forced into someone else’s mold.Core Principles
CPA follows five simple principles:Separation of Concerns
Keep different domains separate. Risk, settlement, data—each has its own boundaries. Change one without breaking the others.Composability
Everything is replaceable. Swap components, rearrange them, extend them. No need to rebuild the whole system.Openness
Use open APIs and contracts, not proprietary formats. Mix services from different providers.Programmability
Everything is API-driven. Automate what you can. Extend what you need.Evolvability
Change is constant. CPA lets you evolve incrementally—add a new PSP, update compliance rules, adopt new tech—without big rewrites.Composition Over Aggregation
CPA prefers composition over aggregation. Composition means combining independent services. Each service stays separate—you can swap them out or rearrange them. Aggregation bundles multiple functions into one component. It seems easier at first, but you end up with tight coupling, less flexibility, and harder changes.Example: Fraud Checks in Authorization Flows
Say you have a payment gateway that bundles fraud checks into authorization. Every authorization triggers a fraud check. To change this, you need to add flags and modify the authorization logic. Now authorization and fraud are tightly coupled—hard to test, hard to change, hard to swap providers. With CPA, authorization and fraud are separate services. You compose them however you need:fraud >=> auth→ check fraud first, then authorizeauth >=> fraud→ authorize first, then check fraud
How We Build Hellgate with CPA
CPA isn’t just theory—it’s how we build the Hellgate Cloud Platform. Every service follows CPA principles. They work together, but you can use them independently. We learned this from building payment systems and consulting in the payments world. We saw the problems: walled gardens, legacy systems, fragile protocols, systems that don’t connect well. CPA is our answer.Our Platform Journey
We’re building Hellgate Cloud Platform as a collection of composable services. Commerce V2 is our CPA-based implementation—it’s built entirely using CPA principles, composing independent services together to create flexible payment orchestration. One of those composable services is Guardian—our PCI-compliant tokenization service. Guardian is used within Commerce V2, but it’s also available as a standalone service you can use independently or compose with your own services. More services are rolling out soon for general access: Hub, Specter, Link, and Pulse. Together with Guardian and Commerce V2, these make up our complete product stack. Each one is:- Standalone — Works on its own
- Composable — Works with other services, ours or third-party
- CPA-aligned — Built with composable architecture from the start
Building with CPA
When building payment software with CPA:- Think in flows — Break processes into steps you can rearrange
- Design for swapping — Make components replaceable
- Focus on interfaces — Define how components talk to each other, not how they work inside
- Plan for change — Structure things so you can evolve incrementally
- Compose, don’t bundle — Keep services independent
Learn More
See CPA in action:- Commerce V2 — A CPA-based implementation that orchestrates payment flows by composing services
- Guardian — One of the composable services used in Commerce V2, also available standalone