| Pattern | How it works | Code changes | Best for |
|---|---|---|---|
| API | Your system calls POST /api/decisions before authorizing, reads the outcome, and acts on it. | Your backend builds the request and branches on the result. | Teams that own their payment flow and want full control. |
| Interceptor | Specter sits inline as a transparent proxy in front of your acquirer. It evaluates the request and either forwards it (ALLOW) or returns a block/review response. | Point your acquirer URL at Specter — no backend logic. | Adding fraud checks with minimal or no integration work. |
API
You stay in full control of the flow: call Specter, inspect the decision, and decide whether to authorize, hold for review, or stop. This gives you the richest request (you choose exactly what context to send) and the most flexibility in how you handle each outcome.Interceptor
Specter terminates the acquirer request, maps it into a decision, evaluates it, and then either transparently forwards the original request to the real acquirer (ALLOW) or returns a configured response (BLOCK / REVIEW)
without contacting the acquirer. Your backend needs no fraud logic — it only changes the destination URL.
Which should I use?
API
Choose this when you control the payment backend and want maximum context
and flexibility.
Interceptor
Choose this when you want fraud protection without changing backend logic.