Developers

One API. One adapter. One SDK.

Your processor calls 0Fraud on each authorisation. Your backend sets controls and receives signed webhooks. Your app embeds the SDK. The contract is published as OpenAPI 3.1, and every example on this page was run against the API.

API reference Download OpenAPI spec

Integration

Live in four steps.

Point your processor at 0Fraud

Register /adapters/<processor>/<issuer_id> as your real-time authorisation endpoint. If we can't answer in time, the payment is approved.

Link cards

Create cardholders with your processor's card tokens. Every rule starts in shadow, so nothing is declined until you choose.

Embed the SDK

Each phone enrols once: keys in the secure chip, plus app attestation. Biometrics, with the device passcode as a fallback.

Handle one webhook

On challenge.created, verify the signature and send a push through your app. The SDK does the rest.

Set a card's protection. Every rule can be off, shadow or enforce; new cards start in shadow.

# Turn protection on for one card
curl -X PUT https://sandbox.api.0fraud.si/v1/cards/card_7Hk2/controls \
  -H "Authorization: Bearer $ZEROFRAUD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "keyed_entry_block": "enforce",
    "location_match":    "shadow",
    "online_approval":   "enforce",
    "scam_check":        "shadow",
    "approval_methods":  "any"
  }'

# 200 OK
{
  "card_id": "card_7Hk2",
  "keyed_entry_block": "enforce",
  "location_match": "shadow",
  "online_approval": "enforce",
  "scam_check": "shadow",
  "location_radius_km": 50,
  "approval_methods": "any",
  "passcode_fallback": true
}

Endpoints

The whole surface, on one page.

Method	Path	What it does
POST	`/adapters/{processor}/{issuer_id}`	Real-time authorisation endpoint your processor calls (Lithic, Marqeta). Always answers in the processor's own format
POST	`/v1/decisions`	Decide on an authorisation from your own switch: approve, decline or challenge, with the rules behind it
GET	`/v1/decisions`	Audit log of every decision, newest first, with each rule's mode and reason
POST	`/v1/cardholders`	Register a cardholder and link card tokens (never card numbers)
GET	`/v1/cards/{card_id}/controls`	Read a card's controls
PUT	`/v1/cards/{card_id}/controls`	Keyed-entry block, location match, online approval, scam check (off, shadow, enforce) and passcode fallback
POST	`/v1/devices/enrollments`	Enrol a phone: hardware-bound keys plus Apple App Attest or Google Play Integrity
POST	`/v1/devices/{device_id}/locations`	Signed location update from the phone
GET	`/v1/challenges/{challenge_id}`	Fetch a pending payment to show the cardholder
POST	`/v1/challenges/{challenge_id}/responses`	Approve or decline, signed in the secure chip, by biometrics or device passcode
GET	`/v1/health/fail-open`	Approvals given without a decision in the last hour, by processor and reason. Alert on any

Sandbox access is available to card issuers. Request access →