SHAREAI के साथ निर्माण करें
ग्राहकों को AI उपयोग, आपके वैकल्पिक शुल्क और प्रत्येक खरीद के बारे में एक स्पष्ट विकल्प दें। एक भुगतान यात्रा बनाएं जिसे वे समझ और नियंत्रित कर सकें।
अनुभव जिसे आप डिज़ाइन करेंगे
ShareAI के साथ भुगतान करेंस्पष्ट एक्सेस। स्वीकृत शर्तें। पुष्टि की गई खरीदारी।
आपका कार्यान्वयन
अपने उत्पाद और कार्यान्वयन दोनों में प्राधिकरण, स्वीकृत शर्तें और पुष्टि की गई भुगतान को स्पष्ट रखें।
ग्राहक समझता है कि वे कनेक्ट कर रहे हैं, AI का उपयोग कर रहे हैं या खरीदारी को मंजूरी दे रहे हैं।
टोकन और ऑपरेशन इच्छित खाता और स्कोप का उपयोग करते हैं।
समझने योग्य ऑफ़र प्रकाशित करें और उस संस्करण को ट्रैक करें जिसे प्रत्येक ग्राहक ने स्वीकार किया है।
नए शर्तें मौजूदा ग्राहक को चुपचाप स्थानांतरित नहीं करती हैं।
एक इच्छित खरीदारी बनाएं, इसकी भुगतान स्थिति सत्यापित करें और इसे एक बार पूरा करें।
पुनः प्रयास, रद्दीकरण, अस्वीकृत चेकआउट और सीमाएं संभाली जाती हैं।
इसे अपने एडिटर में ले जाएं
कार्यान्वयन लक्ष्य, आवश्यक इनपुट और स्वीकृति चेक्स के साथ पूरी गाइड कॉपी करें। कोड उदाहरण, टेबल और दस्तावेज़ लिंक को एक साथ रखें।
आपके प्रोजेक्ट के लिए तैयार, जिस प्रारूप में आपको आवश्यकता है।
अद्यतनित
आप खाता कनेक्ट करने, AI उपयोग के लिए भुगतान करने और उत्पाद खरीदारी की पुष्टि करने को अलग करेंगे।
जहां आप काम करेंगे आपका उत्पाद → भुगतान अनुभव
Pay with ShareAI ग्राहक को उनके चयनित ShareAI खाते का उपयोग आपके एप्लिकेशन में करने की अनुमति देता है। दो अलग-अलग बिलिंग प्रवाह हैं: स्वीकृत प्राधिकरण के तहत ग्राहक-वित्त पोषित AI अनुरोध, और एक उत्पाद खरीद जिसे ग्राहक चेकआउट में पुष्टि करता है। वैकल्पिक Builder मार्कअप AI उपयोग पर एक अतिरिक्त समझौता है।
| ग्राहक कार्रवाई | क्या होता है | आवश्यक पहुंच |
|---|---|---|
| एक वॉलेट कनेक्ट करें | चयनित खाते और स्वीकृत शर्तों के लिए एक प्राधिकरण बनाता है। Connect पर क्लिक करने से कोई उत्पाद नहीं खरीदा जाता है। | openid साथ ही आपके ऐप द्वारा उपयोग की जाने वाली क्षमताएँ। |
| AI अनुरोध भेजें | स्वीकृत उपयोग शर्तों और अधिकृत खाते के पात्र AI क्रेडिट का उपयोग करता है। | लागू अनुमानित पहुंच; monetization_gateway स्वीकृत Builder मार्कअप शर्तों के लिए। |
| उत्पाद खरीद की पुष्टि करें | अधिकृत पुष्टि के बाद ही विशेष खरीद को डेबिट करता है। | payments और एक सफल भुगतान अनुरोध। |
JamZY का अपॉइंटमेंट नमूना AI उपयोग मार्ग को प्रदर्शित करता है। इसमें कोई व्यापारी चेकआउट नहीं है, भुगतान का कोई अनुरोध नहीं करता है और यह दावा नहीं करता कि कनेक्ट करने से कोई सदस्यता खरीदी जाती है। जब आप उस अलग अनुभव को जोड़ते हैं तो शेष अध्यायों का उपयोग करें।
आपका बटन और उत्पाद कॉपी यह कहते हैं कि ग्राहक कनेक्ट कर रहा है, AI का उपयोग कर रहा है या खरीद की पुष्टि कर रहा है।
आप ऑपरेशन के उपयोग से पहले इच्छित भुगतान खाते से अनुमति प्राप्त करेंगे।
जहां आप काम करेंगे कंसोल → उपयोग के मामले → ग्राहक प्राधिकरण
payments, नेटवर्क लागत पर AI के लिए inference, और स्वीकृत AI मार्कअप के लिए monetization_gateway का उपयोग करें। केवल उन्हीं क्षमताओं का अनुरोध करें जिनका एप्लिकेशन वास्तव में उपयोग करता है।एक क्लाइंट ID प्लेटफ़ॉर्म की पहचान करता है। एक एक्सेस टोकन स्वीकृत ग्राहक प्राधिकरण का प्रतिनिधित्व करता है। एक अनुबंध संस्करण बिलिंग शर्तों को रिकॉर्ड करता है। इनमें से कोई भी अकेले यह साबित नहीं करता कि किसी विशेष उत्पाद भुगतान की पुष्टि की गई थी।
टोकन इच्छित ग्राहक का होता है और इसमें उस ऑपरेशन के लिए अनुमतियाँ शामिल होती हैं जिसे आप करने वाले हैं।
आप स्पष्ट उपयोग शर्तें प्रकाशित करेंगे जिन्हें ग्राहक समीक्षा कर सकता है और स्वीकार कर सकता है।
जहां आप काम करेंगे एप्लिकेशन → सदस्यताएँ
Subscriptions में, स्पष्ट रूप से नामित ऑफ़र बनाएं और अतिरिक्त AI शुल्क की व्याख्या करें। सदस्यता ID उत्पन्न होती है, केवल-पढ़ने योग्य होती है और आपके एप्लिकेशन के लिए स्कोप्ड होती है। ये ऑफ़र ऐप के प्लेटफ़ॉर्म क्लाइंट्स में साझा किए जाते हैं, इसलिए आप Web और Android के लिए अलग-अलग व्यावसायिक ऑफ़र बनाए नहीं रखते।
surcharge सेट करें।चुने गए मॉडल के लिए नेटवर्क लागत, अधिभार और Builder की आय की तुलना करने के लिए Estimate का उपयोग करें। अगले अनुबंध संस्करण के रूप में समीक्षा किए गए ड्राफ्ट को प्रकाशित करें। ग्राहक प्राधिकरण के दौरान उस संस्करण को स्वीकार करते हैं; प्रकाशित ऑफ़र स्वीकृत ग्राहक समझौते के समान नहीं है।
यदि आपको केवल उत्पाद payments की आवश्यकता है, तो उपलब्ध मुफ्त भुगतान-एक्सेस अनुबंध प्रवाह का उपयोग करें बजाय इसके कि Builder मार्कअप का आविष्कार करें। वर्तमान उपयोग-ऑफ़र संपादक द्वारा निश्चित सदस्यता मूल्य और अंतराल कॉन्फ़िगर नहीं किए गए हैं; AI ऑफ़र को स्वचालित आवर्ती बिलिंग के रूप में व्याख्या न करें।
आपका ऑफर सटीक रूप से बताता है कि AI लागत में क्या जोड़ा गया है। ग्राहक-सामना करने वाली सहमति वही प्रकाशित शर्तें दिखाती है।
आप एक नया अनुबंध पेश करेंगे जबकि प्रत्येक खाते द्वारा स्वीकार की गई शर्तों का ट्रैक रखेंगे।
जहां आप काम करेंगे सदस्यताएँ → अनुबंध
अगले अनुबंध ड्राफ्ट में बदलाव तैयार करें। मौजूदा प्राधिकरण उनके स्वीकार किए गए सदस्यता और संस्करण को बनाए रखते हैं जब तक ग्राहक प्रतिस्थापन स्वीकार नहीं करता। सदस्यता अवलोकन में खाता गणना और वितरण की तुलना करें बजाय यह मानने के कि प्रत्येक खाता नवीनतम संस्करण का उपयोग करता है।
ग्राहकों को क्या बदलाव हैं बताएं और जब आवश्यक हो तो उन्हें नई शर्तें स्वीकार करने के लिए सहमति प्रवाह के माध्यम से भेजें। एक ताज़ा टोकन स्वीकृति का निर्माण नहीं कर सकता। स्वीकार किए गए अनुबंधों को बनाए रखना डिफ़ॉल्ट संक्रमण है। आगे की क्रियाओं से पहले नवीनीकृत सहमति की आवश्यकता चुनना जानबूझकर मौजूदा पहुंच को बाधित करता है जब तक ग्राहक नई शर्तों को मंजूरी नहीं देता; प्रकाशन से पहले उस प्रभाव की समीक्षा करें। किसी भी अनुमत कमी को स्वीकार किए गए अनुबंध के नियमों का पालन करना चाहिए; शुल्क वृद्धि के लिए ग्राहक की मंजूरी आवश्यक है।
एप्लिकेशन-स्तरीय दृश्य और पहचान सीमा को अलग रखें। प्लेटफ़ॉर्म-विशिष्ट ग्राहक पहचानकर्ता उनके क्लाइंट संदर्भ तक सीमित रहते हैं, भले ही वाणिज्यिक अवलोकन पूरे एप्लिकेशन को समेकित करता हो।
आप पहचान सकते हैं कि प्रत्येक खाते ने कौन सा अनुबंध स्वीकार किया और समझा सकते हैं कि यह अगले अनुबंध में कैसे स्थानांतरित हो सकता है।
आप एक इच्छित खरीद बनाएंगे, पुष्टि प्राप्त करेंगे और डिलीवरी से पहले भुगतान सत्यापित करेंगे।
जहां आप काम करेंगे आपका बैकएंड → ShareAI चेकआउट → भुगतान सत्यापन
यह अध्याय नियुक्ति उदाहरण को एक अलग उत्पाद खरीद के साथ विस्तारित करता है। इसे केवल भुगतान सक्षम करने और उस स्कोप के साथ ग्राहक टोकन प्राप्त करने के बाद चलाएं। ऑर्डर और भुगतान स्थिति को अपने बैकएंड पर बनाए रखें।
# Real payment request: use scoped test access and an intentional amount.
curl --fail-with-body 'https://api.shareai.now/api/v1/console/builder/payments' \
-H "Authorization: Bearer $SHAREAI_ACCESS_TOKEN" \
-H 'Content-Type: application/json' \
-H 'Idempotency-Key: YOUR_UNIQUE_ORDER_REFERENCE' \
--data '{"title":"JamZY appointment preparation pack","amount":"1.00"}'curl --fail-with-body --get \
'https://api.shareai.now/api/v1/console/builder/payments' \
-H "Authorization: Bearer $SHAREAI_ACCESS_TOKEN" \
--data-urlencode "id=$SHAREAI_PAYMENT_ID"| भुगतान स्थिति | आपका उत्पाद क्या करना चाहिए |
|---|---|
| लंबित | दिखाएं कि ग्राहक पुष्टि अभी भी आवश्यक है। अभी तक पूरा न करें। |
| भुगतान किए जाते हैं | अपने सर्वर के ऑर्डर के खिलाफ सत्यापित करें, फिर एक बार पूरा करें। |
| अस्वीकार किया गया | निर्णय का सम्मान करें; ग्राहक को यह चुनने दें कि क्या वह दूसरी खरीद का प्रयास करना चाहता है। |
| समाप्त | जब ग्राहक पुनः प्रयास करना चाहता है तो नई इडेम्पोटेंसी कुंजी के साथ एक नया अनुरोध बनाएं। |
भरोसेमंद API द्वारा लौटाए गए केवल चेकआउट URL का उपयोग करें, और इसे आपके इंटीग्रेशन की अनुमत गंतव्य नीति के खिलाफ सत्यापित करें। ऐप में वापसी-सफलता संदेश भुगतान का प्रमाण नहीं है। भुगतानकर्ता अपने स्वयं के Builder खाते से खरीदारी नहीं कर सकता।
यदि आप मौजूदा निश्चित-मूल्य सदस्यता अनुबंध का समर्थन करते हैं, तो भुगतान API इसकी स्वीकृत शर्तों का उपयोग स्पष्ट रूप से पुष्टि की गई अवधि के लिए कर सकता है। कोई काल्पनिक आवर्ती मूल्य न भेजें या नई अवधि को चुपचाप चार्ज न करें। JamZY का डाउनलोड करने योग्य अपॉइंटमेंट नमूना उस एक्सटेंशन को लागू नहीं करता है।
कोई ऑर्डर तब तक वितरित नहीं किया जाता जब तक आपका बैकएंड भुगतान सत्यापित नहीं करता, और पुष्टि प्रवाह को दोहराने से एक ही ऑर्डर को दो बार वितरित या डेबिट नहीं किया जा सकता।
आप क्रेडिट सीमाओं और डिसकनेक्शन को बिना डुप्लिकेट चार्ज या अप्रत्याशित खाता परिवर्तनों के संभालेंगे।
जहां आप काम करेंगे आपका एप्लिकेशन → बिलिंग रिकवरी
AI उपयोग और उत्पाद खरीद के लिए अलग-अलग पात्र-क्रेडिट नियम होते हैं। एक खाता AI-पात्र क्रेडिट्स रख सकता है जो किसी उत्पाद के लिए भुगतान नहीं कर सकते। API त्रुटि और ग्राहक बिलिंग गंतव्य का उपयोग करके अपर्याप्त धन और प्रति-एप्लिकेशन खर्च सीमा को संभालें।
ग्राहक को चुना हुआ भुगतान खाता, विफल हुई क्रिया और क्रेडिट्स या सीमाओं को प्रबंधित करने का मार्ग दिखाएं। ग्राहक अपने स्वयं के कैप को नियंत्रित करता है; ऐप मालिक इसे बढ़ा नहीं सकता। किसी संगठन से व्यक्तिगत खाते में चुपचाप स्विच न करें ताकि चार्ज सफल हो सके।
डिसकनेक्ट करने से संबंधित प्राधिकरण रद्द हो जाना चाहिए और स्थानीय सत्र साफ़ हो जाना चाहिए। यह भविष्य के प्राधिकृत अनुरोधों को रोकता है; यह पहले से पुष्टि की गई खरीद को पूर्ववत नहीं करता या स्वचालित रूप से अलग भुगतान प्रतिबद्धता को रद्द नहीं करता। रिफ्रेश विफलता, ग्रांट रद्दीकरण और भुगतान समाप्ति के लिए अलग-अलग रिकवरी संदेशों की आवश्यकता होती है।
अपर्याप्त-क्रेडिट और सीमा त्रुटियां ग्राहक को सूचित और नियंत्रण में छोड़ती हैं, बिना किसी आकस्मिक डुप्लिकेट ऑर्डर या भुगतानकर्ता परिवर्तन के।
आप सफल पथ और इसके विफलता मामलों का परीक्षण करेंगे इससे पहले कि प्लेटफ़ॉर्म को प्रकाशन में शामिल करें।
जहां आप काम करेंगे OAuth सेटिंग्स → सत्यापन
एप्लिकेशन-व्यापक टेस्टर रोस्टर और Builder से अलग पात्र भुगतान खाता का उपयोग करें। लंबित निमंत्रण सहित अधिकतम पांच टेस्टर स्थान होते हैं। प्रकाशन में शामिल प्रत्येक प्लेटफ़ॉर्म के लिए वास्तविक एंडपॉइंट और स्कोप सत्यापन पूरा करें।
inference या monetization_gateway के लिए सफल स्कोप्ड AI अनुरोध का परीक्षण करें और payments के लिए आवश्यक सफल भुगतान API कॉल का परीक्षण करें। एक भुगतान अनुरोध लंबित हो सकता है बिना डेबिट के; एक पूर्ण चेकआउट परीक्षण अतिरिक्त रूप से स्पष्ट पुष्टि और भुगतान को सत्यापित करता है।आपका इंटीग्रेशन स्वीकृत एक्सेस, स्वीकृत शर्तें, अनुरोधित भुगतान और पुष्टि किए गए भुगतान को अलग करता है, और प्रत्येक के लिए फेल्योर पाथ को संभालता है।
आवेदन करने से पहले उस व्यक्तिगत या संगठन खाते का चयन करें जो प्रोग्राम नामांकन का स्वामी होगा। संगठन सत्यापन से पहले आवेदन जमा कर सकते हैं, लेकिन केवल स्टाफ अनुमोदन से पहुंच सक्रिय नहीं होती। Console में ऑनबोर्डिंग चेकलिस्ट से संगठन ईमेल और कंपनी सत्यापन पूरा करें। अनुमोदित संगठन तब तक Pending verification में रहता है जब तक दोनों जांच पूरी नहीं हो जाती। Builder, Provider और Creator प्रोग्राम इस नियम का पालन करते हैं।
Monetization Gateway मूल्य निर्धारण देखें · अन्वेषण करें ShareAI for Startups · स्कोप और अनुमतियां
आपके सार्वजनिक Terms & Conditions, Privacy Policy और deletion निर्देशों को आवेदन से मेल खाना चाहिए और बिना साइन-इन के उपलब्ध रहना चाहिए। ShareAI प्रोग्राम स्वीकृति, Monetization Gateway अनुमोदन, ग्राहक की OAuth अनुमति और स्वीकृत बिलिंग अनुबंध अलग-अलग निर्णय हैं। Refresh नई अनुमतियाँ जोड़ नहीं सकता या नए व्यावसायिक शर्तों को स्वीकार नहीं कर सकता।
मौजूदा एकीकरणों के लिए पुरानी surcharge स्कोप स्वीकार की जाती है। नए उदाहरण monetization_gateway का उपयोग करते हैं। मौजूदा वायर फ़ील्ड जैसे surcharge_bps और surcharge_percentage को अपरिवर्तित रखें।
Monetization Gateway मूल्य निर्धारण देखें · अन्वेषण करें ShareAI for Startups · स्कोप और अनुमतियां
मानक शुल्क 5% Builder मार्कअप का है। AI नेटवर्क लागत के €2.00 और 10% मार्कअप के लिए, ग्राहक €2.20 का भुगतान करता है। ShareAI €0.01 €0.20 मार्कअप प्राप्त करता है; Builder के पास Event Ingestion से पहले €0.19 है।
पहले 1,000 निपटाए गए Production Monetization Gateway अनुरोध प्रत्येक कैलेंडर माह (UTC) में मुफ्त हैं, जो Builder खाते में साझा किए जाते हैं। अतिरिक्त अनुरोधों की लागत €0.04 प्रति 1,000 होती है, पात्र छूट से पहले। एक निपटाया गया अनुरोध एक घटना बनाता है।
Pay with ShareAI अपने आप में, केवल inference एक्सेस, साधारण खाता API कुंजियाँ और Staging या परीक्षण ट्रैफ़िक Monetization Gateway Event Ingestion को लागू नहीं करते।
ShareAI for Startups स्वीकृत एप्लिकेशन पर वास्तविक ShareAI शुल्क के लिए एक साझा मासिक भत्ता प्रदान करता है। वर्तमान लॉन्च, ग्रोथ और मोमेंटम टियर €1,000, €5,000 और €10,000 प्रति माह सूचीबद्ध करते हैं। वही बजट ShareAI के प्रतिशत शुल्क को Builder मार्कअप और बिल योग्य इवेंट इनजेशन के साथ कवर करता है। यह एक सकल-मार्कअप भत्ता, एक अलग मुफ्त-इवेंट कोटा या मुफ्त AI inference नहीं है। खाते के पहले 1,000 मुफ्त इवेंट इसे उपभोग नहीं करते।
शेष इवेंट इनजेशन शुल्क अनुरोध के नए Builder आय से भुगतान किए जाते हैं, फिर उपलब्ध Builder AI आय और अप्रतिबंधित AI क्रेडिट्स से। ग्राहक AI शुल्क और उत्पाद payments अलग रहते हैं।
ShareAI एक निश्चित अवधि के लिए या जब तक बदला न जाए, एप्लिकेशन-विशिष्ट शुल्क या शुल्क समर्थन को स्वीकृत कर सकता है। एप्लिकेशन की वर्तमान मूल्य निर्धारण और विशेष कार्यक्रमों की स्वीकृत शर्तों, वैधता और उपभोग किए गए भत्ते की समीक्षा कंसोल में करें। एक टियर परिवर्तन या मूल्य निर्धारण ओवरराइड एप्लिकेशन के मासिक उपयोग को रीसेट नहीं करता।
लॉन्च ShareAI के साथ लॉग इन को वैकल्पिक रखता है। ग्रोथ और मोमेंटम इसे आवश्यक बनाते हैं; मोमेंटम को एप्लिकेशन फुटर में आधिकारिक ShareAI for Startups बैज की भी आवश्यकता होती है। ShareAI साप्ताहिक रूप से बैज की जांच करता है। आवश्यकताओं को बायपास करने के पुष्ट प्रयासों से डिमोशन, स्टार्टअप प्रोग्राम से हटाने या स्वीकृत प्रोग्राम शर्तों के तहत मार्केटप्लेस से वापसी हो सकती है।
एंटरप्राइज़ दरें ShareAI टीम द्वारा Builder खाते के लिए एक व्यक्तिगत प्रस्ताव पर सहमति के बाद कॉन्फ़िगर की जाती हैं। आवंटित प्रतिशत और इवेंट दर भविष्य के अनुरोधों पर लागू होती है।
Monetization Gateway मूल्य निर्धारण देखें · अन्वेषण करें ShareAI for Startups · स्कोप और अनुमतियां