Კრიპტო კაზინო
Torrent Gear
Როგორ მუშაობს API გადახდები პროვაიდერებისგან
გადახდის API არის ხელშეკრულება თქვენს აპლიკაციასა და პროვაიდერს შორის, რომელიც გადააქცევს „გადასახადის შექმნას“, „დაადასტუროს 3DS“, „დააბრუნოს თანხები“, „გადაიხადოს კლიენტი“ და „მიიღოს სტატუსი“ საიმედო, განმეორებით გამოწვევებად. ქუდის ქვეშ - ათობით წესი: ტოქსიკაცია, იდემპოტაცია, ვებჰუკი, ანტიფროდი, ხაზი, SLA და აუდიტი. ქვემოთ მოცემულია პრაქტიკული რუკა, თუ როგორ არის მოწყობილი ეს პროვაიდერების უმეტესობა.
ძირითადი მოდელი: რა არსებები არსებობს თითქმის ყოველთვის
Payment/Charge - ჩამოწერის მცდელობა (authorize + capture ან დაუყოვნებლივ purchase).
Payment Method - ბარათი (PAN/token), საბანკო ანგარიში/alias, საფულე, ადგილობრივი მეთოდი.
Customer არის კლიენტის/გადამხდელის არსი (ზოგჯერ არჩევითი).
Payout/Transfer - გადახდა კლიენტს/მერკანტს.
Refund/Reversal - თავდაპირველი გადახდის დაბრუნება.
Webhook Event - სტატუსის ასინქრონული შეტყობინება.
Dispute/Chargeback - დავა გადახდის ქსელზე (ბარათებისთვის).
Order/Invoice - ბიზნეს კონტექსტი გადახდის გარშემო.
ავთენტიფიკაცია და უსაფრთხოება
API გასაღებები/OAuth 2. 0/mTLS - სერვერისთვის.
კლიენტის ნიშნები - ერთჯერადი ნიშნები წინა ხაზისთვის (ისე, რომ არ ანათებდეს საიდუმლოებები).
ბარათების ტოქსიკაცია - PAN მიდის პროვაიდერზე; თქვენ მხოლოდ ნიშანს ინახავთ.
PCI DSS - თუ PAN ხედავთ, PCI ზონაში ხართ; უმჯობესია თავიდან აიცილოთ და გამოიყენოთ მასპინძელი ველები/SDK.
HMAC ვებჰუკების ხელმოწერა - შემოწმება, რომ ღონისძიება პროვაიდერისგან მოვიდა.
ორმაგი ზონის არქიტექტურა - საზოგადოებრივი ფრონტი (JS/SDK) და პირადი ზურგჩანთა (გასაღებები, რისკის ლოგიკა).
Idempotence, რიგები და კოორდინაცია
Idempotency-Key სათაურში: მოთხოვნის გამეორება (ტაიმაუტით) არ ქმნის დუბლიკატს.
თქვენ გაქვთ Outbox/Saga: ისე, რომ „გაგზავნოთ გადახდა, ჩაწერა ლეჯერში და დაელოდოთ ვებჰუკს“.
backoff retrais მხოლოდ დროებითი შეცდომებისთვის. retryable/non-retryable მატრიცა სავალდებულოა.
ტიპიური endpoints (სქემები და flow)
1) ბარათები (Visa/Mastercard და ა.შ.)
POST/payments - შექმნას გადახდა ('amount', 'currency', 'payment _ method _ token', 'capture' = false/true).
POST /payments/{id}/confirm — шаг 3-D Secure 2 (challenge/redirect result).
POST/payments/{ id }/capture - დაჭერა ავტორიზაციის შემდეგ (ნაწილობრივი/სრული).
POST/payments/{ id/refund - დაბრუნება (ნაწილებად, საწყისი ოდენობით).
GET /payments/{id} — статус (authorized, captured, failed, requires_action).
3-D Secure/SCA: პროვაიდერი დააბრუნებს 'requires _ action' + 'client _ secret '/URL challenge. კლიენტის დადასტურების შემდეგ, ფრონტი შედეგს დაუბრუნებს თქვენს ზურგჩანთას - თქვენ იძირებით '/confirm '.
2) A2A / Open Banking (Pay by Bank)
POST/payments არის პასუხი 'redirect _ url' კლიენტის ბანკში.
კლიენტი უფლებამოსილია ბანკში webhook 'payment. succeeded/failed`.
GET/payments/{ id} - საბოლოო სტატუსი (ხშირად მხოლოდ ასინქრონულად).
3) ადგილობრივი მეთოდები (PIX, PayID, FPX, iDEAL და ა.შ.)
POST/payments- ს მიიღებთ 'qr _ code '/' deeplink '/' copy _ code'.
თქვენ აჩვენებთ მომხმარებელს, ელოდებით webhook- ს ჩარიცხვის შესახებ.
Taimauts და TTL კოდი არის ხელშეკრულების ნაწილი.
4) გადახდა
POST /payouts (`amount`, `currency`, `destination_token` или `card_token`/`bank_alias`).
GET /payouts/{id} — статусы (`queued`, `sent`, `paid`, `failed`).
ვებჰუკი 'payout. paid/failed '- სიმართლის წყარო.
დახურული მარყუჟი: სასურველია გადაიხადოთ წყაროზე ალტერნატივა.
ვებჰუკი: „ჭეშმარიტების წყარო“
მოვლენები: 'payment. pending/authorized/captured/failed`, `payment. requires_action`, `refund. succeeded`, `payout. paid`, `dispute. created 'და ა.შ.
ადგილზე მიტანა: HMAC- ის მიერ ხელმოწერილი თხრილებით, ხშირად „ერთხელ მაინც“ - შეინარჩუნეთ დამუშავების imppotence.
საუკეთესო practice: დაამუშავეთ webhuk, განაახლეთ გამყიდველი და უპასუხეთ 2xx. შემდეგ ნებისმიერი ბიზნეს ლოგიკა ასინქრონულია.
შეცდომებისა და სტატუსის დამუშავება
HTTP კოდები: '2xx' წარმატება; '4xx' კლიენტის შეცდომა (შესაბამისობა, ფროიდი/ბანკის უკმარისობა, არასწორი ნიშანი); '5xx' - პროვაიდერი.
Причины отказов: `insufficient_funds`, `do_not_honor`, `stolen_card`, `limit_exceeded`, `risk_decline`, `bank_unavailable`.
გამეორების ფანჯრები: 3DS- სთვის - შეუძლებელია უსასრულოდ გადატვირთვა; A2A- სთვის - TTL რედირექტირება/კოდი; payouts- ისთვის - backoff.
ანტიფროდი და რისკი
Device-fingerprinting და ქცევითი მონაცემები - JS/SDK პროვაიდერის ან თქვენი საკუთარი ფენის მეშვეობით.
სიები: BIN რისკი, მეთოდების შავი/თეთრი სიები/ASN/ქვეყნები.
რეგულირებული კარიბჭეები: ახალი ინსტრუმენტების ლიმიტები, „cool-off“, velocity, RG/AML ბარიერი შემოწმება.
პოლიტიკოსები: 'pass/step-up/hold/block', რომელიც დაფუძნებულია სკორპინგზე + წესებზე.
რელსების მახასიათებლები
ბარათები: ნებართვა vs cliring (თანხის შეცვლა შესაძლებელია), 3DS2, გადახურვა თავდაპირველი ოპერაციისთვის, დავები/ჩარდბეკი.
A2A/Open Banking: redirect/consent flow, მაღალი აფროვი, დაბალი ღირებულება; ყველაფერი ასინქრონულია და ძალიან არის დამოკიდებული ბანკზე.
ადგილობრივი სწრაფი: QR/alias, მყისიერი ვებჰუკი, TTL და მკაცრი შედუღება.
OCT/Push-to-Card (ბარათზე გადახდა): თქვენ გჭირდებათ ბარათის ნიშნები, ემიტენტისთვის Fast Funds- ის მხარდაჭერა, 3DS- ის გარეშე.
ვერსია და თავსებადობა
API ვერსიები: '/v1 ', „მონაცემთა ვერსიები“ სათაურით ან ფიჩეფლაგით.
Backwards-compatible ცვლილებები: მხოლოდ არა დესტრუქციული ველები.
დეპრესიები: ძველი ვერსიების გაყვანის გრაფიკი, მიგრაციის ჰაიდები, ვებჰუკების დუბლიკატი მიგრაციის დროს.
დაკვირვება და SLA
მეტრიკა: p95 დრო ავტორიზაციის/გადახდის, approve rate BIN/Bank/მეთოდით, retrays- ის წილი, ვებჰუკი-ლაგი.
Logs: კორელაცია 'request _ id', 'idempotency _ key', 'payment _ id'.
ალერტები: კონკრეტული ბანკის/ქვეყნის უარის თქმის ზრდა, ტაიმაუტის ზრდა, მოვლენების დუბლიკატები.
სვერკა და ფინანსები
ლეჯერი: ორმაგი ჩანაწერი, უცვლელი ჟურნალები, სტატუსები 'authorized/captured/refunded'.
სამმხრივი შედუღება: თქვენი დამსაქმებელი - ვებჰუკი - პროვაიდერის/ბანკის მოხსენებები.
რეფერენდუმები: შეინახეთ 'provider _ reference', 'ქსელი _ reference', 'payout _ reference' - ეს დაზოგავს sport.
Sandbox, სერტიფიკაცია და პროდი
Sandbox: ტესტის ნიშნები/ბარათები/ბანკები, 3DS/რედაქციის სიმულაცია, „ღილაკები“ ვებჰუკის სტატუსებისთვის.
ტესტის შემთხვევები: წარმატება/უარყოფა, 3DS გამოწვევა, პროვაიდერის ტაიმუტი, ვებჰუკის დუბლიკატი, ნაწილობრივი capture/refund, რედაქციის გაუქმება, payout fail.
Go-live: prod გასაღებები, ვებჰუკების დომენები, IP-allowlist, ჩართეთ ანტიფროზი, მიუთითეთ ლიმიტები და ალერტები.
მინი მაგალითები (სქემატურად)
შექმნა გადახდა (ბარათი)
POST /v1/payments
{
"amount": 9232, "currency": "EUR", "payment_method_token": "pm_tok_123", "capture": true, "metadata": {"order_id": "ORD-1001"}
}
→ 200 { "id": "pay_abc", "status": "requires_action", "next_action": {"type":"redirect", "url":"..."} }ვებჰუკი წარმატებული ჩარიცხვის შესახებ
POST /webhooks
{
"type": "payment. captured", "data": {"id":"pay_abc","amount":9232,"currency":"EUR","metadata":{"order_id":"ORD-1001"}}
}გადახდა
POST /v1/payouts
{
"amount": 5000, "currency": "EUR", "destination_token": "dest_tok_456", "metadata": {"user_id":"u_77"}
}განხორციელების შემოწმების სია
1. გასაღების არქიტექტურა: სერვერის საიდუმლოებები ცალკე, კლიენტი - ერთჯერადი.
2. Idempotence: თითოეულ write ზარი + emempotent webhuk.
3. ვებჰუკი: HMAC ხელმოწერა, retrai, დავალებების ხაზი, ლაგების მონიტორინგი.
4. 3DS/SCA და რედაქციები: გაუქმება/ტაიმაუტის დამუშავება, frandle-UX- ის ხელახალი მცდელობა.
5. ანტიფროდი/ლიმიტები: velocity, ახალი დეტალები, შავი სიები, RG/AML ბარიერები.
6. ლეჯერი და კონვერტორი: ორმაგი ჩაწერა, სამმხრივი კრიკეტი, ანომალიების ალერტები.
7. ორკესტრი: სათადარიგო პროვაიდერი, Routing წესები BIN/ქვეყანაში/ჯამში.
8. მონიტორინგი: approve rate/p95/retrais dashbords, ბანკების/მეთოდების ალერტები.
9. ლეგალურად/PCI: ტოკენიზაცია, დაბრუნების პოლიტიკა, დახურული payouts მარყუჟი.
10. დეგრადაციის გეგმა: kill-switch არხი, რიგები, სახელმძღვანელო რეჟიმი კრიტიკული ოპერაციებისთვის.
ხშირი შეცდომები
PAN- ის შენახვა თავის მხარეზე PCI და ტოკენიზაციის გარეშე.
Idempotence- ის არარსებობა - გადახდების/გადახდების დუბლირება ტაიმუთებში.
ლოგიკა სინქრონიზებულ პასუხებზე, ვებჰუკების გამოკლებით.
ერთი მიმწოდებელი ბაზარზე, fallback/კასკადების გარეშე.
არ არის დამუშავებული 3DS/რედირექტის გაუქმება და დაკარგული კალათები.
სუსტი შედედება - „ჩამოკიდებული“ და „დაკარგული“ გარიგებები.
აშკარა SLA და ალერტების ნაკლებობა, კლიენტი ხედავს პრობლემას და არა თქვენ.
Mini-FAQ
რა არის უფრო საიმედო: სინქრონული სტატუსი თუ ვებჰუკი?
ვებჰუკი არის ჭეშმარიტების წყარო; სინქრონული პასუხი - მხოლოდ „მიღებული/საჭიროა მოქმედება“.
შეგიძლიათ გააკეთოთ 3DS- ის გარეშე?
ეს დამოკიდებულია რეგულირებაზე/რისკზე. EC/UK - SCA სავალდებულოა; high-risk- ისთვის უკეთესია, ვიდრე step-up.
როგორ გავზარდოთ approve rate?
ორკესტრი BIN/Bank/მეთოდით, ადგილობრივი რელსები, ჭკვიანი რელსები, სწორი აღწერილობები, ანტიფროდი დაბალი FPR.
რატომ არ არის „მყისიერი“?
ეს დამოკიდებულია სარკინიგზო მაგისტრალზე (OST/A2A/ადგილობრივი), მიმღებისა და ლიმიტების ბანკზე. მოდით გულწრფელი SLA ფანჯარა და სტატუსის ნაკადი.
API გადასახადები არ არის მხოლოდ „გადახდის შექმნა“. ეს არის დისციპლინა: უსაფრთხო ავთენტიფიკაცია - ტოქსიკაცია - idempotence - ასინქრონული ვებჰუკი - ლეჯერი და შედუღება - ანტიფროდი/AML - ორკესტრი და მონიტორინგი. ამ სქემის მიხედვით ააშენეთ პროცესი, შეინახეთ სათადარიგო არხები და გამჭვირვალე UX - და თქვენი გადახდის ფენა იქნება სწრაფი, პროგნოზირებადი და მდგრადი ბანკებისა და პროვაიდერების ჩავარდნების მიმართ.