ReferenceFraud controls

Fraud controls

Fraud controls give you a blocklist (bans on ip / email / card_fingerprint / person), sliding-window velocity checks over recent order attempts, and AVS/CVV screening. Velocity and AVS/CVV screening run automatically at checkout, before money moves; you manage the blocklist and read velocity events through the routes below.

Privacy / no enumeration oracle: every subject is stored only as a tenant-salted fingerprint, never in the clear — no raw email, IP, or PAN is persisted. Checkout refuses a banned entity with the same generic decline a normal card decline produces, so probing “is this email banned?” through checkout is impossible.

Blocklist administration (operator-managed)

Tenant-level blocklist administration is operator/console-managed. Merchants manage their own bans through the merchant routes below.

MethodPathPurpose
POST/v1/tenants/:tenant/fraud/bansAdd a ban on an ip/email/card_fingerprint/person subject (stored as a tenant-salted fingerprint).
GET/v1/tenants/:tenant/fraud/bansList the tenant’s active bans (fingerprint previews only).
DELETE/v1/tenants/:tenant/fraud/bans/:idLift a ban.
GET/v1/tenants/:tenant/fraud/velocity-eventsRead the tenant’s recent order-attempt velocity events.

Merchant routes

fdk_ credential, tenant from the credential per credential-carries-ownership, scope manage:own_fraud. Mounted at /v1/merchant/fraud.

MethodPathScopePurpose
GET/v1/merchant/fraud/bansmanage:own_fraudList the caller’s bans.
POST/v1/merchant/fraud/bansmanage:own_fraudAdd a ban.
DELETE/v1/merchant/fraud/bans/:idmanage:own_fraudLift a ban.

AVS/CVV screening

AVS (address verification) and CVV screening run automatically at checkout, before money moves. Their strictness is tuned per store through the store manifest under behavior.fraud — there is no separate API call to enable them.

Notes

  • Bans are keyed to a fingerprint, never a raw identifier — there is no reverse lookup from a ban row back to a plaintext email/IP/PAN.