SLA & Disaster Recovery

This page is the operational commitment: what uptime SohoPay targets, how outages are handled, and how fast support responds. Ops teams should fold the queuing behavior and escalation contacts here into their own runbooks.

​

Uptime target

SohoPay targets 99.9% uptime. The critical path is the Policy Service: because signing is 2-of-3 MPC with the Policy Service holding a required key, no settlement can complete without it. API availability, webhook delivery, and dashboard uptime matter, but Policy Service availability is the number that determines whether money can move. 99.9% allows for roughly 43 minutes of downtime per month. Current and historical uptime is published live on the Observatory.

​

Planned maintenance

Schedule batch agent workloads away from the window if 30 minutes of settlement latency matters to you.

​

What happens to payments during an outage

SohoPay is fail-closed: if the Policy Service is unavailable, nothing settles — there is no degraded mode where checks are skipped. This is a security property, not a bug: an outage can delay your money, never lose or misroute it. During an outage:

1. Submitted payments that pass initial validation are queued, not rejected.
2. Orders still expire on their normal 10-minute TTL — a payment whose order expires while queued fails cleanly with ORDER_EXPIRED, and no fee is charged.
3. On recovery, queued payments are re-checked against every policy (credit, limits, allowlist, AML) and settled in order.
4. You receive the normal payment.settled (or payment.failed) webhook for each, plus settlement confirmation — treat webhooks, not wall-clock time, as your source of truth for settlement state.

​

Incident communication

• Observatory — live system health, current incidents, and maintenance notices. Public, no login.
• Status notifications — incident open/update/resolve notices to registered account contacts.
• Post-incident reports — for incidents breaching the SLA, a written report with root cause and remediation follows within 5 business days.

​

RPO / RTO and backup posture

• Data durability — settlement records are anchored on Base itself; the chain is the ultimate ledger, so a SohoPay database loss cannot lose the record of a settled payment. Off-chain state (agents, orders, webhooks) is continuously replicated with point-in-time recovery, targeting near-zero RPO.
• Multi-region posture — API and Policy Service infrastructure runs across multiple availability zones with cross-region backups; MPC key material lives in AWS KMS with its own durability and access-control guarantees (see MPC Signing).
• Recovery — fail-closed queuing (above) means recovery is a matter of draining the queue, not reconciling divergent ledgers.

​

Support SLA

To get critical routing, put “CRITICAL” (or “SECURITY” for suspected compromise — see the runbook) in the subject line and include IDs (agt_, pay_, req_) and timestamps in UTC.

​

Escalation contacts

1. support@sohopay.xyz — all issues start here; critical subjects page the on-call engineer.
2. Beta-integrator Slack — fastest interactive channel for integrators in the beta program.
3. Enterprise escalation — enterprise contracts include named on-call escalation contacts and phone bridge details in the contract’s SLA annex.

​

Ops readiness checklist

• Observatory bookmarked; status notifications going to a monitored address
• Agents handle delayed settlement (webhook-driven, idempotent retries)
• Sunday 02:00–02:30 UTC window in your team calendar
• “CRITICAL” escalation path documented in your internal runbook
• Webhook endpoint monitored — it’s how you learn queued payments settled

​

Next steps