SLA and latency expectations
This page sets the operational expectations developers should build against. The figures below are observed steady-state targets; binding commitments live in your order form and Service Level Agreement.
Uptime
| Tier | Uptime target | Credit terms |
|---|---|---|
| Free Trial / Starter | 99.5% monthly | None |
| Pro | 99.9% monthly | Pro-rated service credits per SLA |
| Business | 99.95% monthly | Pro-rated service credits + early-warning notifications |
| Enterprise | 99.99% monthly (or per order form) | Negotiated; typically pro-rated credits with floor |
Uptime is measured against api.qairopay.com synthetic checks from three geographies. Excluded: scheduled maintenance announced ≥ 72 hours in advance, customer-caused outages (e.g. expired keys at scale), and force majeure as defined in the SLA.
Response time targets
p50 / p95 / p99 targets per endpoint class, measured from inside the QairoPay edge.
| Endpoint class | p50 | p95 | p99 |
|---|---|---|---|
GET reads (single resource) | 40 ms | 120 ms | 250 ms |
GET lists (≤ 100 records, no filters) | 80 ms | 200 ms | 400 ms |
GET lists with filters | 120 ms | 350 ms | 700 ms |
POST writes (pass/card/cardholder) | 180 ms | 500 ms | 900 ms |
| Bulk endpoints (100 items) | 600 ms | 1,500 ms | 3,000 ms |
| Settlement and payout writes | 350 ms | 900 ms | 1,500 ms |
| Real-time auth decisioning (Enterprise) | 200 ms | 400 ms | 800 ms |
These are platform-internal numbers — your perceived latency adds the network round-trip from your servers to QairoPay’s regional edge.
Webhook delivery
We attempt the first delivery within 2 seconds of the underlying event. Retry budget thereafter is the standard schedule — see Retries and delivery.
| Metric | Target |
|---|---|
| First-attempt delivery latency (p95) | < 2 s from event creation |
Successful end-to-end delivery (your 2xx, p95) | < 5 s for healthy endpoints |
| Retention window for replays | 30 days |
| Max retry attempts before endpoint is auto-disabled | 10 (~7 days cumulative) |
Settlement timing
| Leg | Target |
|---|---|
| Card transaction authorized → recorded in QairoPay | < 1 s |
| Card capture → settlement payable accrued | < 5 min |
| Daily netting cycle | T+0, fixed time per program |
| Bridge on-ramp (USD → USDC) | < 30 min from netting cycle |
| USDC delivered to treasury (on-chain confirmation) | < 60 min from netting cycle |
| Fiat off-ramp (U.S. ACH) | T+1 |
| Fiat off-ramp (international wire) | T+2 |
| On-chain USDC payout (Aptos) | < 5 min from request |
Support response targets
| Severity | Target first response | Channel |
|---|---|---|
| Sev-1 (live outage / data exposure) | 15 min, 24/7 | Pager via the sponsor-bank-disclosed escalation runbook |
| Sev-2 (degraded / major feature broken) | 1 business hour | Email + dashboard ticket |
| Sev-3 (functional question, non-blocking) | 1 business day | |
| Sev-4 (informational) | 3 business days |
Severity is assessed by QairoPay support based on the impact reported. If you disagree with the classification, escalate via your account contact.
Maintenance windows
Routine maintenance happens in a published window each Tuesday and Thursday 03:00–05:00 UTC. Maintenance that requires brief service impact is announced ≥ 72 hours in advance via the status page and email to the technical contact on file.
Where the binding language lives
This page is informational. The contractually-binding service levels — including credit calculations, exclusions, and notification obligations — are in the SLA appendix of your order form. Email legal@qairopay.com for a copy.