The Composable Payment Architecture (CPA) is Hellgate's approach to building payment systems from independent, interoperable components rather than one monolithic platform. Instead of adopting a single vendor's bundled stack, you compose only the services you need – a vault, an orchestration layer, a fraud engine, a PSP abstraction – and snap them into your existing infrastructure.

CPA is not a product; it's an architectural model. Each Hellgate service (Guardian, Hub, Specter, Link, Commerce, Pulse) is built to CPA principles: standalone, composable, and API-driven. Enterprises and platforms use it to own and control their payment flows without vendor lock-in.

→ Explore the Composable Payment Architecture

Traditional orchestration platforms are walled gardens: you adopt their way of working, take bundled services you may not need, and accept switching costs that keep you locked in. CPA inverts this. You pick only the components you need, mix in services from other providers, and keep control of your own payment flows.

The practical difference is portability and control. With a walled garden you adapt to the platform; with CPA the platform adapts to you. When something changes, you swap a single component instead of re-building the whole system – which is why complex, high-volume merchants and platforms favour the model.

→ See how CPA compares to all-in-one platforms

CPA follows five principles: Separation of concerns – risk, settlement, and data each stay in their own boundaries; Composability – every component is replaceable and rearrangeable; Openness – open APIs and contracts instead of proprietary formats; Programmability – everything is API-driven and automatable; and Evolvability – you add a PSP, update compliance rules, or adopt new technology incrementally, without large rewrites.

Together these principles let payment teams change one part of the stack without breaking the rest.

→ Read the CPA principles

No. Avoiding vendor lock-in is the entire point of CPA. Every Hellgate component is provider-agnostic and built on open APIs and contracts, so you can combine Hellgate services with third-party providers or your own systems. Because integration is defined by interfaces rather than proprietary formats, you can swap a component out or re-point it to a different provider without re-building your stack.

This is especially valuable for enterprises and platforms that need to keep negotiating leverage with PSPs and acquirers over time.

→ Learn how CPA removes vendor lock-in

The CPA is delivered as a suite of independent components on the Hellgate Cloud Platform:

• Commerce – a unified payment engine for payments, tokens, authentications, and wallets.

• Hub – the orchestration fabric that routes across acquirers and PSPs.

• Guardian – PCI-compliant vaulting and tokenization.

• Specter – the real-time fraud intelligence layer.

• Link – the PSP and provider abstraction layer.

• Pulse – observability and metrics.

Each works standalone or in composition with the others.

→ See all CPA components

Every component is standalone by design. You can deploy Guardian purely for PCI vaulting, use Specter only for fraud scoring, or adopt Link just to abstract your PSP connections – without taking the rest of the platform. There are no forced bundles.

When you do use several components together, they compose natively: Specter can read token signals from Guardian, Hub routes through Link, and so on. But the choice of how much to adopt, and when, stays with you.

→ Use what you need, build what you want

CPA turns integration into configuration. Because components talk through open, versioned contracts rather than bespoke code, adding a PSP, changing a fraud backend, or updating a compliance rule is a configuration change – not a multi-month engineering project. Link, for example, lets you re-point a stable API contract to a different provider without the caller ever changing.

For enterprises this collapses the cost of switching providers and the risk of being trapped by a single vendor, protecting both margins and negotiating power.

→ See how CPA lowers switching costs

Yes – CPA is built for exactly that profile. Payment orchestration typically becomes financially justified once a merchant processes tens of millions in annual volume, and Hellgate is the technology and strategy partner for organisations running the most complex payment ecosystems. Its clients span automotive, mobility, EV charging, airlines, retail, logistics, and insurance.

For platforms and marketplaces, CPA supports single-merchant, platform, and ecosystem operating models, so payment logic scales with your business rather than constraining it.

→ CPA for enterprises, global sellers & platforms

Aggregation bundles many functions into one component – for example, a gateway that ties fraud checks into authorization. It looks simpler at first but creates tight coupling: changing one behaviour means modifying shared logic, and swapping a provider becomes hard.

Composition keeps each capability as an independent service you arrange as needed – run fraud before auth, or auth before fraud, by configuration. CPA prefers composition because it keeps services testable, replaceable, and free of hidden dependencies.

→ Composition over aggregation, explained

Provider-agnostic means Hellgate's components are not tied to any single acquirer, PSP, or fraud vendor. You choose the providers that fit your geographies, cost targets, and risk profile, and Hellgate abstracts the differences behind consistent APIs. If you want to add a local acquirer for better authorization rates in a new market, or move volume between PSPs, you do it without re-engineering.

This keeps you in control of routing, pricing, and resilience – instead of a vendor deciding those for you.

→ Learn about provider-agnostic payments

CPA isolates sensitive data and compliance concerns into dedicated components – primarily Guardian, the PCI-compliant vault – so the rest of your stack stays out of PCI scope. Because compliance is a separated concern, you can freely re-arrange, add, or swap other services without re-opening your compliance posture each time.

In other words, flexibility and compliance stop being a trade-off: you keep the freedom to evolve your architecture while sensitive data remains in a certified environment.

→ See how Guardian keeps you compliant

Because CPA components are designed to plug into what you already run, adoption is incremental rather than a rip-and-replace. Many teams start with a single component – Guardian to cut PCI scope, or Specter for fraud – and expand from there. Hellgate provides SDKs, comprehensive documentation, and clear integration patterns, and typical component integrations are measured in days rather than months.

You keep your existing systems running and compose new capabilities alongside them.

→ Read the developer documentation

Commerce is Hellgate's unified payment engine – a programmable platform-as-a-service that handles payments, tokens, authentications, and mobile wallets through a single, consistent API. It is the CPA-based implementation of the platform, composing independent services (such as Guardian for tokenization) into a complete payment-processing product.

Commerce is designed for merchants and platforms that want one API to accept, authenticate, and manage card payments across channels and markets, without stitching together multiple point solutions.

→ Explore Commerce

Commerce is organised around four domains: Payments (one-off, recurring, and unscheduled, with capture, void, and refund), Tokens (tokenize and manage cardholder data, including network tokens), Authentications (3-D Secure for card-not-present transactions), and Mobile Wallets (including branded in-car wallets).

Both customer-initiated and merchant-initiated (off-session) flows are supported, covering subscriptions, installments, and unscheduled charges.

→ See Commerce capabilities

Yes. Commerce is fully PCI compliant, achieved through Guardian, Hellgate's PCI DSS Level 1 certified tokenization service. Card data is captured and stored inside a certified cardholder data environment operated by Hellgate, so raw PANs never need to touch your own systems.

The practical benefit is a dramatically reduced PCI scope for your business – often qualifying for a lighter self-assessment questionnaire instead of a full audit.

→ How Guardian delivers PCI compliance

Commerce supports three operating models: single merchant (one business accepting payments), platform (a business managing payments on behalf of sub-merchants), and ecosystem (complex multi-party arrangements across markets and entities).

This range makes Commerce suitable for marketplaces, platforms, and enterprises with multiple legal entities or business units that need consistent payment logic across all of them.

→ Read about operating models

Commerce is built for fast integration: SDKs for iOS, Android, and Web, a consistent REST API, webhooks, and comprehensive documentation mean most teams integrate in days rather than weeks. A test (sandbox) account can be created for free to build and validate flows before going live.

Because Commerce follows CPA principles, you can start with the flows you need and extend later without re-architecting.

→ Create a test account

No. Commerce is optional. Guardian, Hub, Specter, and Link are all standalone CPA components that you can adopt independently of Commerce and compose with your own payment engine or a third-party stack.

Commerce is the ready-made, composed option for teams that want a complete payment engine out of the box; if you already have one, you can still use the individual Hellgate services around it.

→ Compose only what you need

Yes. Commerce handles EMV 3-D Secure (3DS) authentication for card-not-present transactions, both integrated into a payment and as a standalone authentication service. It supports one-off, recurring, and installment authentication flows, and provides configuration and failure handling so you can meet Strong Customer Authentication (SCA) requirements.

Standalone 3DS lets you authenticate through Hellgate even when you authorize elsewhere – useful in composable setups.

→ Read about 3-D Secure in Commerce

Both. Commerce V2 can run on dedicated, single-tenant infrastructure – provisioned exclusively for your organisation with physical data isolation – or on a shared, multi-tenant Commerce V2 service available for both test and production tiers.

The shared service is fast to onboard and cost-effective when full isolation is not a hard requirement; dedicated is the choice when data sovereignty, regulatory compliance, or strict performance SLAs apply.

→ Compare shared vs. dedicated Commerce

Yes. Commerce supports the full range of merchant-initiated transactions: initial and subsequent recurring payments (subscriptions, installments) and unscheduled off-session charges (top-ups, usage-based billing). It stores the credentials-on-file and network-token context needed to keep these payments authorising over time.

This is critical for subscription, mobility, and usage-based businesses where declined renewals directly hit revenue.

→ See merchant-initiated payments

Commerce ships native SDKs for iOS and Android, plus a headless Web SDK for browser-based payment experiences. The SDKs handle sensitive card capture and tokenization on the client side, so raw card data is collected securely and kept out of your servers, supporting a reduced PCI scope.

The headless Web SDK gives full control over your checkout UI while Hellgate manages the secure session and card flow.

→ Browse the SDKs

Yes. Commerce includes mobile-wallet capabilities and supports branded in-car wallet implementations, letting automotive and mobility businesses embed secure payments directly into the vehicle for fuel, EV charging, parking, tolls, and connected-car services.

In-car flows combine tokenization and strong authentication (such as FIDO) so transactions initiated from the vehicle stay secure and compliant with global standards.

→ Build in-car payment experiences

Commerce supports network tokens as an add-on: scheme-issued tokens that replace the raw card PAN. Network tokens improve authorization rates, reduce fraud, and keep subscriptions alive when a customer's card is reissued, because the token is automatically kept up to date by the scheme.

Commerce can request network tokens and payment-data bundles (including cryptograms) for use in your acquirer integration, without exposing sensitive card details.

→ Learn about network tokens

Yes. Commerce supports token import, including backing up card payment methods from third-party vaults such as Stripe, so you can move your stored credentials onto Hellgate for use with any processor. Import runs are trackable, and reconciliation reports let you verify that migrated tokens map correctly.

This removes a major barrier to switching – you keep your existing customers' saved cards without asking them to re-enter details.

→ See token migration

Guardian is Hellgate's fully PCI-compliant tokenization service, delivered as managed, dedicated infrastructure. It sits as a protective yet actionable layer between your services and the sensitive data it stores – primarily card credentials – replacing raw data with tokens your systems can safely handle.

By taking sensitive data out of scope, Guardian unlocks composability: you can combine payment services freely without each one dragging PCI scope, compliance, and data-protection obligations along with it.

→ Explore Guardian

Yes. Guardian is a standalone CPA component, fully independent of Hub or Commerce. Many organisations adopt Guardian on its own purely to cut PCI scope – vaulting card data with Hellgate while keeping their existing payment stack – and compose other services later if they choose.

It also works naturally alongside other Hellgate services: Specter, for example, can read token-level signals from Guardian to sharpen fraud scoring.

→ Use Guardian standalone

When you route card data through Guardian, the data lives entirely inside a PCI DSS Level 1 certified cardholder data environment operated by Hellgate – not in your own infrastructure. Your systems only ever handle non-sensitive tokens.

Because your environment never touches the PAN, it falls outside the most demanding PCI requirements. In practice this often moves a merchant from SAQ D (hundreds of controls) to a far lighter SAQ A or SAQ A-EP self-assessment.

→ See Hellgate's Trustcenter

A credit card vault is a PCI DSS-certified environment that stores cardholder data – primarily Primary Account Numbers (PANs) – on behalf of a merchant. Instead of storing raw card data yourself, you store a token: a non-sensitive reference that maps back to the original credential inside the vault.

Because your infrastructure never holds the PAN, it falls outside the most demanding PCI controls, dramatically reducing your compliance burden while you still transact normally using the token.

→ Guardian handles PCI vaulting for enterprise merchants

Cards are the primary use case, but Guardian is not limited to them. Alongside PCI tokens for payment credentials, it offers generic tokens that store arbitrary sensitive payloads – for example SEPA bank details, API keys, or personally identifiable information (PII).

That makes Guardian useful for GDPR-driven data-protection needs as well as PCI: any sensitive value your systems shouldn't hold in the clear can be vaulted and referenced by token.

→ See generic tokens

Guardian supports four token types. PCI tokens (standard) protect card credentials and keep raw PANs out of your systems. Generic tokens (standard) store arbitrary sensitive payloads such as SEPA credentials or PII. Network tokens (add-on) are scheme-issued tokens for higher authorization and lower fraud. Metadata inquiries (add-on) return card and issuing-bank data for display, validation, routing, and analytics.

Add-on features are enabled per account through your Hellgate representative.

→ Compare Guardian token types

Network tokens replace the card PAN with a scheme-issued token that the card networks keep continuously updated. When a customer's card is reissued or its expiry changes, the token still works – so recurring and subscription payments don't fail at renewal.

Because they carry richer, verified data and reduce reliance on static PANs, network tokens typically lift authorization rates, reduce declines, and mitigate fraud. Guardian can provision them from a session, PAN, or existing PCI token.

→ Learn about network tokens

Yes. Guardian supports both PCI token import and export, so you can migrate stored credentials from another vault into Guardian – and move them out again if you ever need to. Migration flows are documented and designed to run without disrupting live transactions.

Portable tokens are a deliberate anti-lock-in feature: your data stays yours, which is central to the CPA philosophy.

→ See token migration

Yes. Guardian is delivered as managed, dedicated single-tenant infrastructure: your instance is provisioned exclusively for your organisation, with compute, storage, and network never shared with other clients. Your payment data is physically isolated, with no possibility of cross-tenant access.

Hellgate operates and manages the infrastructure on your behalf, but full data ownership stays with you – and you can choose an Azure region close to your workloads for latency and data-residency reasons.

→ Getting access to Guardian

Guardian is operated as a PCI DSS Level 1 certified service. When you route card data through it, that data lives entirely within Hellgate's certified cardholder data environment rather than your own infrastructure, so you can significantly reduce your PCI scope and often qualify for lighter self-assessment questionnaires (SAQ A or SAQ A-EP).

Guardian also supports v4.0 requirements such as customised implementation of multi-factor authentication and encrypted data transmission.

→ Hellgate Trustcenter

Metadata inquiries let you retrieve comprehensive card and issuing-bank information from a PAN, a PCI token, or a network token – without exposing the underlying sensitive data. Typical uses include displaying card brand and last four digits, validating a card, making routing decisions (for example, sending a transaction to the acquirer with the best rate for that issuer), and enriching analytics.

It's an add-on feature that turns vaulted data into actionable signal while keeping it protected.

→ See metadata inquiries

Yes. Beyond cards, Guardian's generic tokens can vault other categories of sensitive and personally identifiable information, so PII never sits in the clear in your own systems. Combined with dedicated, single-tenant infrastructure and your choice of Azure region for data residency, this supports GDPR obligations around data minimisation, protection, and locality.

You keep full ownership of the data, while Guardian provides the certified environment that holds it.

→ How Guardian protects sensitive data

Guardian's forwarding lets you send card data to a certified third-party provider without that data ever passing through your infrastructure. You reference a token; Guardian injects the sensitive value (card data, or a network-token cryptogram) into the outbound request server-side, then forwards it.

This is how SAQ-A merchants can, for example, use network tokens or connect to a new processor without ever handling a raw PAN or cryptogram themselves.

→ See secure forwarding

Hub is Hellgate's orchestration fabric – the component that connects your entire payment stack. It links acquirers, PSPs, and fraud-prevention tools into one coordinated system, with intelligent routing, automatic retries, and failover across providers.

Hub is PSP-agnostic and rule-based, so payment teams control how each transaction flows – which provider it goes to, when to retry, and when to step up authentication – from a single control point rather than in scattered application code.

→ Explore Hub

A payment gateway connects your checkout to a single acquirer and passes the transaction through. A payment orchestration layer sits above multiple gateways and acquirers, deciding in real time which route each transaction should take. Hub is Hellgate's orchestration fabric: it applies routing rules, handles failover, integrates fraud scoring from Specter, and gives you one API across all your providers.

The difference is intelligence and portability: a gateway is a pipe; orchestration is the logic that controls which pipe to use, and when to switch.

→ Glossary: Payment Orchestration

Yes. Hub is PSP-agnostic by design and built for multi-PSP, multi-acquirer setups. You can add providers per market or use case, route transactions to the best option for each, and fail over automatically when one provider degrades or declines.

For enterprises, running several PSPs behind one orchestration layer means better geographic coverage, higher acceptance rates, and negotiating leverage – without maintaining separate integrations in your own code.

→ See multi-PSP orchestration

Highly. Hub flows are rule-based: you define how transactions are routed, when retries fire, which provider is primary vs. fallback, and when to enforce steps such as 3-D Secure – all as configurable policies rather than hard-coded logic. AI-native flow support is on the roadmap.

Because CPA keeps concerns separate, you can rearrange these flows – for example, run fraud before or after authorization – without rewriting your integration.

→ See flow customization

Not directly – and that's intentional. In line with CPA, Hub orchestrates but doesn't bundle fraud or KYC into itself. Instead, it integrates those capabilities as separate services: fraud decisioning through Specter, and third-party fraud/KYC providers through Link.

This keeps each concern independent, so you can choose or swap your fraud and identity providers without disturbing your orchestration logic.

→ See how Specter adds fraud intelligence

Yes. Hub can orchestrate flows for your own payment engine or a third-party stack – Commerce is not required. As a standalone CPA component, Hub's job is routing and coordination, so it sits on top of whatever executes the actual authorization.

This lets enterprises that already have a payment engine gain orchestration, routing, and failover without replacing what they've built.

→ Run Hub with your own engine

Hub lifts acceptance in several ways: intelligent routing sends each transaction to the provider most likely to approve it; automatic retries and failover recover transactions when a provider declines or degrades; and it can enforce authentication or network tokens where they improve approval odds.

Combined with local acquiring in key markets, this reduces avoidable declines – a direct revenue gain for high-volume merchants where even small approval-rate improvements are material.

→ See how Hub lifts acceptance

Hub consumes the Specter Score – a real-time risk score assigned to each transaction – and executes configurable policies based on it: allow, block, step up to 3-D Secure, or route differently. Because Specter integrates natively as a CPA component rather than a bolted-on third-party API, its scoring feeds directly into Hub's routing and decisioning with no added latency.

You define the thresholds and rules; Hub enforces them in the payment flow.

→ See Specter + Hub decisioning

Yes. Merchants define their own routing rules, retry logic, and risk thresholds in Hub. You decide which provider handles which transaction, the conditions that trigger a fallback, and the score thresholds at which fraud policies act. Rules are managed centrally rather than embedded in application code.

This gives payment and risk teams direct control to tune performance, cost, and risk appetite as conditions change – without a release cycle.

→ Configure routing and thresholds

Yes. By abstracting acquirers and PSPs behind one orchestration layer – and, via Link, behind stable API contracts – Hub lets you add, remove, or switch providers without re-building your integration. Your payment logic lives in Hub, not in a single vendor's platform.

That portability preserves negotiating leverage and resilience: if a provider's pricing or performance changes, you can shift volume rather than being trapped.

→ How CPA removes lock-in

For enterprises running several acquirers, Hub centralises what would otherwise be fragmented logic: unified routing across all acquirers, automatic failover between them, consistent retry behaviour, and one integration surface instead of many. It supports single-merchant, platform, and ecosystem models, so multi-entity and multi-market structures are handled coherently.

The result is higher acceptance, lower operational overhead, and the flexibility to optimise cost and performance per market.

→ Hub for multi-acquirer enterprises

Hub is part of the Hellgate Cloud Platform and is rolling out for general access alongside Specter, Link, and Pulse, complementing Guardian and Commerce which are already available. Real payment volume already flows through Hellgate's orchestration and abstraction layers today.

If you want to evaluate Hub for your stack, the fastest path is to talk to Hellgate about access and a scoped pilot for your use case.

→ Book a demo to discuss Hub access

Link is Hellgate's protocol-abstraction runtime and the platform's PSP and provider connectivity layer. You define a versioned API contract – a protocol – once, and bind it to one or more real providers through declarative backends. Callers invoke the protocol; Link maps each request onto the configured provider, dispatches it, maps the response back, and logs the exchange.

The result is a clean split between the API your code uses and the provider that actually fulfils it: change what's behind the API without changing the API.

→ Explore Link

A PSP abstraction layer decouples your application from the specific wire formats of individual payment service providers. Instead of coding to each PSP's API, you code to one stable contract; the abstraction layer translates that contract into whatever each provider expects.

Link is that layer for Hellgate. It means adding a provider, or switching between them, becomes a configuration change rather than a new engineering integration – the difference between weeks of work and re-pointing a contract.

→ How PSP abstraction works

Yes – that's its core value. Because your systems call a stable protocol rather than a specific provider, you can re-point that protocol to a different backend, or run several backends side by side, without changing the caller and without a re-build. A provider migration becomes your configuration change instead of a customer-facing project.

For enterprises, low switching costs mean real leverage: you can move volume between PSPs on commercial or performance grounds whenever it makes sense.

→ See how Link lowers switching costs

Link supports the core payment operations you'd expect a provider contract to expose – authorize, capture, refund, payout, and settlement – plus actions like assess for risk checks. Each operation is defined as an action within a protocol, with a schema-validated request and response shape.

Because protocols are versioned and generate their own OpenAPI specification, every integration starts with a clear, documented contract.

→ See Link protocols and actions

Yes. Partners and teams can define new provider integrations as Link backends – adapters that bind a protocol to a specific provider through declarative mapping rules, credentials, and an authentication strategy. Because adapter logic lives in versioned templates and a filter chain rather than per-vendor code, new connectors don't require redeploying the runtime.

This makes Link extensible: the ecosystem of supported providers can grow through configuration.

→ See Link backends and adapters

Both. Within the platform, Link is the connectivity layer that Commerce routes through to reach acquirers and that Specter reaches through to call external risk engines – so it's bundled by default when you use those services. It's also available as a standalone edition you can use on its own.

Whichever way you adopt it, Link's role is the same: decouple your consumers from vendor wire formats.

→ Bundled vs. standalone Link

Link keeps adapter logic in versioned templates and a declarative filter chain rather than in per-vendor code or deploys. To integrate or change a provider, you define mapping rules that translate a protocol into that provider's request and response format – configuration that can be updated without shipping application code.

Where other CPA services own a capability (Guardian owns tokenization, Specter owns decisioning), Link owns the connection, so integration stops being an engineering bottleneck.

→ Integration as configuration

A protocol is the versioned, schema-validated API contract – the actions callers invoke (assess, authorize, capture, refund) and the shape of each request and response. A backend is the binding from that protocol to a real provider: credentials, an authentication strategy, and the declarative mapping rules that translate the contract into the provider's wire format.

Because the two are separate, you can point one protocol at a different backend – or run several in parallel – without the caller ever knowing.

→ Protocols vs. backends

Link is built for secure provider connectivity. It supports message-level JWE encryption of request and response bodies with rotatable keys, and it can rotate backend credentials and encryption keys without downtime. Outbound calls pass an SSRF guard – HTTPS-only, no private or internal addresses – validated when you register or update a backend or imported protocol URL.

These controls let you meet strict provider and security requirements without building the plumbing yourself.

→ See credential and key rotation

Yes. Every invocation through Link is recorded asynchronously in an execution audit log, capturing timing and the provider's response. This gives you a complete, queryable history of what was sent to which provider and what came back – useful for debugging, reconciliation, dispute handling, and compliance evidence.

Because the log is centralised across all providers behind Link, you get one consistent audit trail rather than fragmented per-vendor logs.

→ See the execution log

Link separates the API your code depends on from the provider that fulfils it. To add a PSP, you register a new backend and its mapping rules; to switch, you re-point the protocol to that backend. Callers keep hitting the same contract throughout, so no application changes are needed and you can even run old and new providers in parallel during migration.

This is how Hellgate runs real volume across very different backends behind single, stable contracts.

→ Add or switch PSPs with Link

Yes. Link is a general protocol-abstraction runtime, not payment-only. Specter reaches external risk engines through Link, and the same mechanism can bind protocols to virtually any HTTP-based provider – fraud services, data enrichment, KYC, and more.

That generality is what lets the CPA stay open: any external capability can be composed in behind a stable contract, then swapped or extended by configuration.

→ See how Specter uses Link for backends

Specter is Hellgate's real-time fraud intelligence layer – a low-latency, high-throughput decision engine that analyses every transaction as it moves through your payment flow, assigns a risk score, and blocks bad actors before checkout. It combines fast in-process rules with integrations to external risk services, and improves detection over time by ingesting transaction data.

Like every CPA component, Specter runs standalone or composed with other services.

→ Explore Specter

Specter evaluates signals such as device fingerprinting, geolocation, behavioural velocity (rolling-window counts per card, customer, device, or IP), and token-level data – without ever exposing sensitive card details. These feed both in-process rules and external risk backends.

The combination lets Specter catch patterns typical of fraud – unusual velocity, mismatched geographies, high-risk device signals – while keeping sensitive data protected.

→ See how Specter evaluates transactions

Specter assigns a real-time risk score (0–100) to every transaction as it moves through Hub. For chargeback-prone patterns – first-time customers, high-value orders from high-risk geographies, unusual velocity – it triggers configurable policies: stepped-up verification, 3-D Secure enforcement, or outright blocking. The score draws on device fingerprinting, geolocation, behavioural velocity, and token-level signals.

Because Specter integrates natively as a CPA component rather than a bolted-on API, its scoring feeds directly into routing and decisioning with zero added latency.

→ Learn more about Specter

Specter is backend-agnostic. It integrates with external risk engines – such as Visa Decision Manager, Worldpay FraudSight, Ravelin, and Featurespace ARIC Risk Hub – reached through a Link integration. You select the backend, or combination of backends, that fits your transaction profile, geography, and risk appetite.

Specter normalises each backend's output into a single Specter Score, and adding a new backend is configured at the platform level without changing your integration.

→ See all Specter backends

Yes. Specter and Guardian are independent CPA components. Specter provides real-time fraud intelligence and risk scoring; Guardian provides PCI-compliant vaulting and tokenization. They integrate naturally when both are in use – Specter can read token-level signals from Guardian to improve scoring accuracy – but each can be deployed standalone or alongside your existing infrastructure.

So you can add Specter for fraud without adopting Guardian, and vice versa.

→ Guardian overview

Specter can run standalone with basic orchestration, providing rule-based scoring and blocking on its own. Full rule appliance and advanced decisioning – where scores drive routing, retries, and step-up in real time – come together with the CPA Hub.

This means you can start with Specter for fraud scoring and unlock deeper decisioning as you compose it with Hub, without re-integrating.

→ See Specter integration options

Hub consumes the Specter Score and executes real-time policies against it – allow, block, step up to 3-D Secure, or route differently. Because Specter is a native CPA component rather than a third-party API, the score flows straight into Hub's routing and decisioning without added latency.

You define the thresholds and rules once; Hub enforces them consistently across every transaction and every provider.

→ See Specter + Hub decisioning

Yes. Specter is a decision engine built to encode complex fraud and business rules. You define local rules (boolean conditions and velocity counters over the decision context), maintain blacklists with optional TTLs, and set the score thresholds at which policies act. Rules and thresholds are yours to configure and tune.

Because everything is expressed as configurable rules, risk teams can adapt to new fraud patterns quickly, without a code release.

→ See the Specter rule engine

The Specter Score is a single, real-time risk score (0–100) assigned to every transaction. It combines Specter's in-process rules and velocity signals with the normalised output of any external risk backends you've connected, so multiple fraud sources resolve into one consistent number.

Downstream, Hub uses the score to make decisions – approve, block, or step up – giving you a single, tunable control point for fraud across all providers.

→ Learn about the Specter Score

Specter offers two integration patterns. The Decision API has your system call POST /api/decisions before authorizing and branch on the result – maximum control and the richest context. The Interceptor sits inline as a transparent proxy in front of your acquirer, forwarding approved transactions and returning a configured response for those it flags – adding fraud checks with no backend changes.

Both evaluate the same rulesets and return the same outcomes; they differ only in where the integration lives.

→ Compare Specter integration patterns

Specter is engineered as a low-latency, high-throughput engine. Local rules and velocity counters are evaluated in-process, with no external calls, so they add minimal latency. Because Specter integrates natively into the CPA rather than as a bolted-on third-party API, its scoring feeds directly into routing and decisioning with effectively zero added latency.

External risk backends, when used, are invoked only where your rules call for them – you control the trade-off between depth and speed.

→ See Specter's architecture

Specter continuously ingests transaction data, so detection sharpens as it observes more of your traffic. Lifecycle events – such as chargebacks and fraud reports – can auto-populate blacklists, closing the loop between confirmed fraud and future blocking. Combined with tunable rules and multiple risk backends, this lets your defences adapt to emerging patterns.

You keep control: the engine learns from your data while you decide the rules and thresholds it enforces.

→ See lifecycle events and learning

The Payment Card Industry Data Security Standard (PCI DSS) is the security standard that governs how organisations store, process, and transmit cardholder data. Any business that touches card data – merchants, platforms, and service providers – must comply, with the level of obligation scaling to transaction volume and how data is handled.

Non-compliance risks fines, higher processing costs, and liability after a breach, which is why reducing how much card data you touch is so valuable.

→ Visit the Hellgate Trustcenter

Hellgate reduces your scope by keeping card data out of your systems. Guardian, a PCI DSS Level 1 certified vault, stores cardholder data inside a certified environment operated by Hellgate; your systems handle only non-sensitive tokens. The Web, iOS, and Android SDKs capture card data on the client and tokenize it, so raw PANs never reach your servers.

The practical outcome is often a move from SAQ D to a much lighter SAQ A or SAQ A-EP.

→ How Guardian cuts PCI scope

Self-Assessment Questionnaires (SAQs) reflect how much card data you handle. SAQ A is the shortest, for merchants who fully outsource card data handling (for example, via a hosted vault). SAQ A-EP applies when your site affects the payment page but you don't store card data. SAQ D is the most demanding, with hundreds of controls, for merchants that store, process, or transmit card data directly.

By vaulting card data with Guardian, merchants typically qualify for SAQ A or SAQ A-EP instead of SAQ D.

→ See how Guardian simplifies your SAQ

Guardian is operated as a PCI DSS Level 1 certified service. When merchants route card data through Guardian, that data lives entirely within a certified cardholder data environment operated by Hellgate – not within the merchant's own infrastructure – so they can reduce their own PCI DSS scope significantly, often qualifying for lighter questionnaires (SAQ A or SAQ A-EP).

Guardian also supports the v4.0 requirement for customised implementation of multi-factor authentication and encrypted data transmission.

→ Hellgate Trustcenter

Yes. Guardian is operated as a PCI DSS Level 1 certified service – the highest level of PCI compliance, required of service providers handling the largest volumes of card data. Card data routed through Guardian is held within this certified cardholder data environment.

You can review Hellgate's certifications and security posture in the Trustcenter, which is the authoritative place for current compliance documentation.

→ Review certifications in the Trustcenter

Tokenization replaces sensitive data – such as a card PAN – with a non-sensitive token that maps back to the original value held in a secure vault. Your systems use the token for everyday operations and never store the real card number.

For compliance this is decisive: because the sensitive value lives only in a certified environment, the systems that handle tokens fall outside the most demanding PCI controls, shrinking both your risk and your audit burden.

→ How Guardian tokenization works

Yes – that's the whole point of using a certified vault. By capturing card data through Hellgate's SDKs and storing it in Guardian's PCI Level 1 environment, you can run payments, subscriptions, and refunds using tokens while never holding a raw PAN in your own systems.

Removing card data from your environment is the most effective way to reduce PCI obligations, and it also shrinks your exposure in the event of a breach.

→ Transact without storing card data

Network tokens are scheme-issued replacements for the card PAN. Because a network token isn't the raw card number, using it in place of a PAN reduces the sensitive data flowing through your environment, complementing vaulting in lowering PCI exposure.

With Guardian's forwarding, even the cryptogram a network token needs can be injected server-side, so SAQ-A merchants can use network tokens without ever handling raw payment credentials.

→ Learn about network tokens

A cardholder data environment (CDE) is the set of systems, people, and processes that store, process, or transmit cardholder data – and everything connected to them. The size of your CDE largely determines your PCI DSS burden, because every component in scope must meet the standard's controls.

By routing card data through Guardian, the CDE effectively becomes Hellgate's certified environment rather than yours, which is what shrinks your compliance footprint.

→ See Hellgate's certified environment

No – and any vendor claiming otherwise is overstating it. Using Guardian dramatically reduces your PCI scope by keeping card data out of your systems, typically moving you to a lighter self-assessment questionnaire. But you remain responsible for your own environment, your integration, and completing the applicable SAQ.

Hellgate provides the certified infrastructure and documentation to make that far simpler; the remaining obligations are yours to attest to.

→ Find compliance documentation

Hellgate's compliance documentation, certifications, and security posture are published in the Hellgate Trustcenter. It's the authoritative, up-to-date source for details such as PCI DSS certification, data protection, and infrastructure security – the material your security and procurement teams will typically request during due diligence.

For questions specific to your setup, your Hellgate account representative can provide the relevant documentation directly.

→ Visit the Hellgate Trustcenter

Because CPA isolates compliance into dedicated components, regulatory change touches a bounded part of your stack rather than all of it. When rules evolve – a new PCI DSS version, updated SCA requirements, changing data-residency laws – you update or reconfigure the relevant component (Guardian for data, Commerce for 3-D Secure) without re-architecting everything around it.

Evolvability is a core CPA principle: adapt incrementally instead of running a large compliance re-build each time the landscape shifts.

→ How CPA supports evolving compliance

Pulse is early-stage. It is rolling out on the Hellgate Cloud Platform with metrics and notifications first, and AI-native capabilities planned for later. Pulse is the observability and metrics layer of the CPA, turning raw transaction data into live insight across your payment flows.

If you'd like to evaluate Pulse for your stack as it becomes available, the fastest route is to talk to Hellgate about early access.

→ Explore Pulse

Hub events are observable via Pulse. As Hub orchestrates transactions – routing, retries, failover, and decisioning – it emits events that Pulse streams and surfaces as live metrics and performance trends.

Because both are CPA components, this integration is native rather than a bolted-on export: Pulse gives payment teams real-time visibility into what Hub is doing, without building a separate analytics pipeline.

→ See Pulse observability

Yes – via Providers and Link. Because external providers are reached through Link, their invocations and responses are observable, so Pulse can surface performance and health for third-party services alongside Hellgate's own components.

That gives you one observability layer across your whole payment stack – acquirers, PSPs, and risk services included – rather than fragmented, per-vendor dashboards.

→ See what Pulse monitors

Anomaly detection is planned via Pulse's AI-native features. The initial focus is real-time metrics and notifications; automated anomaly detection – flagging unusual patterns in approval rates, latency, or provider behaviour – sits on the roadmap as those AI capabilities roll out.

The direction is to move payment teams from reactive dashboards to proactive alerts on the trends that matter.

→ See the Pulse roadmap

No. Commerce is optional. Guardian, Hub, Specter, and Link are all standalone CPA components you can adopt independently of Commerce and compose with your own payment engine or a third-party stack.

Commerce is the ready-made, composed option for teams that want a complete payment engine out of the box; if you already have one, you can still use the individual Hellgate services around it.

→ Compose only what you need

Yes. Specter is a decision engine built to encode complex fraud and business rules. You define local rules (boolean conditions and velocity counters over the decision context), maintain blacklists with optional TTLs, and set the score thresholds at which policies act – then Hub enforces them.

Because everything is expressed as configurable rules, risk teams can adapt to new fraud patterns quickly, without a code release.

→ See the Specter rule engine

In-car payment technology turns the vehicle into a secure payment platform, letting drivers pay directly from the car for services such as fuel, EV charging, parking, tolls, and other connected-car services. It integrates with the vehicle's existing infotainment and systems while maintaining bank-grade security standards.

Hellgate powers these experiences through Commerce, combining tokenization and strong authentication so payments initiated from the vehicle stay secure and PCI-compliant.

→ Build in-car payment experiences

In-car payments are protected by multiple layers: FIDO-based authentication, tokenization that keeps raw card data out of the vehicle, and secure element technology. Advanced encryption and authentication protect every transaction while maintaining compliance with global security standards.

With Hellgate, sensitive credentials are vaulted in Guardian's PCI DSS Level 1 environment, so the car and your systems handle only tokens – never the underlying card number.

→ How Guardian secures payment data

Common in-car payment use cases include:

• Fuel and EV charging payments

• Parking fees and tolls

• Drive-through and on-the-go purchases

• Vehicle-related subscriptions

• Connected-car services

All of these can run through a single, secure payment layer, so automotive and mobility brands add new revenue streams without stitching together separate integrations.

→ See in-car use cases

Businesses gain in several ways:

• Increased customer convenience and loyalty

• Higher transaction completion rates

• New revenue opportunities from connected-car services

By embedding seamless, low-friction payments into the vehicle, automotive OEMs, mobility providers, and fuel or charging networks reduce checkout friction and open recurring revenue – all on secure, PCI-compliant infrastructure.

→ See Commerce for mobility

Implementation typically requires:

• A compatible vehicle infotainment system

• Secure payment processing infrastructure

• Integration with payment networks

• Compliance with automotive industry standards

• Connection to merchant services

Hellgate provides the SDKs, tokenization, and PCI-compliant infrastructure to cover the payment side, so your team focuses on the in-vehicle experience rather than payment plumbing.

→ See implementation requirements

Payment orchestration lets charging networks connect to multiple payment processors through a single integration, simplifying the payment ecosystem and creating redundancy if a provider has an outage. This gives flexibility in processor selection, optimized costs, and greater reliability for EV charging infrastructure.

With Hellgate Hub as the orchestration fabric, EV networks route each transaction to the best processor, fail over automatically, and manage everything from one API.

→ Learn about payment orchestration

International EV charging networks face unique challenges around currency conversion, regional regulations, and cross-border acceptance. Hellgate applies industry-leading security protocols and complies with PCI DSS to keep every transaction secure, wherever the charging session happens.

Card data is vaulted in Guardian's PCI DSS Level 1 environment and can be tokenized for reuse, so cross-border sessions stay both secure and compliant with local requirements.

→ See Hellgate's security posture

Charging networks can address complex payment challenges through orchestration:

• Managing multiple payment processors

• Optimizing transaction costs

• Supporting membership and subscription models

• Reconciling complex payment flows

• Improving authorization rates

• Unified reporting across regions and business units

→ See how Hub solves these

Charging station owners using orchestration benefit from:

• Improved operational efficiency

• Reduced transaction costs

• Centralized reporting

• Flexible payment options for a better customer experience

• Recurring billing capabilities

• The ability to scale as their charging network grows

→ See Hub for charging networks

Implementation typically requires API integration with your existing charging management system, but minimal technical change beyond that. Hellgate provides comprehensive documentation, SDKs, and implementation support to ensure a smooth transition to the new payment infrastructure with minimal disruption to charging operations.

Because orchestration sits above your processors, you add providers and routing logic as configuration rather than re-building your platform.

→ See implementation for orchestration

Airline payment orchestration turns your payment infrastructure into a flexible, unified platform, letting airlines manage transactions across multiple channels, markets, and payment methods. It integrates with your existing PSS and reservation systems while maintaining high security standards and optimizing authorization rates.

Hellgate Hub provides the orchestration fabric – routing, failover, and one API across all your acquirers and payment methods – so airlines scale globally without new integration projects per market.

→ Learn about airline payment orchestration

Cross-border airline payments are protected by multiple layers: tokenization, 3-D Secure authentication, and secure element technology. Hellgate uses advanced encryption and authentication so every transaction is protected, while maintaining compliance with global standards including PCI DSS and regional regulations.

Card data is vaulted in Guardian's PCI DSS Level 1 environment, keeping raw PANs out of your PSS and reducing your compliance scope across every market you sell in.

→ See Hellgate's security posture

Common airline payment orchestration use cases include:

• Direct ticket sales

• Refund processing

• Agency settlements

• Multi-currency transactions

• Corporate travel payments

• Ancillary revenue streams

• Alternative payment methods and loyalty integrations across all booking channels

→ See airline use cases

Airlines benefit through increased authorization rates, lower processing costs, and new revenue opportunities. Seamless payment experiences then translate into:

• Higher conversion rates

• Dynamic routing for optimal transaction success

• Reduced foreign-exchange fees

• Less operational overhead for reconciliation and settlement

→ See Hub for airlines

Implementation typically requires integration with your existing PSS/reservation system, a connection to your finance and reconciliation systems, and access to your distribution channels. Hellgate's platform manages integration with the payment networks, handles compliance with payment-industry standards, and connects to local and global payment methods through a single API.

Because orchestration sits above your acquirers, adding a market or method is configuration rather than a new build.

→ See airline implementation

A credit card vault is a PCI DSS-certified environment that stores cardholder data – primarily Primary Account Numbers (PANs) – on behalf of a merchant. Instead of storing raw card data in your own systems, you store a token: a non-sensitive reference that maps back to the original credential inside the vault.

Because your own infrastructure never touches the PAN, it falls outside the most demanding PCI DSS requirements. The result is a dramatically reduced compliance scope – typically from SAQ D (hundreds of controls) to SAQ A (a short self-assessment).

→ Hellgate Guardian handles PCI vaulting for enterprise merchants · Full guide: Credit Card Vault

A local rule runs in-process inside Specter – boolean conditions, velocity counters, and checks over enriched metadata. It evaluates in microseconds, needs no external call, and carries no per-decision fee. A backend rule delegates scoring to an external risk engine (such as Worldpay FraudSight) reached through a Link integration, for judgements a single transaction can't make on its own.

The rule of thumb: deterministic and cheap belongs local; probabilistic or dependent on data you don't hold belongs in a backend. Most fraud is caught by the cheap local net, so the paid model call is reserved for genuinely ambiguous transactions.

→ See how Specter's rule engine works

Specter charges a fixed platform fee for the runtime rather than a fee per decision. That means predictable OPEX that consolidates fraud tooling into one line, instead of a cost that scales linearly with every transaction you screen.

Because most fraud is stopped by cheap, in-process local rules before any paid external call is made, you also avoid paying a model to score transactions a simple boolean check could resolve – lowering both cost per decision and latency.

→ Learn how Specter is priced

No. Legacy acquirer or Feedzai-style rulesets typically collapse into a handful of repeating patterns – velocity, positive and negative lists, geographic and BIN mismatch, IP and email intelligence, fraud-history linkage, and behavioural or ML scoring. Roughly the large majority map directly onto Specter local rules, and only the behavioural or ML minority needs a backend.

Rulesets are versioned and move through a DRAFT to ACTIVE lifecycle with rollback, so you review a diff and activate rather than filing a change request with your acquirer. Pruning a dead rule becomes trivial and safe.

→ See how rulesets migrate to Specter

Every backend rule in Specter has an on_error setting: allow (fail-open, the default, so an outage never blocks genuine customers), block (fail-closed), or review. Specter also checks that a transaction carries the fields a backend needs before calling it; if fields are missing, it skips the call and tells you which ones.

Velocity counters are fail-open too: if the counter store is unavailable, the check never blocks a real customer. This keeps checkout resilient even when an external dependency degrades.

→ See backend error handling

Specter backend groups let you run providers in fallback (try in order), parallel (call all and merge outcomes), or split (weighted A/B) mode. A member can also run in shadow mode, where it executes and its result is recorded but doesn't affect the live decision.

That means you can test a new provider against real traffic before trusting it, then promote or swap it by configuration – without touching your integration or exposing customers to an unproven model.

→ See backend groups and shadow mode

Yes. Specter is backend-agnostic and its catalogue includes engines such as Worldpay FraudSight, Ravelin, Visa Decision Manager, and Featurespace, each reached through a Link integration. FraudSight, for example, returns an outcome, a score, and a human-readable reason such as card unfamiliarity or an unusual transaction for the merchant.

Specter normalises each backend's output into a single Specter Score, so you keep the provider you trust while gaining one consistent decision and one control point across all of them.

→ See supported fraud backends

Because most fraud is caught by cheap, deterministic checks. Running the local net first – velocity, blocklists, amount thresholds, geography and BIN mismatches – stops the majority of fraud for free and in microseconds, and reserves the paid ML call for the genuinely ambiguous remainder.

The result is lower cost per decision, lower latency, and logic your risk team can read and change directly. You can also combine both in one decision: local rules pre-filter, a backend scores the rest, and Specter returns a single combined outcome.

→ See how Specter combines rules and models

Metadata is a flat key–value map you attach to each transaction, available to local rules but not sent to backends. Any signal your checkout or PSP already computes – IP geolocation, an anonymizer flag, BIN country, an email-risk band, a reshipper flag, MIT or CIT type – can be passed once and consumed by local rules.

This is the migration workhorse: it lets the large majority of a legacy ruleset run locally even though Specter itself does no IP, email, or BIN enrichment. You bring the enriched signal; Specter turns it into fast, free decisioning.

→ See how metadata powers local rules

A velocity rule is a rolling-window counter – for example, more than five attempts on the same card in the last hour. Specter maintains these counters per card, per device IP, per device fingerprint, and per customer, so you can catch bursts that a single transaction wouldn't reveal.

Velocity checks are evaluated in-process as local rules, so they add minimal latency and carry no per-decision fee. They are also fail-open: if the counter store is unavailable, the check never blocks a genuine customer.

→ See velocity rules in the rule engine

Each vertical has a distinct card-not-present fraud signature, and Specter pairs a fast local net with a scoped external call for each. Subscription merchants face card testing and free-trial abuse, met with burst velocity per IP and disposable-email blocks. Fashion faces reshipping of high-value goods, met with card velocity and billing-shipping country mismatch rules.

Travel platforms face high-value, non-recoverable bookings behind anonymized traffic; airlines face liquid, high-value tickets with rich booking-level tells such as passenger-not-cardholder on a one-way fare. In each case cheap local rules handle the obvious cases and a backend scores the ambiguous remainder.

→ See Specter for your industry

Specter evaluates the rules in your active ruleset in order and returns one of three outcomes: ALLOW, REVIEW, or BLOCK. A BLOCK stops evaluation immediately, REVIEW outcomes accumulate, and if nothing matches the result is ALLOW. Signals go in and a decision comes out, in real time.

Rules can be condition (boolean logic over the transaction), backend (delegate to an external engine), backend_group (several backends together), or blacklist (block when a field matches a blocked value). You decide the order and the thresholds; Specter enforces them consistently on every transaction.

→ See how the decision engine works

Rules of the form "email or card linked to fraud in the last N days" map onto Specter's blacklist, which supports a TTL and can be auto-populated from lifecycle events such as a chargeback, a fraud report, or a failed transaction. Report the fraud once and the entry lands on the blacklist with, for example, a 60-day expiry.

Future transactions then match automatically, with no manual list-keeping, and the entry ages out when the TTL lapses. This closes the loop between confirmed fraud and future blocking while keeping your lists clean.

→ See blacklists and lifecycle events