Крипто казино
Torrent Gear
Провайдерлерден API төлөмдөр кандай иштейт
Төлөм API - бул сиздин тиркемеңиз менен провайдердин ортосундагы келишим, ал "төлөмдү түзүңүз", "3DS тастыктаңыз", "каражатты кайтарып бериңиз", "кардарга төлөңүз" жана "статус алыңыз" деген ишенимдүү, кайталанма чакырыктарга айланат. Капоттун астында - ондогон эрежелер: токенизация, idempotency, webhuke, антифрод, кезек, SLA жана аудит. Төмөндө - бул көпчүлүк провайдерлер үчүн кандай уюштурулганынын практикалык картасы.
Базалык модели: кандай нерселер дээрлик дайыма бар
Payment/Charge - эсептен чыгаруу аракети (authorize + capture же дароо purchase).
Payment Method - карта (PAN/token), банк эсеби/alias, капчык, жергиликтүү ыкма.
Customer - кардардын/төлөөчүнүн маңызы (кээде милдеттүү эмес).
Payout/Transfer - кардарга/соодагерге чыгуучу төлөм.
Refund/Reversal - баштапкы төлөмгө кайтаруу (closed-loop).
Webhook Event - статус жөнүндө асинхрондук билдирүү.
Dispute/Chargeback - төлөм тармагы боюнча талаш-тартыш (карталар үчүн).
Order/Invoice - төлөм айланасында бизнес контексти.
Аутентификация жана коопсуздук
API-ачкычтар/OAuth 2. 0/mTLS - Server үчүн.
Кардарлардын токендери - frontend үчүн бир жолу колдонулуучу токендер (сырларды жаркырабашы үчүн).
Карталарды токендештирүү - PAN провайдерге барат; Сиз токенди гана сактайсыз.
PCI DSS - Сиз PAN көрүп, анда сиз PCI зонасында болуп саналат; качуу жана hosted талаасын/SDK колдонуу жакшы.
HMAC кол Webhook - окуя жөнөтүүчүдөн келген текшерүү.
Эки зоналуу архитектура - коомдук фронт (JS/SDK) жана жеке бэкенд (ачкычтар, тобокелдик-логика).
Idempotency, кезек жана ырааттуулук
Idempotency-Key аталышында: суроонун кайталанышы (таймаутта) дубликатты түзбөйт.
Outbox/Сага сизде: "төлөмдөрдү жөнөтүү → жаздыруу → күтүү вебхук" макулдашылган.
backoff менен Retray - убактылуу каталар үчүн гана. Matrix retryable/non-retryable - милдеттүү.
Типтүү эндпоинттер (схемалар жана флоу)
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 күтүп.
Таймауттар жана кодго TTL - келишимдин бир бөлүгү.
4) Төлөмдөр (payouts)
POST /payouts (`amount`, `currency`, `destination_token` или `card_token`/`bank_alias`).
GET /payouts/{id} — статусы (`queued`, `sent`, `paid`, `failed`).
Webhook 'payout. paid/failed '- чындыктын булагы.
Жабык Loop: артыкчылыктуу булагы боюнча төлөө (кайра) чейин альтернатива.
Webhuke: "чындыктын булагы"
Окуялар: 'payment. pending/authorized/captured/failed`, `payment. requires_action`, `refund. succeeded`, `payout. paid`, `dispute. created 'ж.б.
Жеткирүү: HMAC тарабынан кол коюлган retrains менен, көп учурда "жок дегенде бир жолу" → иштетүүчүнүн боштугун сактап.
Best practice: WebHook иштетүү → Ledger жаңыртуу → жооп 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 клиринг (сумманын жылышы мүмкүн), 3DS2, баштапкы операция боюнча кайтарымдар, талаш-тартыштар/чарджбэк.
A2A/Open Banking: redirect/consent-flow, жогорку апрув, төмөн наркы; баары асинхрондук жана банкка көз каранды.
Жергиликтүү тез: QR/alias, заматта webhuk, TTL жана катуу жыйындысы.
OCT/Push-to-Card (картага төлөмдөр): Бизге карта токендери керек, эмитенттен Fast Funds колдойт, 3DS жок.
Версиялоо жана шайкештик
API версиялары: '/v1 ', "дата-версия" аталышында же phicheflags.
Backwards-compatible өзгөрүүлөр: гана жок талаалар.
Депрекациялар: эски версияларды чыгаруу графиги, миграциялык гайддар, миграция учурунда вебхуктардын дубликаты.
Байкоо жана SLA
Метрика: p95 авторизациялоо/төлөө убактысы, BIN/банк/ыкма боюнча апprove rate, ретрациялардын үлүшү, веб-хаки-лаг.
Логи: 'request _ id', 'idempotency _ key', 'payment _ id' боюнча корреляция.
Алерталар: белгилүү бир банк/өлкө боюнча баш тартуулардын көбөйүшү, таймаштардын өсүшү, окуялардын дубликаттары.
Бириктирүү жана финансы
Менеджер: кош жазуу, өзгөрүлбөс журналдар, статустар 'authorized/captured/refunded'.
Үч тараптуу жыйындысы: Сиздин леджер, вебхук, провайдер/банк отчеттору.
Referents: 'provider _ reference', 'network _ reference', 'payout _ reference' сактаңыз - бул саппортту сактап калат.
Sandbox, күбөлүк жана буюмдар
Sandbox: тесттик токендер/карталар/банктар, 3DS/редакторлордун симуляциясы, вебхук статустары үчүн "баскычтар".
Тест учурлары: ийгилик/ийгиликсиздик, 3DS challenge, провайдердин тайм-аут, вебхуктун кайталанышы, жарым-жартылай capture/refund, редакторду жокко чыгаруу, payout fail.
Go-live: прод ачкычтары, вебхук домендери, 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"}}
}Төлөм (payout)
POST /v1/payouts
{
"amount": 5000, "currency": "EUR", "destination_token": "dest_tok_456", "metadata": {"user_id":"u_77"}
}Киргизүүнүн чек-тизмеси
1. Ачкычтардын архитектурасы: сервердик сырлар өзүнчө, кардарлар - бир жолу колдонулуучу.
2. Idempotency: ар бир write-чакырууда + демпотенттик вебхук иштеп чыгуучулар.
3. Вебхактар: HMAC кол тамгасы, ретра, тапшырмалардын кезеги, лагдардын мониторинги.
4. 3DS/SCA жана редакторлор: кайра иштетүү/убакыт, frendley-UX кайталап аракет.
5. Антифрод/лимиттер: velocity, жаңы реквизиттер, кара тизмелер, RG/AML босоголору.
6. Леджер жана жыйындысы: кош жазуу, үч тараптуу салыштыруу, аномалиялардын алерттери.
7. Оркестр: запастык провайдер, BIN/өлкө/сумма боюнча роутинг эрежелери.
8. Мониторинг: dashboard approve rate/p95/retrais, банктар/ыкмалар боюнча алерт.
9. Юридикалык/PCI: tokenization, кайтаруу саясаты, жабык илмек payouts.
10. Деградация планы: kill-switch канал, кезек, оор иш үчүн кол режими.
Көп каталар
PAN PCI жана tokenization жок өз тарабында сактоо.
Тайм-аут учурунда idempotency → эки төлөмдөр/төлөмдөр жок.
Вебхуктарды эсепке албаганда синхрондуу жооптордун логикасы.
fallback/каскаддар жок, рынокто бир провайдер.
Жок 3DS жокко чыгаруу/редактору → жоголгон себет.
алсыз жыйындысы → "илинип" жана "жоголгон" бүтүмдөр.
Так SLA жана alerts жоктугу → көйгөйдү кардар көрүп, сен эмес.
Mini-FAQ
Кайсы ишенимдүү: синхрондуу статусу же Webhook?
Вебхук - чындыктын булагы; синхрондуу жооп - бир гана "кабыл алынган/зарыл иш-аракет".
3DS жок кыла алат?
Жөнгө салуудан/тобокелдиктен көз каранды. EC/UK - SCA милдеттүү; жогорку тобокелдик үчүн жакшы кадам.
Кантип prove rate жогорулатуу керек?
BIN/банк/ыкмасы, жергиликтүү рельстер, акылдуу ретрациялар, туура дескрипторлор, төмөн FPR менен антифрод.
Эмне үчүн payout "заматта эмес"?
Рельстен (ОСТ/А2А/жергиликтүү), алуучунун банкынан жана лимиттерден көз каранды. Келгиле, чынчыл SLA терезени жана статус агымын берели.
API төлөмдөр - бул "төлөм түзүү" гана эмес. Бул дисциплина: коопсуз аутентификация → токенизация → idempotency → асинхрондук вебхактар → леджер жана жыйындылар → антифрод/AML → оркестрлөө жана мониторинг. Бул схема боюнча процессти куруңуз, резервдик каналдарды жана тунук UX сактаңыз - жана сиздин төлөм катмарыңыз тез, алдын ала айтууга боло турган жана банктардын жана провайдерлердин бузулушуна туруктуу болот.