Casino API integration checklist: go-live से पहले क्या बनाएं, टेस्ट करें और मॉनिटर करें

आख़िरी बार जाँचा गया 2026-10-09

Casino game API integration हमेशा उन्हीं जगहों पर टूटता है: retry हुआ debit दो बार कट गया, किसी ऐसे bet का rollback आ गया जो आपने देखा ही नहीं, या तीन decimals वाली currency। यह checklist हर layer को उसी क्रम में लेती है जिसमें developer उससे टकराता है, और हर चेक के साथ बताती है कि वह किस गड़बड़ी को रोकता है।

यह casino API integration checklist उस developer के लिए है जिसके हाथ में API keys हैं और सिर पर deadline। यह उसी क्रम में चलती है जिसमें असल काम में चीज़ें सामने आती हैं: पहले आपके wallet और provider के बीच का contract, फिर lobby, फिर launch, फिर testing और live होने के बाद का पहला हफ्ता।

हर item इसलिए है क्योंकि उसके बिना कुछ न कुछ टूटता है। इन्हें एक shared doc में टिक करते जाएं, और जो खुले रह जाएं उन्हें vendor की integration टीम को सवालों के रूप में भेज दें।

0. Code की पहली लाइन से पहले

• आपके पास पूरा API documentation है, sales PDF नहीं: हर endpoint, हर error code, example payloads।
• आपको wallet model पता है। Seamless (provider हर bet और win पर आपके server को call करता है) या transfer (आप पैसा provider की तरफ के balance में डालते हैं)। यह checklist seamless मानकर चलती है, क्योंकि ज़्यादातर aggregators यही बेचते हैं।
• Staging credentials और staging callback URL, production से अलग हैं।
• Request signing साफ है: कौन सा header, कौन सा algorithm (आमतौर पर HMAC-SHA256), कौन से fields sign होते हैं, किस क्रम में।
• Provider चाहता है कि आप उसके outgoing IP addresses allow-list करें, तो वे IPs आपके पास हैं।
• आपके पास एक नामित technical contact और ऐसा channel है जो घंटों के अंदर जवाब देता है।

1. Wallet callbacks

Provider चार कामों के लिए आपके server को call करेगा। सबसे पहले इन्हें बनाएं।

• Balance। Player की currency में उसका मौजूदा खर्च करने लायक balance लौटाता है।
• Debit (bet)। फंड हो तो stake घटाता है और नया balance लौटाता है। Insufficient funds पर documented error code जाए, 500 नहीं।
• Credit (win)। Win जोड़ता है। Zero का credit भी valid है और उसे सफल होना चाहिए; कई studios हारे हुए round को बंद करने के लिए यही भेजते हैं।
• Rollback (refund)। पहले के किसी खास debit को उलटता है।
• हर response docs के मुताबिक signed या validated है।
• हर incoming call पर आप signature verify करते हैं और गलत signature को documented code के साथ reject करते हैं।
• आपका endpoint provider के timeout से काफी पहले जवाब देता है। यह नंबर docs में ढूंढें। अगर 3 सेकंड लिखा है, तो 99th percentile पर 300 ms से कम का लक्ष्य रखें।
• Amounts minor units में integers के रूप में या fixed-point decimals में स्टोर होते हैं। Float में कभी नहीं।
• Debit और credit के साथ round ID और game ID आते हैं। दोनों स्टोर करें।

Scenario। धीमे mobile connection पर एक player spin करता है। आपका debit सफल होता है, लेकिन response में 4 सेकंड लगते हैं और provider 3 पर हार मान लेता है। अब provider अपने नियमों के हिसाब से या तो rollback भेजेगा या debit को retry करेगा। Section 2 और 3 इसी पल के लिए हैं।

2. Idempotency

• आपकी transactions table में provider के transaction ID पर unique constraint है।
• एक ही transaction ID वाला दोबारा आया debit या credit पैसे को फिर से नहीं हिलाता। वह same balance values के साथ original response लौटाता है।
• Same ID पर अलग amount वाली call reject होती है और ज़ोर से log होती है। यह या तो provider का bug है या attack।
• Balance बदलना और transaction insert करना एक ही database transaction में होता है। ऐसा कोई पल नहीं जब एक हो और दूसरा न हो।
• एक ही player की एक साथ आई calls serialise होती हैं (row lock या उसके बराबर कुछ)। दो खुले game tabs से एक साथ आए दो debits, ऐसे balance पर दोनों पास नहीं होने चाहिए जो सिर्फ एक के लिए काफी है।

3. Rollbacks

• Rollback उस debit का reference देता है जिसे वह cancel करता है। उसे provider के transaction ID से ढूंढें।
• ऐसे debit का rollback जो आपको कभी मिला ही नहीं: उसे tombstone के रूप में record करें और success (या documented code) लौटाएं। अगर debit बाद में आए, तो tombstone उसे charge होने से रोकेगा।
• पहले से rolled-back debit का rollback original response लौटाता है।
• ऐसे debit का rollback जिसके round में win आ चुका है: docs को अक्षरशः फॉलो करें। कुछ providers इसकी इजाज़त नहीं देते, कुछ चाहते हैं कि आप दोनों को उलट दें।
• Rollbacks कभी balance को ऐसी हालत में नहीं पहुंचाते जिसका कोई हिसाब न हो। अगर वे balance को negative कर सकते हैं, तो नियम अभी तय करें और लिख लें।

4. Rounds और अधूरे games

• आप देख सकते हैं कि कौन से rounds खुले हैं (debit आया, closing credit नहीं)।
• आपको पता है कि provider पुराने rounds कैसे बंद करता है: timeout के बाद automatic credit, कोई manual tool, या support ticket।
• Bonus और free-round wins टैग होते हैं ताकि आपका bonus logic उन्हें cash wins से अलग treat कर सके।
• आपका back office हर player की पूरी round history दिखाता है: हर call, हर response, timestamps।

5. Currencies

• हर player की एक तय currency है, जो registration पर सेट होती है, launch पर भेजी जाती है और हर callback में वापस आती है।
• आप चेक करते हैं कि callback की currency player की currency से मेल खाती है, और mismatch को reject करते हैं।
• हर currency के decimal places सही हैं। ज़्यादातर fiat में दो होते हैं, कुछ में शून्य, कुछ में तीन। Crypto में आठ या ज़्यादा हो सकते हैं; wire पर कौन सी precision चलेगी, यह vendor के साथ तय करें।
• आप जो भी game लिस्ट करते हैं, वह सच में उस currency को support करता है जिसमें आप उसे दिखा रहे हैं। कोई studio EUR और USD support कर सकता है पर BDT या ETB नहीं।
• हर currency के bet limits समझ में आने वाले हैं। जो minimum bet EUR में छोटा है, वह IDR में अजीब और BTC में बहुत बड़ा हो सकता है।
• Reports में display currency और settlement currency आपस में गड़बड़ नहीं होतीं।

6. Game list sync

• Game list API से schedule पर खींची जाती है, कम से कम रोज़, और लोकल स्टोर होती है।
• बंद या हटाए गए games अगले sync पर lobby से गायब हो जाते हैं, अगली तिमाही में नहीं।
• अगर आप curate करते हैं, तो नए games सीधे lobby में नहीं, review state में आते हैं।
• आप provider का stable game ID स्टोर करते हैं, नाम नहीं। नाम बदलते रहते हैं।
• Images आपकी तरफ cache होती हैं या mobile के लायक साइज़ में serve होती हैं।
• हर game के साथ उसकी category, studio, device support और currency support है, ताकि lobby filters गलत न दिखाएं।
• जो studios किसी market के लिए बंद हैं, उन्हें आपके अपने नियम filter करते हैं, किस्मत पर नहीं छोड़ा जाता।

7. Launch URLs

• Real-money launch में player से जुड़ा short-lived session token जाता है। कभी password या दोबारा इस्तेमाल होने वाला ID नहीं।
• Token expiry संभाली गई है: पुराने tab में साफ मैसेज दिखता है, टूटा हुआ frame नहीं।
• Launch पर language, currency, device type और return/lobby URL सेट होते हैं।
• जहां game support करता है, वहां deposit या cashier URL भेजा जाता है, ताकि “insufficient funds” के बाद player कहीं पहुंचे।
• Game iframe और नई window, दोनों में सही खुलता है। कुछ studios कुछ domains या browsers पर iframe ब्लॉक करते हैं।
• अगर demo launches ऑफर हैं, तो वे कभी real wallet को नहीं छूते। इसे अलग से टेस्ट करें।
• Click से पहले frame तक का launch time, 4G पर mid-range फोन पर नापा गया है। 5 सेकंड से ज़्यादा लगा तो players निकल जाते हैं।

8. Testing

• हर उस currency के लिए एक test player जिसे आप support करेंगे।
• हर game type का एक पूरा round: slot, live table, crash, table game, virtual।
• जानबूझकर failures: आपका server timeout, 500 या insufficient-funds code लौटाए। देखें provider आगे क्या करता है।
• Duplicate calls हाथ से replay करें: debit दो बार, credit दो बार, rollback दो बार।
• उल्टे क्रम में calls: debit से पहले rollback, rollback के बाद credit।
• दो tabs, एक ही player, एक साथ spin।
• Game के बीच में session expiry।
• एक बड़ा win और एक zero win।
• Test period के लिए आपकी reconciliation report provider की report से पाई-पाई तक मेल खाती है।

9. Go-live

• Production keys और callback URL बदल दिए गए, production players के लिए staging बंद।
• Callback latency, error rate और signature failures पर monitoring, और alerts किसी इंसान तक जाते हैं, उस dashboard तक नहीं जिसे कोई खोलता ही नहीं।
• रोज़ का reconciliation job: हर game और हर currency के आपके totals बनाम provider के totals।
• Prepaid models में zero से काफी ऊपर low-credit alert, और कोई ऐसा व्यक्ति जो रविवार को भी top up कर सके।
• आपके back office में हर game और हर studio के लिए kill switch।
• Vendor का support channel और escalation contact आपकी runbook में लिखा है।

10. पहले सात दिन

• हर सुबह reconciliation चेक करें।
• सभी rejected callbacks और खुले rounds देखें।
• हर studio के launch errors पर नज़र रखें; एक खराब studio पूरी lobby को नीचे खींच सकता है।
• Vendor से उनकी तरफ के error logs मांगें और मिलान करें।

Crypto brand launch करने वाली छोटी टीम, vendor का documentation ठोस हो तो, यह लिस्ट एक हफ्ते में पूरी कर सकती है। अगर docs कमज़ोर हैं, तो यही लिस्ट vendor का भी अच्छा टेस्ट है: गिनें कि कितने items के बारे में आपको पूछना पड़ा। Seamless wallet ranking और नए ऑपरेटर्स के लिए aggregators वाला पेज vendors को ठीक इसी तरह के integration काम पर score करते हैं।