डेबिट के बाद टाइमआउट: आइडेम्पोटेंसी की सुरक्षा कहाँ खत्म होती है

पेमेंट API का सबसे महँगा जवाब कभी-कभी जवाब का न आना होता है, और यहीं आइडेम्पोटेंसी key की असली परीक्षा होती है। सर्वर नतीजे का इंतज़ार नहीं कर पाया, लेकिन इससे यह पता नहीं चलता कि प्रोवाइडर ने डेबिट कर दिया या नहीं। नई रैंडम key से नया HTTP जवाब तो मिल जाता है, लेकिन साथ ही दूसरा ट्रांज़ैक्शन भी बन सकता है। दोहराव को सुरक्षित बनाने के लिए पहले यह तय करना होगा कि ठीक-ठीक क्या वही का वही रहता है।

दो कर्मचारी एक ही रिफ़ंड करते हैं

एक और चुपचाप होने वाली गलती की कल्पना कीजिए: सपोर्ट 20 यूरो रिफ़ंड करता है, और लगभग उसी समय फ़ाइनेंस ऑपरेटर उसी शिकायत पर 20 यूरो और रिफ़ंड कर देता है। API keys अलग हैं, दोनों रिक्वेस्ट तकनीकी रूप से सही हैं। यहाँ प्रोवाइडर की आइडेम्पोटेंसी यह नहीं पहचान पाएगी कि दोनों कर्मचारी एक ही निर्देश पूरा कर रहे हैं। सुरक्षा अंदरूनी रिफ़ंड केस और उसे पूरा करने की यूनिक अनुमति से शुरू होनी चाहिए।

सहमत रिफ़ंड के लिए प्रोवाइडर से संपर्क करने से पहले एक रिकॉर्ड बनाइए। यह कस्टमर की शिकायत, मूल पेमेंट, रकम और आधार को जोड़ता है। दूसरे कर्मचारी को पहले से बना हुआ एक्शन दिखना चाहिए, न कि वह नई एंट्री बना दे। साथ ही, दो सच में अलग आंशिक रिफ़ंड जायज़ हैं: जैसे दो लौटाए गए सामानों के लिए। सिस्टम को निर्देश के दोहराव और नए निर्देश में फ़र्क करना होगा, इसलिए सिर्फ़ रकम की तुलना काफ़ी नहीं है।

एक ऑपरेशन की परिभाषा से शुरू कीजिए

प्रस्तावित मॉडल ऑर्डर नंबर और पेमेंट पर एक्शन के नंबर को अलग करता है। एक ऑर्डर में ऑथराइज़ेशन, कई अनुमत आंशिक कैप्चर और अलग रिफ़ंड हो सकते हैं। इसलिए «ऑर्डर नंबर» सभी रिक्वेस्ट के लिए बहुत व्यापक है, और हर HTTP कॉल पर नई रैंडम key बहुत संकरी। पहले किसी खास एक्शन का स्थिर अंदरूनी रिकॉर्ड बनाइए।

उदाहरण के लिए, काल्पनिक ऑर्डर Q-731 में 48 यूरो का कैप्चर होना है। अंदरूनी बिज़नेस key का मतलब है «Q-731, कैप्चर, भाग 1»। इससे रकम, करेंसी, प्राप्तकर्ता, प्रोवाइडर अकाउंट और इरादे का वर्ज़न जुड़े होते हैं। API कॉल के लिए एक अलग अपारदर्शी key बनाई जाती है, जो पहली बार भेजने से पहले सहेज ली जाती है। दोबारा क्लिक, बैकग्राउंड प्रोसेस और क्रैश के बाद चालू हुआ सर्वर, सब यही key इस्तेमाल करते हैं। इसमें पर्सनल डेटा डालने की ज़रूरत नहीं है।

आइडेम्पोटेंट रिक्वेस्ट पर Stripe का डॉक्यूमेंटेशन दिखाता है कि API वर्ज़न को ध्यान में रखना क्यों ज़रूरी है: API v1 में एक्ज़ीक्यूशन शुरू होने के बाद दोहराव सहेजा गया नतीजा लौटाता है, कुछ एरर वाले जवाबों समेत। key को रखने की अवधि और पैरामीटर की तुलना के नियम भी कॉन्ट्रैक्ट का हिस्सा हैं। किसी भी key को दोबारा ऑपरेशन पर स्थायी रोक मत मानिए।

«नतीजा अज्ञात» स्थिति साफ़ दिखनी चाहिए

1. 1.तैयार। प्लेटफ़ॉर्म ने एक्शन, उसके पैरामीटर और प्रोवाइडर की key सहेज ली है। यूनिकनेस की पाबंदी दो हैंडलर को एक ही इरादा अलग-अलग बनाने नहीं देती।
2. 2.भेजा गया। एक एक्ज़ीक्यूटर को रिक्वेस्ट चलाने का अधिकार मिला; बाकी मौजूदा ट्रांज़ैक्शन देखते हैं और नया नहीं बनाते।
3. 3.नतीजा अज्ञात। जवाब खो गया या अधूरा है। यह एक अलग कामकाजी स्थिति है, अपने आप पुष्ट डिक्लाइन नहीं।
4. 4.नतीजा तय। जवाब, जाँचा गया इवेंट या तय रिकंसिलिएशन नतीजे की पुष्टि करता है। प्लेटफ़ॉर्म उसे दर्ज करता है और तय बिज़नेस कार्रवाई करता है।

यहाँ स्थितियों के नाम उदाहरण के लिए हैं। किसी असली सिस्टम में ऑथराइज़ेशन, कैप्चर, कैंसलेशन और दूसरे चरणों में फ़र्क करना होगा। अहम बात कुछ और है: टीम को अधूरापन दिखना चाहिए और उसे सुलझाने का अनुमत तरीका पता होना चाहिए। «ताज़ा» जवाब पाने के लिए अनिश्चितता को नई key से मत ढकिए।

ठीक-ठीक क्या दोहराया जा सकता है

दोहराने से पहले जाँचिए कि बात उसी ऑपरेशन की है, उन्हीं अहम पैरामीटर के साथ और प्रोवाइडर के नियमों के दायरे में। PayPal में PayPal-Request-Id का सपोर्ट और उसे रखने की अवधि API पर निर्भर करती है। दोहराव पिछली रिक्वेस्ट का मौजूदा स्टेटस लौटा सकता है। यह एक और वजह है कि हर मेथड का कॉन्ट्रैक्ट जाँचा जाए, न कि यह मान लिया जाए कि सभी पेमेंट SDK एक जैसे बर्ताव करते हैं।

अगर कस्टमर ने ऑर्डर बदल दिया और रकम 53 यूरो हो गई, तो इसके लिए पेमेंट पर नया फैसला चाहिए। पहले 48 यूरो वाले पुराने एक्शन का हाल पता कीजिए। उसके बाद ही प्रोडक्ट प्रोसेस और कस्टमर की सहमति के अनुसार तय कीजिए कि कैंसलेशन, अतिरिक्त भुगतान या नया ट्रांज़ैक्शन चाहिए। दोहराई गई रिक्वेस्ट में बस रकम बदल देना बिज़नेस इरादे के अहम बदलाव को छिपा देता है।

अपनी सर्विस के लिए अहम पैरामीटर का फ़िंगरप्रिंट सहेजना और एक ही अंदरूनी key वाली टकराती रिक्वेस्ट को अस्वीकार करना उपयोगी है। पहले से तय कीजिए कि कौन-से फ़ील्ड अहम हैं: रकम और प्राप्तकर्ता पर निश्चित रूप से ध्यान चाहिए, जबकि तकनीकी ट्रेसिंग आईडी आम तौर पर पेमेंट का मतलब नहीं बदलता। सपोर्ट को टकराव के बारे में साफ़ संदेश दीजिए, सीक्रेट और पूरे पेमेंट विवरण उजागर किए बिना।

सुरक्षा की सीमा API कॉन्ट्रैक्ट से तय होती है

Adyen keys के दायरे का अलग से वर्णन करता है, जिसमें यह भी शामिल है कि कुछ क्षेत्रीय एंडपॉइंट के बीच डुप्लिकेट की साझा जाँच नहीं होती। इसलिए रिक्वेस्ट को दूसरे रूट पर ले जाने को अपने आप वही सुरक्षित दोहराव नहीं माना जा सकता। और दो स्वतंत्र प्रोवाइडर्स के पास key की एक जैसी स्ट्रिंग होने से अपने आप कोई साझा तालमेल नहीं बनता।

अंदरूनी इतिहास नेटवर्क रिक्वेस्ट की उम्र से ज़्यादा समय तक रखिए और पुराने अनसुलझे ट्रांज़ैक्शन के लिए प्रक्रिया तय कीजिए। प्रोवाइडर की गारंटी वाली विंडो खत्म होने के बाद पहले रिकंसिलिएशन चाहिए। अगर नतीजा तय नहीं हो पाता, तो अंतहीन कोशिशों की जगह अपवाद का मालिक और एस्केलेशन तय कीजिए।

मैनुअल सुधार मत छिपाइए

ऑपरेटर को कभी-कभी रिकंसिलिएशन का इंतज़ार करने से ज़्यादा आसान अटके एक्शन का लॉक हटाना लगता है। ऐसे बदलाव को दिखने लायक बनाइए: आगे बढ़ने की अनुमति किसने दी, किस सबूत ने पिछला नतीजा तय किया, कौन-सा नया ट्रांज़ैक्शन पुराने की जगह ले रहा है। डेटाबेस में बस स्टेटस बदल देना कारण और असर का संबंध मिटा देता है और अगली शिफ्ट के लिए एक विश्वसनीय दिखने वाला, लेकिन गलत इतिहास छोड़ जाता है।

डिज़ाइन रिव्यू में एक उपयोगी तरीका: उन सभी जगहों की सूची बनाइए जो एक्शन शुरू कर सकती हैं। खरीदार का बटन, शेड्यूल्ड जॉब, SDK का रीट्राई, सपोर्ट कंसोल, कतार की रिकवरी और मैनुअल स्क्रिप्ट, सब एक ही इरादा मॉडल में होने चाहिए। वरना हर कंपोनेंट अपने डुप्लिकेट तो सही ढंग से रोकेगा, लेकिन पूरा सिस्टम दूसरों के डुप्लिकेट बनाता रहेगा।

अगले इंटीग्रेशन रिव्यू की शुरुआत सबसे सीधे सवाल से कीजिए: रिफ़ंड या डेबिट का मंज़ूर निर्देश कहाँ सहेजा जाता है? अगर जवाब सिर्फ़ HTTP रिक्वेस्ट की key है, तो सुरक्षा बहुत देर से शुरू होती है।