> ## Documentation Index
> Fetch the complete documentation index at: https://developer.hellgate.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Choose between the API and interceptor integration patterns.

Specter offers two ways to run a fraud decision before authorization. Both evaluate the same rulesets and
return the same outcomes; they differ only in **where the integration lives**.

| Pattern                                                      | How it works                                                                                                                                                        | Code changes                                                | Best for                                                 |
| ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | -------------------------------------------------------- |
| [API](/products/specter/integration/via-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](/products/specter/integration/via-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.

```mermaid theme={null}
sequenceDiagram
    participant M as Your system
    participant S as Specter
    participant A as Acquirer
    M->>S: POST /api/decisions
    S-->>M: ALLOW / REVIEW / BLOCK
    alt ALLOW
        M->>A: Authorize
    else BLOCK
        M-->>M: Stop payment
    end
```

## 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.

```mermaid theme={null}
sequenceDiagram
    participant M as Your system
    participant S as Specter
    participant A as Acquirer
    M->>S: Acquirer request
    Note over S: Map → decide
    alt ALLOW
        S->>A: Forward request unchanged
        A-->>S: Response
        S-->>M: Response
    else BLOCK / REVIEW
        S-->>M: Configured response
    end
```

## Which should I use?

<CardGroup cols={2}>
  <Card title="API" icon="code" href="/products/specter/integration/via-api">
    Choose this when you control the payment backend and want maximum context
    and flexibility.
  </Card>

  <Card title="Interceptor" icon="diagram-project" href="/products/specter/integration/via-interceptor">
    Choose this when you want fraud protection without changing backend logic.
  </Card>
</CardGroup>