SLAs with payment providers

TL; DR

Strong SLA = measurable KPIs tied to business impact (AR, TtW, TtR, latency, webhook SLA, settlement timing), plus process commitments (escalations, RFO/RCA, changes) and financial incentives (service credits). We monitor with our own metrics and provider data, check in the daily cycle and keep ready-made feilover playbooks.

1) Terms and scope

SLA (Service Level Agreement) - contractual obligations for the quality of service.
SLO (Service Level Objective) - specific target levels by metrics (hour/day/month).
PSP/Acquirer/APM/Bank/RTP - provider types; The SLA can vary on rails.
Methods/actions: 'deposit/auth/capture', 'refund', 'payout/within', 'webhooks', 'settlement'.

Scope of SLA: API/panel, payment processing, notifications, reporting/registers, support, changes (change management), security and compliance.

2) SLA Metrics Dictionary

2. 1 Availability and performance

API Uptime% (minute/five minute granularity)

Auth/Capture Latency p95/p99 (сек)

Webhook Delivery p95 (сек) и Success % (≥99. 9%)

Settlement Time: proportion of batches enrolled in the declared T + N (≥99%)

2. 2 Conversion and quality

Approval Rate (AR) by Segment: 'country × BIN × method × device'

Soft Decline Recovery Support

Refund Success % и TtR p95

Payout Success % и TtW p95

Duplicate/Idempotency Incidents = 0

2. 3 Reliability of data and reporting

Report Delivery SLA: реестры `transactions/settlements/fees` до `HH:MM UTC` (≥99. 5%)

Schema Stability/Change Notice - ≥30 days notice

Webhooks vs Reports Consistency: ≤0 discrepancies. 05%

2. 4 Incidents and Support

MTTA/MTTR by priority level

RFO/RCA (Reason For Outage/Root Cause Analysis) ≤ 5 business days

Planned Maintenance Notice ≥ 7 days (critical - ≥14)

3) Recommended target values (benchmarks)

(Customized for method/market; card/instant/APM differ.)

Uptime API (monthly): ≥ 99. 95% (critical circuit)

Latency p95: Auth ≤ 1. 0 s, Capture ≤ 1. 5 s, Webhooks ≤ 3 s

AR Corridor (reference): not lower than the median by market/BIN in your matrix - 2-3 percentage points (fix the calculation method)

Refund TtR p95: cards ≤ T + 1 bp, instant rails ≤ 60 s

Payout TtW p95 (instant): ≤ 120 s; (T + 1) - 100% on the declared day

Settlement Timeliness: ≥ 99% in the declared T + N

Report Delivery: ≥ 99. 5% before agreed time

4) Measurement and evidence base

Merchant side (you): API telemetry (app-level timers), logging'request _ id', webhook logs, internal events' auth/capture/refund/payout ', own Uptime/Latency dashboard.
Provider side: status page, technical reports on incidents, reports on SLA, uploads on AR/latency, settlement-statement.
Reconciliation: daily reconcile of your events with PSP reports (see "Reconciliation..."), statistical control AR/latency (corridors).
Unified time zone: UTC, ntp synchronization.

5) Financial incentives and loans

• Uptime/Latency/Webhook degradation → fixed% fee credits.
• Delay Settlement → a loan in% of the delayed amount/commission.
• Chronic AR corridor violations → routing/commission revision/joint plan.
• Cap/Collar: upper limit of credits/month, exceptions (force majeure, regulatory actions).
• Non-performance Exit: right to terminate for N consecutive violations.

6) Incident and escalation process

P0-P3 classes (P0 - total unavailability/mass failures).
MTTA/MTTR targets: for example, P0 MTTA ≤ 15 min, MTTR ≤ 2 h.
Channels: duty chat/phone, ticket system, status page.
RCA (≤5 business days) with a prevention plan: technical, process, routing measures.
Communication for support: message templates for players (delays/alternatives).

7) Change Management

Notice ≥ 30 days for: API/registry scheme, 3DS parameters, routes, settlement calendar, commission models.
Joint tests in Sandbox + pilot 5-10% of traffic.
Rollback plan and "feature-flag" on your side.

8) Safety and compliance at SLA

Encryption in transit/rest, certification (PCI DSS/SOC), vulnerabilities and the timing of their elimination.
Sanction/AML screening, PEP, SoF/SoW - provider-supported features and their SLAs.
Data Processing Addendum (DPA), retention и DSAR.
Breach Notification: ≤ 24 hours for a security incident.

9) Monitoring and dashboards

1. Uptime/Latency (p50/p95/p99) by method and region.

2. Webhook SLA: delivery time, success rate, bounce/duplicate.

3. AR/Soft Declines in the context of 'BIN × country × provider'.

4. Refund/Payout Health: Success %, TtR/TtW p95.

5. Settlement Timing and Aging of Non-Arriving Batches.

6. Incident Panel: MTTA/MTTR, open RCA, credit memo.

10) Data model for SLA (minimum)

ts_utc, provider, method_code, action(auth/capture/refund/payout/webhook/settlement),
latency_ms, status, is_success,
bin, country, device_os,
webhook_delivery_sec, webhook_retry_count,
settlement_date, settlement_status,
incident_id, severity, mtta_sec, mttr_sec

11) SQL slices (example)

11. 1 Uptime/Latency

sql
SELECT
DATE_TRUNC('hour', ts_utc) AS h,
provider, method_code, action,
COUNT() FILTER (WHERE is_success)=1. 0 / COUNT() AS success_rate,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY latency_ms) AS p95_ms
FROM sla_events
WHERE action IN ('auth','capture')
GROUP BY 1,2,3,4;

11. 2 Webhook SLA

sql
SELECT
DATE_TRUNC('hour', ts_utc) h, provider,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY webhook_delivery_sec) AS wb_p95,
AVG(CASE WHEN webhook_retry_count=0 THEN 1 ELSE 0 END) AS wb_success
FROM sla_events
WHERE action='webhook'
GROUP BY 1,2;

11. 3 Settlement Timeliness

sql
SELECT settlement_date, provider,
AVG(CASE WHEN settlement_status='ON_TIME' THEN 1 ELSE 0 END) AS on_time_share
FROM sla_events
WHERE action='settlement'
GROUP BY 1,2;

12) SLA item template (sample)

text
1. Availability
- Monthly API Uptime ≥ 99. 95% (5-min granularity).
- Exclusions: Planned Maintenance (≤ 2h/month, 00:00–06:00 UTC, 7d notice).

2. Performance
- Auth p95 latency ≤ 1. 0 s; Capture p95 ≤ 1. 5 s.
- Webhook delivery p95 ≤ 3 s, success ≥ 99. 9%, no duplicates.

3. Financial Operations
- Settlement T+N on-time ≥ 99%; reports delivered by 07:00 UTC D+1 (≥ 99. 5%).

4. Incident Management
- P0: MTTA ≤ 15 min, MTTR ≤ 2 h; P1: 30 min / 4 h.
- RCA within 5 business days with preventive actions.

5. Data & Changes
- 30-day advance notice for API/report schema changes.
- Backward compatibility window ≥ 60 days.

6. Remedies
- Service credits per breach (tiered), cap 25% monthly fees.
- Termination right upon 3 consecutive P0 breaches.

13) Feilover playbooks

Auth/Latency degradation

Actions: enable smart-routing on an alternative PSP, increase 3DS-challenge on vulnerable BINs, soft-decline retrays with backoff.

Webhook delays/duplicates

Actions: switch to polling, enable idempotency on handlers, temporarily freeze auto-refands.

Settlement delayed

Actions: use Treasury StressRes, temporarily lower instant payment limits, escalation to PSP, credit memo.

Payouts issues

Actions: switch to standby rail (SEPA/RTP/other PSP), enable 'payout-lock' for high-risk, VIP prioritization.

14) Provider Management and QBR

QBR (quarterly business review): AR/Latency/Webhook/Settlement/KPI credits, improvement plan, road map feature.
Benchmarking: comparative table of providers by SLO, incidents, cost (Cost/GGR), reporting quality.
Scorecard: 0-5 on each SLA section.

15) SLA Implementation Checklist

• Metrics, formulas and segmentation are defined (UTC, p95/p99, calculation bases).
• Collection/dashboards and daily reconciliation with PSP reports are configured.
• Prescribed MTTA/MTTR, escalations, contacts 24/7, status page.
• Service credits and the right to terminate for chronic disorders are enshrined.
• Change-notice ≥ 30 days, sandbox tests and rollback plan.
• Security/Compliance: PCI/SOC, breach ≤ 24h, DPA/retention.
• Feilover playbooks and integration with the routing orchestrator.
• QBR/scorecard, regular calibration of AR corridors.

16) Frequent errors

Blurred definitions (what is considered "success," where is considered p95) → disputes and "paper" SLA.
The lack of its own metrics → dependence on the provider's reports.
There is no financial incentive → SLA does not work.
Mixing AR with anti-fraud effect → record what is included in the calculation base.
Ignoring settlement calendar and timezones → mismatches and cash gaps.

Summary

A working SLA is not a set of general phrases, but a contract stitched with numbers and processes: clear SLOs on availability/speed/conversion/conclusions/reporting, confirmed by your telemetry, with a credit memo for violations and ready-made feilover playbooks. Such SLA equalizes expectations, reduces response times, and directly supports monetization goals: AR is higher, TtW/TtR is lower, box office delays are rare, and incidents are manageable.