Skip to main content
Specter is a low-latency, high-throughput decision engine built for the Composable Payment Architecture. It combines fast in-process rules with backend integrations to external risk services for payment fraud prevention — and, because every decision payload is declared by a schema, it hosts rules over any event you define: customer registration, refund requests, disputes.

​
Role in the Hellgate Cloud Platform

Specter gives you a straightforward way to encode complex fraud detection and prevention logic, and the same engine for the business policies that sit next to it. It is built for composition and can be extended through Link to connect to virtually any external fraud-detection service. Like every service on the Hellgate Cloud Platform, Specter can be used standalone or in composition with other services.

​
Main features

Specter combines three sources of signal and control in a single ruleset, each written against a schema that declares the payload.

Schemas

Standard FeatureTyped, versioned declarations of what a decision is about. The built-in transaction schema covers card payments; register your own to decide on any other event. Classification markers on each field drive validation, redaction, and retention.

Local rules

Standard FeatureConditions and velocity counters evaluated inside the engine — boolean expressions over the decision payload, with filters and HMAC fingerprints, plus counts, amount sums and distinct counts over rolling or calendar windows per card, customer, device, IP, or any field you declare. No external calls, evaluated in-process for minimal latency, and simulated before you activate.

Blacklist

Standard FeatureField-based blocking with optional TTLs. Entries are managed through the Admin API or auto-populated from lifecycle events such as chargebacks and fraud reports.

Backends

Standard FeatureExternal risk engines — reached through a Link integration and invoked from backend rules to assess a transaction.

​
Integration patterns

Specter offers two ways to get a decision. Both evaluate the same rulesets and return the same outcomes — they differ in where the integration lives. The API takes any schema; the interceptor is for card payments on the built-in transaction schema. See the integration overview to choose the right approach for your situation.

Decision API

Your system calls POST /api/decisions before authorizing and branches on the result. Full control over the payment flow, with the richest request context.

Interceptor

Specter sits inline as a transparent proxy in front of your payment destination — acquirer, PSP, or gateway — forwarding approved requests and returning a configured response for those it flags. Adds fraud checks with no backend changes.

​
Next steps

Plans & Access

Dedicated infrastructure, tiers, and how to obtain a Specter instance.

Authentication

Authenticate to your instance, and the scopes that gate each endpoint.