क्रिप्टो कैसीनो
धार गियर
प्रदाताओं के लिए एपीआई भुगतान कैसे काम करता है
भुगतान एपीआई आपके आवेदन और प्रदाता के बीच एक अनुबंध है जो "भुगतान बनाता है", "पुष्टि करें" "वापसी निधि", "क्लाइंट का भुगतान करें" और विश्वसनीय, दोहराने योग्य कॉल में "स्थिति प्राप्त करें"। हुड के तहत दर्जनों नियम हैं: टोकन, आइडेम्पोटेंसी, वेबहूक, एंटी-फ्रॉड, कतारें, एसएलए और ऑडिटिंग। नीचे एक व्यावहारिक नक्शा है कि यह अधिकांश प्रदाताओं के लिए कैसे काम करता है।
मूल मॉडल: क्या संस्थाएं लगभग हमेशा हैं
भुगतान/प्रभार - लिखने का प्रयास (अधिकृत + कैप्चर या तुरंत खरीद)।
भुगतान विधि - कार्ड (पैन/टोकन), बैंक खाता/उर्फ, बटुआ, स्थानीय विधि।
ग्राहक - ग्राहक/भुगतानकर्ता इकाई (कभी-कभी वैकल्पिक)।- भुगतान/अंतरण - ग्राहक/व्यापारी को निवर्तमान भुगतान।
- रिफंड/रिवर्सल - मूल भुगतान (बंद-लूप) पर लौटें।
- वेबहुक घटना - अतुल्यकालिक स्थिति अधिसूचना।
- भुगतान नेटवर्क (कार्ड के लिए) पर विवाद/चार्जबैक।
- भुगतान के आसपास आदेश/चालान - व्यवसाय संदर्भ।
सत्यापन और सुरक्षा
एपीआई कुंजी/OAuth 2। 0/mTLS - सर्वर-टू-सर्वर के लिए।
क्लाइंट टोकन फ्रंटेंड के लिए डिस्पोजेबल टोकन हैं (ताकि रहस्य को चमकाने के लिए नहीं)।
कार्ड टोकन - पैन प्रदाता के पास जाता है; तुम सिर्फ टोकन जमा करो।
पीसीआई डीएसएस - यदि आप एक पैन देखते हैं, तो आप पीसीआई क्षेत्र में हैं; मेजबान क्षेत्रों/एसडीके से बचना और उपयोग करना बेहतर है।
HMAC हस्ताक्षर वेबहुक - यह जाँचना कि घटना प्रदाता से आई है।- डुअल-ज़ोन आर्किटेक्चर - सार्वजनिक फ्रंट (JS/SDK) और निजी बैकेंड (कुंजी, जोखिम तर्क)।
पहचान, कतारें और स्थिरता
शीर्षिका में Idempotency-Key: अनुरोध को दोहराना (टाइमआउट के साथ) एक डुप्लिकेट नहीं बनाता है.
आपके साथ आउटबॉक्स/सागा: "भुगतान भेजने के लिए - खाते में लिखें वेबहुक की प्रतीक्षा करें" पर सहमति हुई।
बैकऑफ के साथ रिट्राई - केवल अस्थायी त्रुटियों के लिए। रिट्रीबल/नॉन-रिट्रीबल मैट्रिक्स आवश्यक है।
विशिष्ट समापन बिंदु (योजनाएं और प्रवाह)
1) कार्ड (वीजा/मास्टरकार्ड, आदि)
POST/भुगतान - एक भुगतान ('राशि', 'मुद्रा', 'भुगतान _ विधि _ टोकन', 'कैप्चर' = गलत/सही) बनाएं।
POST/भुगतान/{ id }/पुष्टि - шаг 3-D सुरक्षित 2 (चुनौती/पुनर्निर्देशित परिणाम)।
POST/भुगतान/{ id }/कैप्चर - कैप्चर के बाद प्राधिकरण (आंशिक/पूर्ण)।
POST/भुगतान/{ id }/रिफंड - रिटर्न (भागों में, मूल राशि तक)।- GET/भुगतान/{ id} - (अधिकृत, कैप्चर, असफल, ।
3-डी सिक्योर/SCA: प्रदाता चुनौती के लिए 'requires _ acction' + 'क्लाइंट _ सीक्रेट '/URL वापस करेगा। क्लाइंट द्वारा पुष्टि के बाद, फ्रंट आपके बैकएण्ड में परिणाम वापस कर देगा - आप 'पुल/पुष्टि' करते हैं।
2) ए 2 ए/ओपन बैंकिंग (बैंक द्वारा भुगतान)
POST/भुगतान - ग्राहक के बैंक को 'redirect _ url' से प्रतिक्रिया।
ग्राहक बैंक → वेबहुक 'पेमेंट द्वारा अधिकृत है। सफल/असफल '।- GET/भुगतान/{ id} - अंतिम स्थिति (अक्सर केवल अतुल्यकालिक)।
3) स्थानीय तरीके (PIX, PayID, FPX, iDEL, आदि)
POST/भुगतान → 'qr _ code '/' deeplink '/' copy _ code' प्राप्त करें।
उपयोक्ता को दिखाएँ, नामांकन के बारे में वेबहुक की प्रतीक्षा करें.
कोड टाइमआउट और टीटीएल अनुबंध का हिस्सा हैं।
4) भुगतान
POST/payouts ('राशि', 'मुद्रा', 'गंतव्य _ टोकन' или 'कार्ड _ टोकन '/' बैंक _ उर्फ')।
GET/payouts/{ id} - ('पंक्तिबद्ध', 'प्रेषित', 'भुगतान', 'असफल').
Webhooks का payout। भुगतान/विफल 'सत्य का स्रोत है।- बंद लूप: विकल्पों से पहले स्रोत (उलटफेर) का भुगतान करना बेहतर है।
वेबहूक: "सत्य का स्रोत"
घटनाएँ: 'भुगतान। लंबित/अधिकृत/कब्जा/विफल ',' भुगतान। requires_action', 'रिफंड। सफल ',' भुगतान। भुगतान ',' विवाद। बनाया ', आदि।
डिलीवरी: एचएमएसी द्वारा हस्ताक्षरित रिट्रीज़के साथ, अक्सर "कम से कम एक बार" - हैंडलर आइडेम्पोटेंट रखें।
सर्वश्रेष्ठ अभ्यास: वेबहुक की प्रक्रिया करें → लेजर को अपडेट करें → 2xx का जवाब दें। इसके बाद कोई भी व्यावसायिक तर्क अतुल्यकालिक है।
त्रुटि और स्थिति प्रक्रमण
HTTP कोड: '2xx' सफलता; '4xx' क्लाइंट त्रुटि (सत्यापन, धोखाधड़ी/बैंक विफलता, गलत टोकन); '5xx' - प्रदाता।
Причины отказов: 'अपर्याप्त _ फंड्स', 'do _ non _ honour', 'चोरी _ कार्ड', 'सीमा _ पार', 'जोखिम _ dinque', 'बैंक _ अनुपलब्ध'।
रिडो विंडो: 3DS के लिए - आप अंतहीन रूप से वापस नहीं ले सकते; A2A के लिए - पुनर्निर्देशित/कोड TTL मान्य हैं; भुगतान के लिए - बैकऑफ।
एंटीफ्राड और जोखिम
डिवाइस-फिंगरप्रिंटिंग और व्यवहार डेटा - प्रदाता के जेएस/एसडीके या आपकी अपनी परत के माध्यम से।
सूची: बिन जोखिम, विधियों/एएसएन/देशों की काली/सफेद सूची।
समायोज्य द्वार: नए उपकरण, कूल-ऑफ, वेग, आरजी/एएमएल थ्रेशोल्ड जांच पर सीमा।
नीतियां: स्कोरिंग + नियमों के आधार पर 'पास/स्टेप-अप/होल्ड/ब्लॉक'।
रेल पर सुविधाएँ
कार्ड: प्राधिकरण बनाम समाशोधन (राशि स्थानांतरित की जा सकती है), 3DS2, मूल लेनदेन, विवाद/चार्जबैक पर रिटर्न।
A2A/Open बैंकिंग: पुनर्निर्देशित/सहमति प्रवाह, उच्च apruv, कम लागत; सब कुछ अतुल्यकालिक है और बैंक पर अत्यधिक निर्भर है।
स्थानीय उपवास: क्यूआर/उर्फ, तत्काल वेबहुक, टीटीएल और सख्त संकलन।
OCT/पुश-टू-कार्ड (कार्ड भुगतान): आपको कार्ड टोकन की आवश्यकता है, 3DS के बिना जारीकर्ता से फास्ट फंड समर्थन।
वर्शनिंग और संगतता
एपीआई संस्करण: '/v1 ', हेडर या फिचफ्लैग में "डेटा संस्करण"।
पीछे-संगत परिवर्तन: केवल गैर-विनाशकारी क्षेत्र।
मूल्यह्रास: प्रवास के दौरान पुराने संस्करणों, प्रवासन गाइड, डुप्लिकेट वेबहूक की वापसी के लिए अनुसूची।
अवलोकन और एसएलए
मेट्रिक्स: p95 प्राधिकरण/भुगतान समय, बीआईएन/बैंक/विधि द्वारा अनुमोदित दर, रिट्रेज़का हिस्सा, वेबहूक-लैग।
लॉग: 'अनुरोध _ id', 'idempotency _ key', 'भुगतान _ id' द्वारा सहसंबंध।
अलर्ट: एक विशिष्ट बैंक/देश के लिए इंकार में वृद्धि, टाइमआउट में वृद्धि, डुप्लिकेट घटनाएं।
स्वीप और वित्त
खाता: डबल एंट्री, अपरिवर्तनीय लॉग, 'अधिकृत/कैप्चर/रिफंडेड' स्थिति।
तीन तरफा संकलन: आपका खाता ↔ वेबहूक ↔ प्रदाता/बैंक रिपोर्ट।
संदर्भ: 'प्रदाता _ संदर्भ', 'नेटवर्क _ संदर्भ', 'भुगतान _ संदर्भ' रखें - यह समर्थन सहेजता है।
सैंडबॉक्स, प्रमाणन और उत्पादन
सैंडबॉक्स: वेबहुक स्टेटस के लिए टोकन/कार्ड/बैंक, 3DS/redirects का सिमुलेशन, "बटन"।
परीक्षण मामले: सफलता/विफलता, 3DS चुनौती, प्रदाता समय समाप्ति, डुप्लिकेट वेबहुक, आंशिक कैप्चर/रिफंड, पुनर्निर्देशन रद्द करना, भुगतान विफल।
गो-लाइव: प्रॉड कीज़, वेबहुक डोमेन, आईपी-एलोविस्ट, एंटी-फ्रॉड, सेट सीमा और अलर्ट सक्षम करें।
मिनी-उदाहरण (योजनाबद्ध)
भुगतान (कार्ड) बनाएं
POST/v1/भुगतान
{
"राशि": 9232, "मुद्रा": "EUR", " :" "कैप्चर": सही, "मेटाडेटा": {"ऑर्डर _ आईडी": "ORD-1001"}
}
200 {"आईडी": " " "स्थिति": " " ": "{"प्रकार ":" पुनर्निर्देशित ", "url":"...}}सफल नामांकन पर वेबहुक
POST/webhooks
{
"प्रकार": "भुगतान। कैप्चर किया गया," "डेटा": {"आईडी ": "पे _ एबीसी ", "राशि ": 9232, "मुद्रा":" ईयूआर"," मेटाडेटा": {" ऑर्डर _ आईडी":" ओआरडी-1001"}
}भुगतान
POST/v1/भुगतान
{
"राशि": 5000, "मुद्रा": "EUR", " :" "मेटाडेटा": {"उपयोगकर्ता _ id": "u _ 77"}
}कार्यान्वयन चेकलिस्ट
1. मुख्य वास्तुकला: सर्वर रहस्य अलग से, ग्राहक रहस्य - एक बार।
2. idempotency: प्रत्येक राइट कॉल + idempotent webhook हैंडलर में।
3. वेबहूक: एचएमएसी हस्ताक्षर, रेट्राई, कार्य कतार, अंतराल निगरानी।
4. 3DS/SCA और पुनर्निर्देशित: रद्दीकरण/टाइमआउट को संभालना, फिर से दोस्त-यूएक्स की कोशिश करना।
5. एंटीफ्राड/लिमिट: वेग, नए विवरण, ब्लैकलिस्ट, आरजी/एएमएल थ्रेसहोल्ड।
6. खाका और सामंजस्य: दोहरी प्रविष्टि, तीन तरफा सुलह, विसंगति अलर्ट।
7. ऑर्केस्ट्रेशन: स्पेयर प्रदाता, बिन/देश/राशि द्वारा रूटिंग नियम।
8. निगरानी: डैशबोर्ड दर/p95/रिट्रे, बैंकों/विधियों द्वारा अलर्ट को मंजूरी देते हैं।
9. कानूनी/पीसीआई: टोकन, रिटर्न पॉलिसी, बंद भुगतान लूप।
10. गिरावट योजना: महत्वपूर्ण संचालन के लिए किल-स्विच चैनल, कतारें, मैनुअल मोड।
बार-बार गलतियाँ
पीसीआई और टोकन के बिना इसकी तरफ पैन का भंडारण।- कोई पहचान नहीं - समय के साथ दोहराव भुगतान/भुगतान।
- वेबहूक को ध्यान में रखे बिना तुल्यकालिक प्रतिक्रियाओं पर तर्क।
- बाजार में एक प्रदाता, कोई फॉलबैक/कैस्केड नहीं।
- कोई 3DS पूर्ववत/पुनर्निर्देशित प्रसंस्करण नहीं - रीसायकल डिब्बे खो दिए।
- एक कमजोर बंडल - "जमे हुए" और "खोए हुए" लेनदेन।
- स्पष्ट एसएलए और अलर्ट की कमी - ग्राहक जो समस्या देखता है, वह आपको नहीं।
मिनी-एफएक्यू
कौन सा अधिक विश्वसनीय है: तुल्यकालिक स्थिति या वेबहुक?
वेबहुक सत्य का स्रोत है; तुल्यकालिक प्रतिक्रिया - केवल "कार्रवाई स्वीकार/आवश्यक"।
क्या आप 3DS के बिना कर सकते हैं?
नियमन/जोखिम पर निर्भर करता है। ईसी/यूके में - एससीए अनिवार्य है; उच्च जोखिम के लिए, कदम बढ़ाना बेहतर है।
अनुमोदन दर कैसे बढ़ाएं?
बिन/बैंक/विधि ऑर्केस्ट्रेशन, स्थानीय रेल, स्मार्ट रेट्रा, सही विवरणकर्ता, कम एफपीआर विरोधी धोखाधड़ी।
भुगतान "तत्काल नहीं" क्यों है?
रेल (OST/A2A/स्थानीय), प्राप्तकर्ता के बैंक और सीमाओं पर निर्भर करता है। चलो एक ईमानदार SLA खिड़की और स्थिति धारा है।
एपीआई भुगतान न केवल "भुगतान पैदा करते हैं। "यह अनुशासन: सुरक्षित प्रमाणीकरण टोकेनाइजेशन आइडेम्पोटेंसी अतुल्यकालिक वेबहूक खाता और तह - विरोधी धोखाधड़ी/एएमएल ऑर्केस्ट्रेशन और निगरानी। इस योजना के अनुसार प्रक्रिया का निर्माण करें, अतिरिक्त चैनल और पारदर्शी यूएक्स रखें - और आपकी भुगतान परत बैंकों और प्रदाताओं की विफलताओं के लिए तेज, अनुमानित और प्रतिरोधी होगी।