Skip to main content
The blacklist lets operators block transactions based on values extracted from the decision context — a card fingerprint, a device IP, a customer ID, and so on. Entries can be created manually through the Admin API or populated automatically from lifecycle events.

​
Entries

A blacklist entry blocks a specific value at a given JSONPath, optionally with an expiry.
​
string
required
JSONPath matched against the decision context (e.g. $.device.ip, $.customer.id).
​
string
required
The exact value to block.
​
integer
Time-to-live. Omit for a permanent entry.
Manage entries with the Admin API (scopes admin:blacklist:read / admin:blacklist:write): For card-fingerprint entries, Specter stores a masked-PAN display_hint (e.g. ****1234) alongside the opaque fingerprint so operators can identify the card without exposing it.

​
Blacklist rules

A blacklist rule in a ruleset blocks any decision whose context contains a matching value, and can auto-populate the blacklist when a configured event arrives:
​
array
JSONPath fields checked against the blacklist on each decision.
​
integer
TTL applied to auto-populated entries. Omit for permanent.
​
array
Event types that trigger auto-population: fraud_report, chargeback, failed. Defaults to ["fraud_report"].
When a matching lifecycle event is ingested, Specter upserts blacklist entries for every configured field using the originating decision’s values. A card that charges back is then blocked on its next attempt.

Lifecycle events

The events that drive blacklist auto-population.