与支付提供商的SLA

TL;DR

强大的SLA=可测量的KPI，与业务影响（AR，TtW，TtR，latency，webhook SLA，定时交易）以及过程承诺（升级，RFO/RCA，更改）和财务奖励（服务信用额）相关。通过监控供应商自己的指标和数据，在日常周期中进行核对，并保留现成的传奇人物。

1）术语和范围

SLA（服务级别协议）是服务质量的合同义务。
SLO（服务级别目标）-按指标（小时/天/月）分列的具体目标级别。
PSP/Acquirer/APM/Bank/RTP-提供商类型；SLA可能因轨道而异。
方法/活动："deposit/auth/capture"，"refund"，"payout/withdrawal"，"webhooks"，"settlement"。

SLA范围：API/面板，支付处理，注释，报告/注册表，支持，更改（更改管理），安全性和合规性。

2）SLA度量词典

2.1可用性和性能

API Uptime%（分钟/五分钟粒度）

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

Webhook Delivery p95 (сек) и Success % (≥99.9%)

Settlement Timeliness： 在声明的T+N中注册的蹦床比例（≥99%）

2.2转换和质量

按细分为： "乡村× BIN × method × device"（可变为"参考走廊"，有例外）

软解锁恢复支持（转发、路由支持）

Refund Success % и TtR p95

Payout Success % и TtW p95

Duplicate/Idempotency Incidents = 0

2.3数据和报告的可靠性

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

计划稳定性/更改通知： ≥30天通知

Webhooks vs Reports Consistency： 差异≤0。05%

2.4个事件和支持

按优先级分列的MTTA/MTTR（响应/恢复前时间）

RFO/RCA（理性/根原因分析）≤ 5个工作日

计划维护通告≥ 7天（关键是≥14天）

3）建议的目标值（基准）

（根据方法/市场进行调整；卡/instant/APM不同。）

Uptime API（每月）： ≥ 99。95%（临界环路）

Latency p95: Auth ≤ 1.0 s, Capture ≤ 1.5 s, Webhooks ≤ 3 s

AR走廊（参考）： 不低于您的矩阵中的市场中位数/BIN-2-3个百分点（提交计算方法）

Refund TtR p95： ≤ T +1 b.d., instant rails ≤ 60 s

Payout TtW p95 (instant): ≤ 120 s;（T+1）-在申报日为100%

Settlement Timeliness： 在声明的T+N中≥ 99%

Report Delivery: ≥ 99.5%在指定时间之前

4）测量和证据基础

商人（你）：API遥测（应用程序级别计时器），"request_id"编写，webhook logi，内部活动"auth/capture/refund/payout"，本身的Uptime/Latency dashboard。
提供商方面：状态页面,事件技术计算,SLA报告,AR/latency卸载,定位状态。
核对：每天的事件与PSP报告（请参阅"核对……"），AR/latency统计控制（走廊）。
一个时间区域：UTC，ntp同步。

5）财政奖励和贷款

• Uptime/Latency/Webhook降级→固定百分比的fee积分。
• 延迟定居点→贷款占延迟金额/佣金的百分比。
• 长期AR走廊违规行为→路由/佣金/联合计划修订。
• Cap/Collar：上限学分/月,例外（不可抗力,监管行动）。
• 非性能出口：终止与N连续违规的权利。

6）事件和升级过程

P0-P3类（P0-完全不可用/质量故障）。
MTTA/MTTR目标：例如P0 MTTA ≤ 15分钟，MTTR ≤ 2小时。
频道：值班聊天/电话，提卡系统，状态页面。
RCA（≤5）具有预防计划：技术，处理，路由措施。
札幌通信：玩家消息模式（延迟/替代方案）。

7）变更管理（变更管理）

通知≥ 30天：API/注册表方案，3 DS参数，路由，设置日历，佣金模型。
在Sandbox+飞行员中联合测试5-10%的流量。
Rollback计划和"功能旗"在您一边。

8）安全与合规在SLA

中止/静止加密，认证（PCI DSS/SOC），漏洞以及消除它们的时间表。
制裁/AML筛选，PEP，SoF/SoW-由提供商支持功能及其SLA。

Data Processing Addendum (DPA), retention и DSAR.

突破通知：安全事件≤ 24小时。

9）监控和行车记录

1.Uptime/Latency （p50/p95/p99）按方法和区域分列。

2.Webhook SLA：交货时间,分数成功,drebesg/副本。

3.AR/Soft Declines切入"BIN ×国家×提供者"。

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

5.定居时间和Aging未完成的战斗。

6.事件小组：MTTA/MTTR，RCA开放，信用回忆录。

10）SLA分析的数据模型（最低）

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切片（示例）

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项目模板（样本）

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）花花公子failover

Auth/Latency降解

行动：在备用PSP上启用智能路由，增加对易受攻击的BIN的3DS-challenge，带有背景的软锁线转发。

Webhook延迟/重复

行动：转向民调，在处理器上启用等效性，暂时冻结自动反射。

Settlement被拘留

行动：利用财政部StressRes，暂时降低即时支付限额，升级PSP，贷款回忆录。

行动：切换备用轨道（SEPA/RTP/其他 PSP），为高风险启用"付费锁定"，VIP优先级。

14）提供商和QBR管理

QBR（季刊业务评论）：AR/Latency/Webhook/Settlement/KPI学分，改进计划，远景路线图。
基准：提供商的SLO，事件，成本（费用/GGR），报告质量的比较表。
Scorecard：每个SLA分区为0-5。

15） SLA实施支票

• 确定指标、公式和细分（UTC, p95/p99,计算基础）。
• 设置PSP 报告的收集/dashbords和每日对账。
• 说明了MTTA/MTTR、升级、24/7联系人、状态页面。
• 在长期违规情况下提供服务信用和终止权利。
• 更改通知≥ 30天，sandbox测试和滚回计划。
• 安全/合规性：PCI/SOC，breach ≤ 24 h，DPA/retention。
• failover花花公子并与路由编排器集成。
• QBR/scorecard，AR走廊的常规校准。

16）经常出错

模糊的定义（将p95视为成功的地方）→争议和"纸质"SLA。
没有自己的指标→依赖提供商的报告。
没有经济激励措施→ SLA不起作用。
将AR与反氟效应混合，→捕获包含在计算基础中的内容。
忽略定居日历和时区→不连续和票房差距。

总结

Worker SLA不是一组常见的短语，而是包含数字和过程的合同：由您的遥测技术确认的可用性/速度/转换/结论/报告/清晰的SLO，以及违规信用模因和现成的伪造者花花公子。这样的SLA平衡了预期，缩短了反应时间，并明确支持了货币化目标：上方的AR，下方的TtW/TtR，票房延误是罕见的，事件是可以控制的。