Კრიპტო კაზინო
Torrent Gear
Გადახდის კარიბჭეებთან ინტეგრაცია: flow, reconciliation
სტატიის სრული ტექსტი
1) გადახდის ორკესტრის როლი iGaming- ში
სალარო არის პლატფორმის „არტერია“: იგი იღებს დეპოზიტებს, იწყებს ფულადი სახსრების მიღებას, ამუშავებს outback/chargeback 'და სინქრონიზირებულია საფულესთან (Ledger). შეცდომა ან შეფერხება აქ სწრაფად გადაიქცევა ფინანსურ და შესაბამისობაში რისკად. არქიტექტურის ამოცანაა სწრაფი და მტკიცედ სწორი ფულადი სახსრების გადინება ნებისმიერი წარუმატებლობის შემთხვევაში.
2) ძირითადი flow PSP- ით (სახელმწიფო რუკა)
2. 1 ანაბარი (სახელმწიფო რუკა)
1. Create _ intent (INITIATED) - პლატფორმის მხარეს გადახდის განზრახვის შექმნა.
2. Authorize (AUTHORIZED) არის Hill PSP- ში (სურვილისამებრ - დაუყოვნებლივ capture).
3. 3-DS/AVS/KYC hooks არის რისკის შემოწმება/რეგულირება.
4. capture (CAPTURED) - თანხების ჩამოწერა; კრედიტის საფულე.
5. failed/expired/canceled ინტენტის ანაზღაურება და დახურვა.
2. 2 კეშუტი (withdrawal)
RG/AML/limites - payout _ initiated - payout _ settled/failed.
„ოთხი თვალის“ დადასტურება VIP/დიდი თანხებისთვის, velocity შეზღუდვები და გეო წესები.
2. 3 Void / Refund
void: გაუქმება capture- ზე (ამოღებულია hold).
refund: ნაწილობრივი/სრული დაბრუნება capture- ის შემდეგ.
ბარათის სქემებისთვის - ცალკეული სტატუსები „წყალქვეშა/კომპრესირებული“.
ინვარიანტი: სიმართლე მოთამაშის ბალანსზე - საფულე. PSP დიზაინები პირდაპირ არ ცვლის ბალანსს; მხოლოდ wallet ბრძანების საშუალებით. credit/debit 'idempotence.
3) Idempotence, გასაღებები და retray
თითოეული write ოპერაცია ახორციელებს 'X-Idempotency-Key' და 'X-Trace-Id'.
საკვანძო შემადგენლობა უკავშირდება ბიზნეს პარამეტრებს (მაგალითად, 'intent _ id + amount + currency').
იგივე გასაღების გამეორება იგივე შედეგია (200 ძველი სხეულით).
Retrai ექსპონენციალური backoff + gitter, მკაცრი 'timeout/deadline'.
4) 3-DS, AVS, velocity, ანტიფროდი
3-DS 2. x: სასურველია challenge-flow მოწყობილობებით-fingerprinting; შეინახეთ ECI/CAVV/DSTransID ჟურნალში.
AVS/CVV: ჩართეთ გადამოწმების კოდები ტელემეტრიაში და როუტინგის წესებში.
Velocity: ლიმიტები ოდენობით/რაოდენობა/ბარათები/ASN/მოწყობილობები (1h/24h/7d).
ქცევითი სიგნალები: გეო/დროის ზონის შეუსაბამობა, მრავალი ბარათი/რამდენიმე ანაბარი, სწრაფი ქეშაუტები.
5) Routing და cascades PSP
წესები: გეო, BIN დიაპაზონი, ბარათის ტიპი, ღირებულება, კონვერტაცია, რისკი.
კასკადი: PSP1 - PSP2 უარის თქმის შემთხვევაში, კალათის დაკარგვის გარეშე (იდუმალი ტოკენი).
A/B/multi-armed bandit: კონვერტაციის და ღირებულების ოპტიმიზაცია.
Fail-Open/closed: გამოიყენეთ safe-default საეჭვო შეცდომებისთვის (მაგალითად, განმეორება სხვა spindle), მაგრამ არა duble-capture- ისთვის.
6) API კონტრაქტები (საცნობარო ფრაგმენტები)
6. 1 ინტენტის შექმნა დეპოზიტზე
POST /v1/cashier/intents
Headers: X-Idempotency-Key, X-Trace-Id
{
"player_id":"p_123", "amount":{"amount":50. 00,"currency":"EUR"}, "method":"card", "metadata":{"brand_id":"A","region":"EU"}
}
→ 201 { "intent_id":"pi_001","status":"INITIATED" }6. 2 საავტორო უფლებები/კაპიტალი
POST /v1/cashier/intents/pi_001/authorize
→ 200 { "status":"AUTHORIZED","psp_ref":"psp_aa1","eci":"05","cavv":"…" }
POST /v1/cashier/intents/pi_001/capture
→ 200 { "status":"CAPTURED","capture_id":"cap_001" }6. 3 Void / Refund
POST /v1/cashier/captures/cap_001/refunds
{ "refund_id":"rf_001", "amount":{"amount":10. 00,"currency":"EUR"} }
→ 202 { "status":"REFUND_SUBMITTED" }6. 4 ვებჰუკი PSP - პლატფორმა (ხელმოწერილი HMAC/EdDSA)
POST /webhooks/psp
X-Signature: sha256=…
{
"event":"payment. captured", "psp_ref":"psp_aa1", "intent_id":"pi_001", "amount":{"minor_units":5000,"currency":"EUR"}, "occurred_at":"2025-10-23T12:05:01Z", "idempotency_key":"cap_001"
}მიმღები ვალდებულია: შეამოწმოს ხელმოწერა/timestamp/nonce, შეცვალოს 'event _ id', კორელაცია 'intent _ id'.
7) სინქრონიზაცია საფულესთან (ლედგერი)
capture შემდეგ: ბრძანება 'wallet. credit '(imempotent) მოთამაშის ბალანსი.
Refund: `wallet. debit '(ან' wallet. hold _ release 'void).
ქეშუთი: 'wallet. debit` → `payout` в PSP; ვებჰუკის შემდეგ 'payout _ settled' - საგის დახურვა.
Saga „deposit“: „authorize - capture - credit“ კომპენსაციით უარი თქვას.
Saga „refund/payout“: 'request - წყალქვეშა - settled/failed' განმეორებით და ბაბუით.
8) რეკონსტრუქცია (კრიკეტი) - ფულის კონტროლის გული
8. 1 ყოველდღიური შერიგება
მიიღეთ PSP პასპორტის ანგარიში (მერჩანტი/თარიღი/ვალუტით).
შედარება პლატფორმის რეესტრთან: 'intents/captures/refunds/payouts' - 'wallet entries'.
კატეგორიული:- match: ყველაფერი კარგადაა, timing: შეფერხება missing _ psp: არსებობს პლატფორმა, PSP არ არსებობს, missing _ platform: PSP- ში არის, პლატფორმაში არა, amount _ mismatch: თანხის განსხვავება/ვალუტა/fee.
- ავტო წესები timing, ticets/ესკალაცია mismatch- ისთვის.
8. 2 ტექნიკური პროცესი
მოხსენებები ვრცელდება SFTP/API გრაფიკის მიხედვით (retrai + მთლიანობის კონტროლი).
პარსინგი - დეტერმინისტული მაპინგი ('psp _ ref', 'intent _ id', 'capture _ id') ნორმალიზება.
შერწყმა ხორციელდება ინვარიანტებზე OLAP (ClickHouse/BigQuery).
BI ფანჯრები: კონვერტაცია, უარის თქმის მიზეზები, არხების ღირებულება, დახურვის დრო.
8. 3 ალერტა
`% mismatch` > X p. გვ.
9) Chargeback / Dispute
სასიცოცხლო ციკლი: notification - evidence - representment - arbitration.
შეინახეთ evidence პაკეტები (KYC, IP/ASN, Device, 3-DS შედეგები, sage-logs).
მჭიდრო კავშირი risk/anti-fraud- სთან: ბარათის/მოწყობილობების ბარები/ASN როუტინგის დონეზე.
KPI: win-rate, cost-to-serve, time-to-close.
10) ტელემეტრია და SLO
p95 ავტორიზაცია: 3 გვ, p99: 6-8 წმ (დამოკიდებულია 3-DS/ბანკებზე).
Deposit success rate geo/PSP: target 85% (რეალისტური სახელმძღვანელო).
ჩანაწერი: ანგარიში დახურულია T + 1 დღეს; დაუჯერებელი aging Refund turnaround: T + 1 გაგზავნისთვის, T + 5 ჩარიცხვისთვის (სქემის მიხედვით). მეტრიკა: error-rate კოდებით, 3-DS/AVS, decline-matrix (ბანკი/კოდი), cost per success, webhook-lag, retry storms. 11) უსაფრთხოება და შესაბამისობა mTLS PSP + OAuth2/მოთხოვნის ხელმოწერები; გასაღებები/სერთიფიკატები per brand/region. PCI DSS: PAN ტოქსიკაცია, არასოდეს შეინახოთ CVV, ზონების სეგმენტი. WORM აუდიტი: Crition refund/void, მერჩანტის ცვლილება. RG/AML: ფეხები capture/payout- ის წინ; Salk ფურცლები/REP; SAR/STR მოხსენება. PII რეზიდენტობა: რეგიონში ლოგები/მოხსენებები; RLS/შენიღბვა BI- ში. 12) დაკვირვება და ჟურნალისტიკა სტრუქტურირებული ლოგოები (JSON) 'trace _ id', 'psp _ ref', 'intent _ id/capture _ id/refund _ id', კოდი და ხანგრძლივობა. OpenTelemetry HTTP/gRPC/DB/რიგებში; შეცდომების/ფულადი ანომალიების 100%. დაშბორდები NOC: კონვერტაცია არხებით, p95, კოდების უარყოფა, webhook-lag, DLQ. 13) ქაოსი და DR პრაქტიკა PSP- ის დაცემა: ავტო კასკადი/„ ახალი captures “. ვებჰუკების შეფერხება: დედაპლატი + ხელახალი შერიგება pull-API- ის საშუალებით. Out-of-order: idempotence და სტატუსის მანქანა პლატფორმაზე. რეგიონალური გარედან: აქტივი/აქტივი, RPO - 5 წთ, RTO - 30 წთ 14) ჩეკის ფურცლები გამეორება უსაფრთხოა; იდემპოტენტურობის გასაღებები დოკუმენტირებულია. 15) ანტი-ნიმუშები (წითელი დროშები) ბალანსი იცვლება PSP ვებჰუკის საშუალებით, საფულეში აშკარა ბრძანების გარეშე. არ არსებობს იდემპოტენტურობა - ორმაგი ჩამოწერა/სესხი. ინტეგრირებული სალარო iFrame თამაშების პროვაიდერის შიგნით (RG/AML/ტელემეტრიული კონტროლის დაკარგვა). საერთო სავაჭრო გასაღებები რამდენიმე ბრენდისთვის/რეგიონისთვის. T + 1 კრიკეტის არარსებობა, სახელმძღვანელო Excel შედარება. BI/მარეგულირებელი ანგარიშები პირდაპირ OLTP სალაროდან. 3-DS/AVS- ის შეცდომები არ არის ლოგიკური/ანალიზირებული. Webhuks Windows Windows/Windows Window მონაცემთა ბაზაში გადახდის/ბალანსის სტატუსის ხელით რედაქტირება. 16) შედეგი 1. Idempotent ფულადი ბრძანებები და საგნები (authorize/capture/refund/payout). 2. Routing და PSP კასკადები 3-DS/AVS/velocity და რეალური ტელემეტრია. 3. ყოველდღიური შერიგება (აღრიცხვა) და განსხვავებების მკაცრი აღრიცხვა. 4. უსაფრთხოება და შესაბამისობა (mTLS, ხელმოწერები, PCI, RG/AML, WORM). ამ საფუძვლების აგებით, პლატფორმა ზრდის დეპოზიტების კონვერტაციას, ამცირებს დუბლებისა და ჩარჟბეკების რისკებს და თავდაჯერებულად გადის აუდიტს - თუნდაც ტრაფიკის მწვერვალში და გარე პროვაიდერების წარუმატებლობის შემთხვევაში.
პლატფორმა/ოპერატორი
PSP ინტეგრაცია/ბილეთის ოფისის უკანა პლანზე