Როგორ არის მოწყობილი გადახდის სისტემების ინტეგრაცია

გადახდები არის ონლაინ კაზინოს „აორტა“. გადახდის პროვაიდერებთან ინტეგრაციის (PSP) ინტეგრაცია დამოკიდებულია პირველ დეპოზიტზე გადაქცევაზე, გაყვანის სიჩქარეზე, ჩანგლების წილზე, საპორტო დატვირთვაზე და რეგულატორის რეპუტაციაზე. ქვემოთ მოცემულია პრაქტიკული რუკა: რომელი კომპონენტებია საჭირო, როგორ მიედინება მოთხოვნა, სად უნდა დააყენოს დაცვა და რა უნდა ითვალოს.

1) გადახდის მიკროსქემის არქიტექტურა

ძირითადი ბლოკები:

სალარო (Checkout UI): მეთოდის/ვალუტის/თანხის არჩევანი, 3DS/SCA, სტატუსები, შეცდომები.
გადახდის კარიბჭე: PSP- ის მარშრუტი წესების შესაბამისად (ქვეყანა, ვალუტა, რისკი, ღირებულება).
საფულე (PAM/Wallet): ბალანსის აღრიცხვა, RG ლიმიტები, გარიგებები 'debit/credit'.
ანტიფროდი/AML: ოპერაციის ესკიზი ავტორიზაციის დაწყებამდე და მის შემდეგ.
ვებჰუკი: დასტურდება საბოლოო სტატუსებით.
Billing/Reconciliation: ფულის ყოველდღიური დამთხვევა PSP- ში და საფულეში.
ტოქსინების საცავი: ბარათები/საფულეები PSP- ის ტოქსიკაციის გზით, „ნედლეული“ PAN- ის გარეშე.

მარშრუტიზაცია რამდენიმე PSP- ზე:

წესები ქვეყნის/ბანკების/ვალუტის/ლიმიტების, A/B ხაზების, დეგრადაციის დროს ავტომატური ფეილოვერის შესახებ.

2) „დეპოზიტის“ და „გაყვანის“ ნაკადები (სქემები)

ანაბარი (ბარათი/საფულე/ბანკინგი):

1. 'POST/payments/init- მა შექმნა განზრახვა (amount, currency, method).

2. Redirect/SDK/3DS/SCA/ბიომეტრია.

3. PSP უბრუნებს წინასწარი სტატუსს (authorized/pending/failed).

4. Webhook PSP - საბოლოო სტატუსი (captured/failed).

5. 'wallet/credit' ფინალში + RG/ისტორიის ლიმიტების ჩაწერა.

დასკვნა:

1. 'POST/payouts/init' - ვაზის/ლიმიტის/რისკის შემოწმება.

2. PSP- ში პაუზის წამოწყება (იდეალურად - იგივე მარშრუტი, როგორც ანაბარი).

3. Webhook PSP → success/failed.

4. 'wallet/debit' in success, უარის თქმის მიზეზების ჟურნალი, მოთამაშის შეტყობინება.

3) Idempotence და ფულის კავშირი

თითოეული ზარი არის 'Idempotency-Key' და უნიკალური 'txn _ id'.

ანაბრები/დასკვნები ბალანსს მხოლოდ ერთხელ ცვლის - საბოლოო webhook- ის მიხედვით.

ნებისმიერი მოთხოვნის გამეორება უბრუნდება იგივე 'txn _ id' და სტატუსს.

თამაშებთან ერთად: 'round _ id' '' debit _ txn _ id '/' credit _ txn _ id '.

4) უსაფრთხოება და შესაბამისობა

TLS 1. 2+/1. 3, HSTS; webhooks HMAC ხელმოწერით და anti replay ('timestamp', nonce).

Tokenization ბარათები PSP- ზე; PCI DSS scope შემცირება (hosted fields/pages).

SCA/3DS2 ბარათებისთვის, PSD2/Open Banking Pay-by-Bank- ისთვის.

GDPR: PII- ის შემცირება, რენტგენიზაცია, DSR პროცესები; პროფილების წვდომის ჟურნალი.

mTLS/IP ალოუ-სია PSP- სთან კავშირებისთვის, გადახდის მიკროსქემის სეგრეგაცია.

5) ანტიფროდი და AML (გადახდამდე და მის შემდეგ)

Pre-auth წესები: geo/ASN, მოწყობილობა, velocity, ქცევა, „pass-through“.

ML Scoring/გრაფიკი: ზოგადი ბარათები/საფულეები/მოწყობილობები, განმეორებითი chargeback.

Post-auth მონიტორინგი: გაუქმება, გადახდა, სწრაფი გაყვანა.

AML სცენარები: ბარიერები, სტრუქტურა, უჩვეულო მარშრუტები, STR/SAR მოხსენებები.

Step-up KYC: დაწყებამდე საშუალო/მაღალი რისკით.

6) ვებჰუკი: საიმედო მიწოდება

HMAC ხელმოწერა, გადამოწმება 'timestamp' და 'event _ id' დედაპლიკაცია.

Retrai PSP მხარეს არის idempotent.

მიწოდების ლოგოები (success/fail), dead-letter queue და სახელმძღვანელო „replay“.

Webhook არ ცვლის ბალანსს, თუ თანხა/იდენტიფიკატორი არ ემთხვევა.

7) შეცდომები და ტაიმაუტები: პასუხების დიზაინი

კოდები: '402', '409' (იდემპოტენტური კონფლიქტი), '422' (შესაბამისობა), '429' (ვარდნა-ლიმიტი), '5xx' (ინციდენტი).

შეცდომების სხეულები: 'error', 'მესიჯი', 'trace _ id', 'details {...} "- ეხმარება საფოსტო და ალერტებს.

Graceful retry კლიენტზე (ექსპონენციალური bacoff), მკაფიო რჩევები UI- ში.

8) Routing და failover რამდენიმე PSP

ხარისხის წესები: p95 ავტორიზაცია, კონვერტაცია, 3DS ყალბი წილი, ღირებულება.

ჭკვიანი როუტერი: როდესაც მეტრიკა გაუარესდება, არის ტრეფიკის გადაცემა ალტერნატივაზე.

Sticky მარშრუტი სხდომაზე/ბანკში 3DS სტაბილურობისთვის.

დეგრადაციის გეგმა: „მძიმე“ მეთოდების გამორთვა, სწრაფი (P2P/Pay-by-Bank) დატოვება, დასკვნების ხაზი.

9) ჭარხალი და ფინანსები (რეკონსტრუქცია)

PSP- ის ყოველდღიური გადმოტვირთვა და მანქანის გადამზიდავი საფულესთან: თანხების, საკომისიოს, დაბრუნების დამთხვევა.

შეუსაბამობები - გამოძიების შემთხვევები.

ცალკეული მოხსენებები chargeback/refund/fees, ჭეშმარიტი ზღვრის გაანგარიშება მეთოდების მიხედვით.

10) მეტრიკები, რომლებიც ყურადღების ცენტრში უნდა იყოს

ანაბრის კონვერტაცია მეთოდით/ბანკში/ქვეყანაში/სტრუქტურაში.

ანაბრის/გამომავალი დრო (p50/p95).

3DS fails- ის წილი, გაუქმება, დაბრუნება, chargeback rate.

Review და TTV KYC.

Uptime PSP და საკუთარი error-rate მარშრუტებზე.

Cost per success და ROI მეთოდების მიხედვით.

11) მინიმალური API- ს მაგალითი (შემოკლებით)

ანაბრის განზრახვის შექმნა

`POST /v1/payments/init`

json
{
"amount":"50. 00",  "currency":"EUR",  "method":"card",  "return_url":"https://app. example. com/checkout/return",  "idempotency_key":"b6a1-…",  "meta":{"country":"FI","device":"ios"}
}

პასუხი

json
{"payment_id":"pay_123","status":"pending","redirect_url":"https://psp. example/3ds/…"}

Webhook სტატუსი

`POST /v1/payments/webhook` + `X-Signature: sha256=…`

json
{
"event_id":"evt_789",  "payment_id":"pay_123",  "status":"captured",  "amount":"50. 00",  "currency":"EUR",  "timestamp":"2025-10-17T09:41:00Z"
}

ჩარიცხვის ჩატარება (პლატფორმის შიგნით)

`POST /v1/wallet/credit`

json
{"payment_id":"pay_123","txn_id":"txn_555","amount":"50. 00","idempotency_key":"b6a1-…"}

12) ხელმისაწვდომობა და UX სალარო

მინიმალური ნაბიჯები: ქვეყნის auto-detect/ვალუტა, შენახული მეთოდების ნიშნები.

ადგილობრივი მეთოდები: საბანკო ღილაკები, ელექტრონული ვალეტები, Apple/Google Pay.

გამჭვირვალობა: საკომისიო/გამომავალი, ოპერაციის სტატუსი, გასაგები შეცდომები.

წვდომა: დიდი ელემენტები, კონტრასტი, ეკრანული მიმღები, მრავალენოვანი.

13) DR/BCP და ოპერაციების უსაფრთხოება

გადახდის ჟურნალების რეპლიკაცია, დაშიფვრის ზურგჩანთები, კვარტალური DR სავარჯიშოები.

RPO/RTO დოკუმენტირებულია, რომ PSP- ის ჩავარდნის დროს „დაგვიანებული“ გადახდები.

WAF/bot მენეჯმენტი სალაროებში, მაგრამ გამონაკლისი რედუქტორებისთვის/SDK PSP.

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

ბალანსი იცვლება webhook-duble/rassinhron ფინალამდე.

არა 'Idempotency-Key' - ქსელის გაუმართაობის განმეორება ქმნის მეორე ოპერაციას.

Webhook- ის ხელმოწერის სუსტი შემოწმება სტატუსის შეცვლის შესახებ.

PSP- სთან მანქანის სერვერის არარსებობა არის „მშვიდი განსხვავებები“.

ერთი PSP „ყველაფრისთვის“ მარტივია და დეგრადაციის დროს კონვერტაციის დაკარგვა.

3DS/მისამართის ველების შესაბამისობა „შოუსთვის“ არის ჩარჟბეკების ზრდა.

15) განხორციელების შემქმნელი (შენახვა)

Multi-PSP Router, ხარისხის წესები, failover
პირადობის მოწმობა თითოეულ ფენაზე ('txn _ id', 'Idempotency-Key')
Webhooks: HMAC, anti replay, მიწოდების ლოგოები, დედაპლაცია
Tokenization/hosted fields, PCI DSS scope შემცირება
3DS2/SCA, PSD2/Open Banking სადაც შესაძლებელია
ანტიფროდი/AML გადახდამდე და მის შემდეგ, step-up KYC
მანქანის სერვერი PSP ანგარიშები, შეუსაბამობების ანალიზი
დაკვირვება: p95 ანაბარი/გამომავალი, 3DS fail-rate, uptime PSP
DR გეგმა, გადავადებული გადახდები, ჟურნალების ზურგჩანთები
UX სალაროები: ადგილობრივი მეთოდები, გამჭვირვალე ETA/საკომისიო, წვდომა

კარგი გადახდის ინტეგრაცია არ არის „SDK დაკავშირება“, არამედ სტაბილური წრის შექმნა: Multi-PSP მარშრუტიზაცია, მკაცრი idempotence, ხელმოწერილი webhooks, ანტიფროდი/AML, მანქანის გადამზიდავი და დაკვირვება. ასეთი დასტის გაზრდა ზრდის კონვერტაციას, აჩქარებს დასკვნას, ამცირებს ჩარჟბეკების რისკებს და პლატფორმას პროგნოზირებს მოთამაშეთა, პარტნიორებისა და რეგულატორებისთვის.