क्या API मौजूदा पैनल इंटीग्रेशन के साथ संगत है?

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

मेरे दो कर्मचारी एक ही ऑर्डर क्यों डिलीवर करते रहते हैं?

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

जब मैं "paid" पर फ़िल्टर करता हूँ तो मेरा ऑर्डर क्वेरी कुछ क्यों नहीं लौटाती?

भुगतान स्थिति फ़ील्ड में कोई "paid" मान नहीं है। उपयोग में आने वाले मान हैं: completed, partial, refunded, failed, pending और processing। ऑर्डर की स्थिति एक अलग फ़ील्ड में ट्रैक की जाती है, जिसके अपने अलग मान होते हैं। "paid" पर फ़िल्टर लगाने से एक खाली सेट मिलता है, जो त्रुटि के बजाय परिणाम जैसा दिखता है।

पुल एंडपॉइंट कौन से ऑर्डर लौटाता है?

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

वारंटी विंडो कब शुरू होती है?

डिलीवरी पर, भुगतान पर नहीं। इसे घंटों में मापा जाता है, जिसमें प्लेटफ़ॉर्म-व्यापी न्यूनतम सीमा और उसके ऊपर प्रति-विक्रेता सेटिंग्स होती हैं। तुरंत डिलीवर होने वाले स्टॉक पर ये दोनों पल कुछ मिनटों के अंतर पर होते हैं, लेकिन ऐसे ऑर्डर पर जो पहले प्रोसेसिंग में रुका हो, अंतर पूरी अवधि का हो सकता है।

यहाँ बेचने के लिए विक्रेता को क्या खर्च करना पड़ता है?

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

HstockPlus प्लेटफ़ॉर्म: ऑर्डर, फ़ुलफ़िलमेंट और API वास्तव में एक साथ कैसे काम करते हैं

यह पृष्ठ बताता है कि मार्केटप्लेस एक सिस्टम के रूप में कैसे काम करता है: इसमें क्या भूमिकाएँ हैं, ऑर्डर का रास्ता क्या है, और API क्या उजागर करता है। इस पृष्ठ से कुछ भी नहीं बेचा जाता है।

दो कैटलॉग, एक नहीं

प्लेटफ़ॉर्म दो तरह का स्टॉक रखता है और वे इतने अलग व्यवहार करते हैं कि उन्हें एक ही चीज़ मानना समस्याएँ पैदा करता है।

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

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

सक्रिय कैटलॉग द्वारा विक्रेताओं की संख्या कुछ सौ के आसपास है, जबकि लगभग पंद्रह सौ अकाउंट विक्रेता भूमिका रखते हैं, जो लगभग पाँच सौ साठ दुकानों में फैले हैं।

भूमिकाएँ और प्रत्येक की पहुँच

तीन भूमिकाएँ मौजूद हैं और वे अनन्य के बजाय योगात्मक हैं, इसलिए एक अकाउंट खरीदार और विक्रेता दोनों हो सकता है।

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

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

विक्रेता पाँच स्तरों में से एक पर होते हैं जो रोलिंग बारह महीने की विशेषता वाली बिक्री से प्राप्त होते हैं। स्तर सजावटी नहीं है। यह निर्धारित करता है कि प्लेटफ़ॉर्म फंड स्वचालित रूप से जारी करने से पहले कितनी देर प्रतीक्षा करता है, और यह लिस्टिंग सीमा गणना को फ़ीड करता है।

ऑर्डर कैसे चलता है

ऑर्डर की स्थिति और भुगतान की स्थिति अलग-अलग ट्रैक की जाती हैं, और API पढ़ते समय दोनों मायने रखते हैं।

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

पूर्ति लिस्टिंग प्रकार के अनुसार भिन्न होती है। स्वचालित और इन्वेंट्री-समर्थित लिस्टिंग वह स्टॉक सौंपती हैं जो प्लेटफ़ॉर्म पहले से रखता है। मैनुअल लिस्टिंग वे हैं जिन्हें विक्रेता या विक्रेता के सॉफ़्टवेयर को कार्य करने की आवश्यकता होती है, और पूर्ति API उन्हीं के लिए है।

एक बार जब खरीदार को वह मिल जाता है जो उसने ऑर्डर किया था, तो वारंटी विंडो खुलती है। इसे घंटों में मापा जाता है और यह भुगतान के बजाय डिलीवरी से चलती है, जिसमें साइट-व्यापी न्यूनतम कुछ घंटे और उसके ऊपर प्रति-विक्रेता सेटिंग्स होती हैं। उस विंडो के भीतर एक खरीदार टिकट या विवाद खोल सकता है; इसके बाहर, विवाद मार्ग मना कर देता है। फंड विक्रेता को तब जारी होते हैं जब खरीदार पुष्टि करता है या जब उस विक्रेता के स्तर के लिए ऑटो-कन्फर्म टाइमर समाप्त होता है, जो भी पहले हो, और एक सक्रिय विवाद रिलीज़ को रोकता है।

API, और सबसे महत्वपूर्ण अंतर

दो API सतहें हैं, दोनों कुंजी द्वारा प्रमाणित हैं।

खरीदार-मुखी सतह व्यापक रूप से उपयोग किए जाने वाले पैनल सम्मेलन का पालन करती है: एक एकल एंडपॉइंट जो action पैरामीटर लेता है। मानक क्रियाएँ सभी लागू हैं, इसलिए मौजूदा पैनल टूलिंग इसके खिलाफ काम करती है: services उपलब्ध चीज़ों को सूचीबद्ध करने के लिए, add ऑर्डर देने के लिए, status एक की जाँच करने के लिए, balance, refill और cancel। इनके ऊपर यह उन क्रियाओं को जोड़ता है जिन्हें सम्मेलन परिभाषित नहीं करता है: categories और subcategory_info टैक्सोनॉमी को नेविगेट करने के लिए, products और shops, allowcancel, inventory स्टॉक जाँच के लिए, और SMS सत्यापन क्रियाओं का एक पूरा सेट जिसमें प्रोजेक्ट, देश, नंबर ऑर्डर करना और कोड के लिए पोलिंग शामिल है। इसे मानक सम्मेलन प्लस एक्सटेंशन के रूप में मानें, न कि ड्रॉप-इन क्लोन के रूप में; मानक कॉल बिना बदलाव के काम करेंगे, और एक्सटेंशन वह जगह हैं जहाँ प्लेटफ़ॉर्म-विशिष्ट क्षमता रहती है।

विक्रेता-मुखी सतह एक पारंपरिक REST API है जो प्रोडक्ट्स, ऑर्डर, टिकट और भुगतान को कवर करती है। इसके भीतर एक अंतर है जो तय करता है कि आपका एकीकरण सही है या नहीं, और इसे गलत समझना आसान है क्योंकि दोनों एंडपॉइंट ऑर्डर लौटाते हैं।

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

जो कुछ भी स्वचालित रूप से पूर्ति करता है उसे पुल करना चाहिए, लिस्ट नहीं। डैशबोर्ड और समाधान के लिए रीड का उपयोग करें, जहाँ एक ही ऑर्डर को दो बार देखना हानिरहित है।

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

दोनों सतहों के लिए पूर्ण संदर्भ खरीदार API दस्तावेज़ीकरण और विक्रेता API दस्तावेज़ीकरण पर रहता है।

भुगतान और बैलेंस

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

विक्रेता निपटाए गए, जारी किए गए ऑर्डर मूल्य के खिलाफ पेआउट का अनुरोध करते हैं। एक न्यूनतम लागू होता है, जो प्लेटफ़ॉर्म-व्यापी सेट होता है और शीर्ष पर अतिरिक्त प्रति-विधि न्यूनतम होते हैं, और पेआउट पर प्रतिशत शुल्क लगता है। विक्रेताओं से कोई प्रति-ऑर्डर कमीशन नहीं लिया जाता है, इसलिए पेआउट शुल्क वह जगह है जहाँ प्लेटफ़ॉर्म का हिस्सा बिक्री के बजाय बैठता है।

सहायता और विवाद

सहायता तीनों भूमिकाओं द्वारा साझा की गई टिकट प्रणाली के माध्यम से चलती है, इसलिए एक खरीदार, एक विक्रेता और सहायता एक थ्रेड में हो सकते हैं बजाय तीन बातचीत में जो कभी नहीं मिलतीं। टिकट एक समस्या वर्गीकरण रखते हैं, और एक विक्रेता वितरित आइटम को बदलकर, उसे रिफंड करके, या दावे को अस्वीकार करके एक को हल कर सकता है।

विवाद भारी मार्ग हैं और जानबूझकर संकीर्ण हैं: उन्हें ऑर्डर पूर्ण और उसकी वारंटी विंडो के भीतर होना चाहिए, कम से कम एक स्क्रीनशॉट, और दो-स्तरीय समस्या सूची से चयन। वे फंड विक्रेता या खरीदार के पास जाने के साथ समाप्त होते हैं। एक प्रतिस्थापन विवाद परिणाम नहीं है, यही कारण है कि टिकट मार्ग वास्तविक समस्याओं के बड़े बहुमत को हल करता है और पहले टिकट खोलना आमतौर पर तेज़ मार्ग है।

शेड्यूल पर क्या चलता है

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

इनमें से कोई भी API को खुद घोषित नहीं करता है। यदि आपका समाधान आपके किसी कॉल के बिना ऑर्डर की स्थिति बदलते देखता है, तो उनमें से एक आमतौर पर इसका कारण होता है।

शुरू करना

पंजीकरण करें, फिर यदि आप बेचने का इरादा रखते हैं तो विक्रेता अनुमोदन का अनुरोध करें। अनुमोदन API के साथ-साथ इंटरफ़ेस को भी गेट करता है।
लिस्टिंग बनाएं, या कॉन्फ़िगर किए गए अपस्ट्रीम प्रदाता से थोक में ग्रोथ सेवाएँ आयात करें, एक-एक करके नहीं।
एक API कुंजी उत्पन्न करें और किसी और चीज़ से पहले प्रोफ़ाइल एंडपॉइंट को कॉल करके अपनी भूमिका की पुष्टि करें।
यदि आप मैन्युअल रूप से पूर्ति करते हैं, तो शुरू से पुल एंडपॉइंट के खिलाफ निर्माण करें। डुप्लिकेट डिलीवरी भेजने के बाद लिस्ट से पुल पर स्विच करना इस पैराग्राफ को पढ़ने से बुरा दिन है।
प्रति लिस्टिंग वारंटी घंटे जानबूझकर सेट करें। यह वह घड़ी है जिसके खिलाफ प्लेटफ़ॉर्म पर हर खरीदार सुरक्षा चलती है, और यह डिलीवरी से शुरू होती है।