Skip to main content
Fraud models and rules improve when they learn what happened after a decision. Lifecycle events report the real outcome of a transaction — authorization, capture, chargeback, and more — back to Specter, which fans them out to participating backends and uses them to auto-populate blacklists. Submit an event with POST /api/events. Events are processed synchronously: the response includes a backend_notifications entry for every backend call made before returning. Retrieve a persisted event with GET /api/events/{id}.

​
Event types

Lifecycle event types must be a valid step in the payment’s lifecycle (an authorization before a capture, and so on); events that are not are rejected. fraud_report is the exception — see below.

​
Fraud reports

Fraud is not a payment-lifecycle state: a transaction can turn out fraudulent whether it was captured, merely authorized, or never reported to Specter beyond the original decision. A fraud_report event is therefore accepted in any payment state — including for decisions that never received a lifecycle event at all — and never changes payment_state. Accepting a fraud report sets the decision’s fraud marker, returned on the decision resource: The marker is permanent and first-write-wins: repeat reports are accepted and kept in the event log, but the marker keeps the values from the first report. Like every fraud_report, they also fan out to backends and can auto-populate the blacklist.

​
Request

An event references the originating decision_id; its data is a free-form map stored with the event and forwarded to backends that support the event type.

​
Backend fan-out

Specter forwards each event to every backend that participated in the original decision and supports the event type. Backends are reached through a Link integration. A backend declares which event types it supports. When an event targets a type a backend does not support, Specter records status: "skipped" — not an error. The backend_notifications array in the response reports the outcome of every backend call.

​
Blacklist auto-population

A blacklist rule can listen for specific event types (fraud_report, chargeback, failed) and automatically add the originating decision’s field values to the blacklist — so a card that produces a chargeback is blocked on its next attempt.

Blacklist

Auto-populate blocks from fraud and chargeback events.

Decisions

Resolve REVIEW decisions and notify backends.