SLA გადახდის პროვაიდერებით

TL; DR

ძლიერი SLA = გაზომილი KPI, რომელიც დაკავშირებულია ბიზნეს ეფექტთან (AR, TtW, TtR, latence, webhook SLA, settlement timeliness), პლუს პროცესის ვალდებულებები (ესკალაცია, RFO/RCA A A A, ცვლილებები), ფინანსური სტიმპორტები (მომსახურება კრედიტები). ჩვენ ვაკვირდებით საკუთარ მეტრიკებს და პროვაიდერის მონაცემებს, ვამოწმებთ ყოველდღიურ ციკლში და ვატარებთ მზა ფეილოვერის ფლეიბუქებს.

1) ტერმინები და მოქმედების სფერო

SLA (Service Level Agreement) - ხელშეკრულების ვალდებულებები მომსახურების ხარისხის შესახებ.
SLO (სერვისის დონე Objective) - კონკრეტული მიზნობრივი დონის მეტრიკა (საათი/დღე/თვე).
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 კონვერტაცია და ხარისხი

Approval Rate (AR) სეგმენტების მიხედვით: 'country × BIN × method × Device' (ცვალებადია, როგორც „რეფერენდუმის დერეფანი“ გამონაკლისით)

Soft Decline Recovery Support (რეაგირების მხარდაჭერა, მარშრუტიზაცია)

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%)

Schema Stability/Change Notice: შეტყობინება 30 დღის განმავლობაში

Webhooks vs Reports Consistence: განსხვავებები 0. 05%

2. 4 ინციდენტები და მხარდაჭერა

MTTA/MTTR (პასუხი/გამოჯანმრთელების დრო) პრიორიტეტის დონეზე

RFO/RCA (Reason For Outage/Root Cause Analysis) 5 სამუშაო დღე

Planned Maintenance Notice 7 დღე (კრიტიკული - 14 ევრო)

3) რეკომენდებული მიზნობრივი მნიშვნელობები (სახელმძღვანელო)

(შერწყმული მეთოდი/ბაზარი; ბარათები/instant/APM განსხვავდება.)

Uptime API (თვე): 99 ევრო. 95% (კრიტიკული წრე)

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

AR Corridor (რეფერენდუმი): თქვენს მატრიქსში საშუალო ბაზარზე/BIN - 2-3 პროცენტული პუნქტი (დაფიქსირდეს გაანგარიშების მეთოდი)

Refund TtR p95: T + 1 bd ბარათები, instant სარკინიგზო მაგისტრალები 60 s

Payout TtW p95 (instant): ≤ 120 s; (T + 1) - 100% გამოცხადებულ დღეს

Settlement Timeliness: 99% ევრო გამოცხადებულ T + N- ში

Report Delivery: ≥ 99. 5% შეთანხმებულ დროზე

4) გაზომვა და მტკიცებულება

მერჩანტის მხარე (თქვენ): API (app-level timers) ტელემეტრია, 'request _ id' ლოჯისტიკა, ვებჰუკების ლოგოები, შიდა ტირიფი 'auth/capture/refund/payout', საკუთარი Uptime/Latence dashbourd.
პროვაიდერის მხარე: სტატუსის გვერდი, ინციდენტების ტექნიკური მონაცემები, SLA- ს შესახებ მოხსენებები, AR/latency- ის გადმოტვირთვის, ტესტირების მოწმობა.
შერწყმა: თქვენი მოვლენების ყოველდღიური ჩანაწერი PSP ანგარიშებით (იხ. „Crypton“...), სტატისტიკური კონტროლი AR/latency (დერეფნები).
ერთიანი დროებითი ზონა: UTC, ntp სინქრონიზაცია.

5) ფინანსური სტიმულები და სესხები

• Uptime/Latence/Webhook დეგრადაცია - ფიქსირებული% fee სესხები.
• შეფერხება Settlement - სესხი დაკავებული თანხის/საკომისიოს% -ში.
• AR დერეფნის ქრონიკული დარღვევები - როუტინგის/კომისიის/ერთობლივი გეგმის გადასინჯვა.
• Cap/Collar: სესხების/თვის ზედა ზღვარი, გამონაკლისები (ფორსმაჟორი, მარეგულირებელი მოქმედებები).
• Non-performance Exit: ზედიზედ დარღვევების შეწყვეტის უფლება.

6) ინციდენტებისა და ესკალაციების პროცესი

კლასები P0-P3 (P0 - სრული მიუწვდომლობა/მასობრივი უკმარისობა).

• არხები: მოვალეობის შემსრულებელი ჩატი/ტელეფონი, პიკეტის სისტემა, სტატუსის გვერდი.
• RCA (5 გვ.) პრევენციის გეგმით: ტექნიკური, პროცესის, მარშრუტიზაციის ზომები.
• Sapport- ის კომუნიკაცია: მოთამაშეთა შეტყობინებების შაბლონები (შეფერხებები/ალტერნატივა).

7) ცვლილების მენეჯმენტი

Notice - 30 დღე თითო: API/რეესტრების სქემა, 3DS პარამეტრები, მარშრუტები, settlement კალენდარი, საკომისიო მოდელები.
ერთობლივი ტესტები Sandbox + მფრინავში 5-10% ტრაფიკი.
Rollback გეგმა და „feature-flag“ თქვენს მხარეს.

8) უსაფრთხოება და შესაბამისობა SLA- ში

ტრანზიტის/დასვენების, სერტიფიკაციის დაშიფვრა (PCI DSS/SOC), დაუცველობა და მათი აღმოფხვრის დრო.
სანქციების/AML სკრინინგი, PEP, SoF/SoW - პროვაიდერის მიერ მხარდაჭერილი ფუნქციები და მათი SLA.
Data Processing Addendum (DPA), retention и DSAR.
Breach Notification: 24 საათის განმავლობაში უსაფრთხოების ინციდენტის დროს.

9) მონიტორინგი და დაშბორდები

1. Uptime/Latency (p50/p95/p99) მეთოდებისა და რეგიონების მიხედვით.

2. Webhook SLA: მიწოდების დრო, წარმატებული წილი, drebezg/დუბლიკატები.

3. AR/Soft Declines კონტექსტში 'BIN × country × provider'.

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

5. Settlement Timeliness და Aging წარუმატებელი ბრძოლები.

6. Incident Panel: 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) Faylover Playbooks

Auth/Latency დეგრადაცია

მოქმედებები: ჩართეთ smart-routing ალტერნატიული PSP- ზე, გაზარდეთ 3DS გამოწვევა დაუცველ BIN- ზე, soft-decline retrais bacoff- ით.

Webhook შეფერხებები/დუბლიკატები

მოქმედებები: გადადით ნახევარგამოყოფაზე, ჩართეთ იდემპოტენტურობა დამამუშავებლებზე, დროებით გაყინეთ რეფანდური მანქანები.

Settlement დააკავეს

მოქმედებები: სახაზინო StressRess- ის გამოყენება, მყისიერი გადახდების ლიმიტების დროებით შემცირება, PSP- ში ესკალაცია, საკრედიტო მემო.

payouts პრობლემები

მოქმედებები: გადართეთ სარეზერვო სარკინიგზო მაგისტრალზე (SEPA/RTP/სხვა PSP), ჩართეთ 'payout-lock' მაღალი სიჩქარით, პრიორიტეტული VIP.

14) პროვაიდერების მენეჯმენტი და QBR

QBR (Quarterly Business მიმოხილვა): AR/Latency/Webhook/Settlement/KPI სესხები, გაუმჯობესების გეგმა, საგზაო რუკა.
Benchmarking: SLO პროვაიდერების შედარებითი ცხრილი, ინციდენტები, ღირებულება (Cost/GGR), ანგარიშგების ხარისხი.
Scorecard: 0-5 SLA- ს თითოეულ განყოფილებაში.

15) SLA ჩეკის სია

• განისაზღვრება მეტრიკა, ფორმულები და სეგმენტი (UTC, p95/p99, გაანგარიშების ბაზა).
• შედგენილია შეგროვება/დაშბორდები და ყოველდღიური შერიგება PSP ანგარიშებით.
• ასახულია MTTA/MTTR, ესკალაცია, კონტაქტები 24/7, სტატუს გვერდი.
• გათვალისწინებულია სერვისის კრედიტები და ქრონიკული დარღვევების შეწყვეტის უფლება.
• Change notice - 30 დღე, sandbox ტესტები და rollback გეგმა.
• უსაფრთხოება/შესაბამისობა: PCI/SOC, breach-24h, DPA/retention.
• ფეილოვერის ფლეილები და მარშრუტიზაციის ორკესტრთან ინტეგრაცია.
• QBR/scorecard, AR დერეფნების რეგულარული კალიბრაცია.

16) ხშირი შეცდომები

ბუნდოვანი განმარტებები (რა უნდა ჩაითვალოს „წარმატებად“, სადაც p95 უნდა ჩაითვალოს) არის დავები და „ქაღალდის“ SLA.
მისი მეტრიკის არარსებობა დამოკიდებულია პროვაიდერის მოხსენებებზე.
არ არსებობს ფინანსური სტიმულირება - SLA არ მუშაობს.
AR- ს შერევა ანტიფროგრამის ეფექტით - დაფიქსირდეს, რა შედის გაანგარიშების მონაცემთა ბაზაში.
Settlement კალენდრის უგულებელყოფა და დროსონი - შეუსაბამობები და ფულადი სახსრები.

რეზიუმე

სამუშაო SLA არ არის საერთო ფრაზების ერთობლიობა, არამედ ციფრებითა და პროცესებით გაფორმებული კონტრაქტი: მკაფიო SLO ხელმისაწვდომობის/სიჩქარის/კონვერტაციის/დასკვნების/თქვენი ტელემეტრიის მიერ დადასტურებული დასკვნების/ანგარიშგების შესახებ, საკრედიტო მემო დარღვევებისა და მზა ფეილოვერის ფლეიბუტებისთვის. ასეთი SLA ასწორებს მოლოდინს, ამცირებს რეაქციის დროს და პირდაპირ უჭერს მხარს მონეტიზაციის მიზნებს: AR უფრო მაღალია, TtW/TtR უფრო დაბალია, ფულადი შეფერხებები იშვიათია, ინციდენტები კი კონტროლდება.