Payments
Check payer eligibility before initiating a payment. Balance, velocity, or sanctions rules return yes or no without card data passing through the verification layer.
Eligibility API · Stateless · Binary decisions
Eligibility check API
Stateless eligibility and authorization infrastructure. One endpoint returns a binary yes or no for a given subject and rule, without storing personal data. Built for payments, benefits, compliance, and access control.
Request inAllow or DenySigned proof out
What is an eligibility verification API?
An eligibility verification API answers one question: is this subject eligible for this rule? The caller sends a subject identifier and a rule name (or circuit_id). The API consults external data sources in real time, applies the rule logic, and returns a single boolean. No session, no identity store, no PII written to disk.
Unlike OAuth or SAML flows that issue tokens and maintain session state, an eligibility API is a decision endpoint. You get yes or no. That reduces compliance surface, simplifies integration, and keeps the system stateless.
Stateless decision infrastructure
Each request is independent; the API does not retain state between calls. Receive subject + rule, resolve against configured data sources, evaluate, return eligible: true | false.
Subject + rule→
Resolve (external data)→
Evaluate→
eligible: true | false
There is no central store of PII to breach and no session to hijack. For fintech and regulated environments, this aligns with data minimization and zero-data designs. See technical architecture.
Privacy-preserving verification
The API does not need to see or store raw personal data to return a decision. AffixIO integrates with data sources that expose only the minimal attributes required for the rule. The API returns only the binary outcome. No PII is logged or persisted by the eligibility layer.
Why not store the result?
Caching eligibility results would create a new data store subject to retention policies and breach risk. By not storing, the API avoids that entirely. Callers can cache in their own boundary under their own policies if needed.
Example API flow
Base URL: https://api.affix-io.com/v1. Verify with POST /v1/verify using identifier and circuit_id from GET /v1/circuits.
Request
# POST /v1/verify{
"identifier": "3a7bd3e27785e7b7a6c0e7c1f4f3f6b8",
"circuit_id": "health-age-verification"
}
Response
{"eligible": true,
"data_retained": null,
"latency_ms": 43
}
Authentication uses API keys, Bearer tokens, or mTLS. Full spec: openapi.json.
Payments, benefits, compliance
Benefits and entitlements
Determine benefit eligibility without pulling full profile data into your app. Centralized, auditable rule logic.
Compliance and access
KYC/AML gates and access control with stateless checks. Each request is independent.
Contact
Tell us your setup
Write to us about your setting. We answer with a practical wiring diagram for your team.