Service Level Agreement

Effective: [EFFECTIVE DATE] · Version 1.0

Part of the Terms of Service. It applies to the production environment only. The sandbox is simulated, is for testing, and carries no commitment.

Set these numbers to what you can actually deliver. An SLA you miss every month is a contractual liability, not a marketing asset. The figures below are placeholders to be agreed commercially — start conservative.

1. Availability commitment

We target `[TARGET — e.g. 99.5]`% monthly availability of the production API.

Availability means the API accepts requests and returns non-5xx responses for operations that do not depend on a third party.

Excluded from the calculation

Payment-provider downtime. If MTN Mobile Money or Orange Money is unavailable, transactions on that rail will fail. We do not control their systems and cannot commit to their uptime — this is the single largest source of real-world payment failure, and no aggregator can absorb it.
Scheduled maintenance notified at least [e.g. 48] hours in advance
Emergency maintenance to address a security vulnerability
Force majeure, including network, power and infrastructure failures beyond our control
Issues caused by your own systems, configuration, or integration
Suspension of your account under the Terms
Rate limiting applied because you exceeded documented limits

2. Support

Channel	Availability
Email — `[SUPPORT EMAIL]`	`[e.g. Monday–Friday, 08:00–18:00 WAT]`
Security — `[SECURITY EMAIL]`	Monitored continuously

Target first-response times

Severity	Definition	Target response
P1 — Critical	Production fully down; no payments can be processed	`[e.g. 2 hours]`
P2 — High	Major function impaired; a significant share of payments failing	`[e.g. 4 business hours]`
P3 — Normal	Partial impairment with a workaround	`[e.g. 1 business day]`
P4 — Low	Question, documentation, or feature request	`[e.g. 3 business days]`

These are response targets, not resolution targets. Resolution depends on the cause, and a fault inside a payment provider is resolved on their timeline.

3. Service credits

If monthly availability falls below the target, you may request a service credit against the following month's fees:

Monthly availability	Credit
`[< 99.5% but ≥ 99.0%]`	`[10]`% of that month's fees
`[< 99.0% but ≥ 95.0%]`	`[25]`% of that month's fees
`[< 95.0%]`	`[50]`% of that month's fees

Conditions:

Request within `[e.g. 30]` days of the end of the affected month, to [SUPPORT EMAIL], with the dates, times and references affected.
Credits apply to future fees. They are not refunds and are not payable in cash.
The maximum credit in any month is [e.g. 50]% of that month's fees.
Service credits are your sole and exclusive remedy for failure to meet this SLA.
No credit is available while your account is suspended or in arrears.

4. Maintenance

Scheduled: notified at least [e.g. 48] hours ahead, targeted at low-traffic windows. We aim for zero-downtime deployment.
Emergency: we may act immediately to address a security risk, and will tell you as soon as practicable.

5. Status and incidents

[Publish a status page and link it here. A payment platform without a public status page pushes every incident into your support inbox.]

During a P1 incident we will post updates at least every [e.g. 60] minutes until resolved, and provide a post-incident summary within [e.g. 5 business days] on request.

6. Your responsibilities

To rely on this SLA, you must:

Use a supported, current SDK or API version
Handle webhooks idempotently — delivery is at-least-once, and duplicates are normal, not a fault
Retry failed requests with exponential backoff rather than tight loops
Use Idempotency-Key on collection, payout and refund requests
Keep your callback URL reachable and returning 2xx promptly
Stay within documented rate limits
Keep a current technical contact on file

7. Reviews

We review these targets [annually] and will give [e.g. 30] days' notice of material change.

[COMPANY LEGAL NAME] · [SUPPORT EMAIL]