與支付提供商的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，票房延誤是罕見的，事件是可以控制的。