मार्केटप्लेस फ्लो ऑर्डर, भुगतान, भुगतान वितरण, रिफंड, और विवाद की अवस्थाओं को अलग करता है, जिसमें अनिश्चित भुगतान-प्रदाता परिणामों के लिए स्पष्ट हैंडलिंग होती है ताकि आंशिक विफलताएं विक्रेताओं से दोहरी चार्जिंग या दोहरी भुगतान न करें।
पैकेज स्थिति: एआई-सहायता प्राप्त संदर्भ पैकेज। स्थैतिक पैकेज सत्यापन पास हो चुका है; कार्यान्वयन परिदृश्य अभी चलाए नहीं गए हैं और स्थिर अपनाने से पहले मानव डोमेन समीक्षा आवश्यक है।
निर्णय
मार्केटप्लेस कॉमर्स को ऑर्डर पूर्ति, खरीदार भुगतान कैप्चर, विक्रेता भुगतान वितरण, रिफंड, और विवाद के लिए ढीले रूप से जुड़े राज्य मशीनों के रूप में मॉडल किया गया है। प्रत्येक मशीन स्पष्ट संक्रमण और गार्ड प्रदर्शित करती है; बाहरी भुगतान प्रदाताओं से अनिश्चित परिणाम जांच अवस्थाओं में जाते हैं जहाँ सफलता या विफलता मानने के बजाय आइडेम्पोटेंट पुनर्समायोजन होता है। अस्पष्ट भुगतान स्थिति से भुगतान वितरण आगे नहीं बढ़ सकता। रिफंड मूल कैप्चर आईडी का संदर्भ लेते हैं और आंशिक रिफंड के दौरान कैप्चर किए गए कुल से अधिक नहीं हो सकते।
दायरा
- ऑर्डर, भुगतान, भुगतान वितरण, रिफंड, विवाद के लिए राज्य परिभाषाएँ और अनुमत संक्रमण।
- प्रदाता अनिश्चितता हैंडलिंग, वेबहुक आइडेम्पोटेंसी, और पुनर्समायोजन जॉब्स।
- जब भुगतान वितरण सफल हो गया लेकिन बाद में चार्जबैक आता है तो मुआवजा।
- ऑडिट फ़ील्ड जो संस्थाओं को लिंक करते हैं: order_id, payment_intent_id, payout_id, refund_id।
- फंसे हुए अनिश्चित राज्यों पर मेट्रिक्स और डुप्लिकेट प्रदाता इवेंट दबाव।
इस ब्लॉक के बाहर
- कर गणना और चालान प्रारूपण।
- विक्रेता ऑनबोर्डिंग KYC कानूनी आवश्यकताएँ।
- उत्पाद कैटलॉग खोज।
अनुबंध
- ऑर्डर, भुगतान, भुगतान वितरण, रिफंड, और विवाद की अवस्थाएँ अलग-अलग संग्रहीत होती हैं; सम्मिलित दृश्य व्युत्पन्न होते हैं, प्राधिकृत नहीं।
- भुगतान कैप्चर सफलता केवल प्रदाता-पुष्टि किए गए अंतिम घटना या पुनर्समायोजित समकक्ष पर दर्ज होती है।
- अनिश्चित प्रदाता परिणाम provider_pending या provider_unknown में जाते हैं जब तक पुनर्समायोजन न हो; भुगतान कैप्चर होने तक भुगतान वितरण गार्ड ब्लॉक रहता है।
- रिफंड संक्रमण के लिए कैप्चर किए गए भुगतान संदर्भ की आवश्यकता होती है और शेष रिफंडेबल बैलेंस लागू होता है।
- विवाद खोलने पर प्रभावित कैप्चर के लिए भुगतान वितरण रिलीज़ फ्रीज हो जाता है जब तक कि वह हल न हो, प्रोफ़ाइल टाइमआउट के बाद ऑपरेटर-रिव्यू-आवश्यक के लिए बढ़ाया न जाए, या स्पष्ट रूप से बंद न किया जाए; केवल टाइमआउट से भुगतान वितरण स्वतः रिलीज़ नहीं होता जब तक कि अलग से समीक्षा की गई नीति इसे सक्षम न करे।
- प्रदाता वेबहुक हैंडलर प्रदाता इवेंट आईडी पर आइडेम्पोटेंट होते हैं; डुप्लिकेट दोहरी कैप्चर या दोहरी भुगतान वितरण नहीं करते।
- भुगतान वितरण के बाद चार्जबैक भुगतान वितरण को क्लॉबैक-पेंडिंग में ले जाता है, बिना ऑडिट के नकारात्मक बैलेंस में चुपचाप नहीं।
कार्यान्वयन मार्गदर्शन
- क्रॉस-इकाई संक्रमण के लिए आउटबॉक्स या सागा ऑर्केस्ट्रेशन का उपयोग करें जिसमें मुआवजा क्रियाएं दस्तावेजीकृत हों।
- प्रोफ़ाइल SLA से परे अज्ञात राज्यों के लिए प्रदाता API के खिलाफ अनुसूचित पुनर्समायोजन चलाएं।
- केवल क्लाइंट-साइड रीडायरेक्ट से सफलता का अनुमान न लगाएं।
विफलता हैंडलिंग और सुरक्षा उपाय
- यदि भुगतान वितरण वर्कर प्रदाता सफलता के बाद विफल हो जाता है, तो उसी भुगतान वितरण आईडी के साथ टर्मिनल स्थिति तक पुनः प्रयास करें।
- मैनुअल ऑपरेटर ओवरराइड के लिए द्वैध नियंत्रण और अपरिवर्तनीय ऑडिट कारण आवश्यक है।
- समान क्लाइंट संदर्भ कुंजी के साथ डुप्लिकेट ऑर्डर सबमिशन को ब्लॉक करें; पुनः चलाने पर मूल ऑर्डर परिणाम लौटाएं।
- भुगतान वितरण वर्कर पुनः प्रयास उसी payout_id का उपयोग करते हैं जब तक टर्मिनल स्थिति न हो, बिना दोहरी ट्रांसफर के।
सत्यापन और संचालन
- provider_unknown रिकॉर्ड की उम्र, डुप्लिकेट वेबहुक दबाव गणना, और क्लॉबैक बैकलॉग की निगरानी करें।
- आंतरिक लेजर और प्रदाता रिपोर्टों के बीच दैनिक कुलों का पुनर्समायोजन करें।
- लक्षित रिपॉजिटरी में स्वीकृति परिदृश्यों को निष्पादित करें; पैकेज्ड परिदृश्य निष्पादित प्रमाण नहीं हैं।
अपनाने की धारणाएँ
- फिक्स्चर में प्रदाता नाम और SLA मिनट प्रोफ़ाइल विकल्प हैं, विक्रेता गारंटी नहीं।
- टीमें भुगतान प्रोसेसर और लेजर खातों को स्थानीय रूप से वित्त समीक्षा के साथ मैप करती हैं।