ShareAI सह पैसे भरा, संमतीपासून चेकआउटपर्यंत

तुमचा ग्राहक काय पैसे देतो ते निवडा

तुम्ही खाते कनेक्ट करणे, AI वापरासाठी पैसे देणे आणि उत्पादन खरेदी पुष्टी करणे यामध्ये फरक कराल.

जिथे तुम्ही काम कराल तुमचा उत्पादन → पेमेंट अनुभव

Pay with ShareAI ग्राहकाला त्यांच्या निवडलेल्या ShareAI खात्याचा तुमच्या अनुप्रयोगात वापर करण्याची परवानगी देते. दोन वेगळ्या बिलिंग प्रवाह आहेत: स्वीकारलेल्या अधिकृततेखाली ग्राहक-प्रायोजित AI विनंत्या आणि ग्राहकाने चेकआउटमध्ये पुष्टी केलेली उत्पादन खरेदी. पर्यायी Builder मार्कअप हा AI वापरावर अतिरिक्त करार आहे.

JamZY · अपॉइंटमेंट संदर्भ अ‍ॅप्लिकेशन स्क्रीनशॉट मोठा करा ↗

JamZY चा अपॉइंटमेंट नमुना AI वापर मार्ग दाखवतो. यात कोणतेही व्यापारी चेकआउट नाही, पेमेंट्स स्कोपची विनंती करत नाही आणि कनेक्टिंगने सदस्यता खरेदी केली असा दावा करत नाही. तुम्ही ती स्वतंत्र अनुभव जोडताना उर्वरित अध्याय वापरा.

ग्राहकाची अधिकृतता मिळवा

एखाद्या ऑपरेशनने वापरण्यापूर्वी तुम्ही इच्छित देणगीदार खात्याची परवानगी मिळवाल.

जिथे तुम्ही काम कराल कन्सोल → वापर प्रकरणे → ग्राहक अधिकृतता

1. अ‍ॅप तयार करा आणि ऑनबोर्डिंग, सार्वजनिक माहिती आणि प्लॅटफॉर्म कॉलबॅक पूर्ण करा. कन्सोलमध्ये संबंधित वापर प्रकरणे सक्षम करा.
2. Builder मार्कअपसाठी, त्याचा प्रवेश विनंती पूर्ण करा आणि आवश्यक असल्यास मंजुरीची प्रतीक्षा करा. खरेदीसाठी, Pay with ShareAI सक्षम करा आणि Subscriptions मध्ये आवश्यक पेमेंट-अॅक्सेस करार कॉन्फिगर करा.
3. Authorization Code + S256 PKCE द्वारे सक्षम स्कोप्सची विनंती करा. उत्पादन चेकआउटसाठी payments, नेटवर्क खर्चावर AI साठी inference, आणि मंजूर AI मार्कअपसाठी monetization_gateway वापरा. अनुप्रयोग प्रत्यक्षात वापरतो त्या क्षमतांसाठीच विनंती करा.
4. ग्राहकाने योग्य वैयक्तिक किंवा संघटन खाते निवडावे आणि प्रदर्शित अटी स्वीकाराव्यात. अतिरिक्त स्कोप्स किंवा बदललेल्या अटींसाठी पुन्हा अधिकृतता आवश्यक आहे; रिफ्रेश त्यांना मंजूर करत नाही.

वापर प्रकरणे स्क्रीनशॉट मोठा करा ↗

क्लायंट ID प्लॅटफॉर्म ओळखतो. अ‍ॅक्सेस टोकन स्वीकारलेल्या ग्राहक अधिकृततेचे प्रतिनिधित्व करते. करार आवृत्ती बिलिंग अटी नोंदवते. यापैकी कोणतेही एकटेच विशिष्ट उत्पादन पेमेंट पुष्टी झाले आहे हे सिद्ध करत नाही.

तुमच्या AI शुल्काची ऑफरमध्ये स्पष्ट करा

तुम्ही ग्राहक पुनरावलोकन करू शकतील आणि स्वीकारू शकतील अशा स्पष्ट वापर अटी प्रकाशित कराल.

जिथे तुम्ही काम कराल अनुप्रयोग → सदस्यता

Subscriptions मध्ये स्पष्टपणे नाव दिलेली ऑफर्स तयार करा आणि अतिरिक्त AI शुल्क स्पष्ट करा. सदस्यता ID तयार केली जाते, फक्त-वाचनयोग्य आणि तुमच्या अ‍ॅपसाठी स्कोप केलेली असते. या ऑफर्स अ‍ॅपच्या प्लॅटफॉर्म क्लायंट्समध्ये सामायिक केल्या जातात, त्यामुळे तुम्ही वेब आणि अँड्रॉइडसाठी वेगळी व्यावसायिक ऑफर राखत नाही.

सदस्यता · विहंगावलोकन स्क्रीनशॉट मोठा करा ↗

सदस्यता · ऑफर संपादक स्क्रीनशॉट मोठा करा ↗

निवडलेल्या मॉडेलसाठी नेटवर्क खर्च, अधिभार आणि Builder उत्पन्नाची तुलना करण्यासाठी Estimate वापरा. पुनरावलोकन केलेला मसुदा पुढील करार आवृत्ती म्हणून प्रकाशित करा. ग्राहक अधिकृततेदरम्यान ती आवृत्ती स्वीकारतात; प्रकाशित ऑफर स्वीकारलेल्या ग्राहक करारासारखी नसते.

जर तुम्हाला फक्त उत्पादन payments आवश्यक असेल, तर Builder मार्कअप तयार करण्याऐवजी उपलब्ध फ्री पेमेंट-अॅक्सेस करार प्रवाह वापरा. निश्चित सदस्यता किंमती आणि कालावधी सध्याच्या वापर-ऑफर संपादकाद्वारे कॉन्फिगर केले जात नाहीत; AI ऑफरला स्वयंचलित पुनरावृत्ती बिलिंग म्हणून समजू नका.

ग्राहकांना नवीन अटी निवडू द्या

तुम्ही नवीन करार सादर कराल आणि प्रत्येक खात्याने स्वीकारलेल्या अटींचा मागोवा ठेवाल.

जिथे तुम्ही काम कराल सदस्यता → करार

पुढील करार मसुद्यात बदल तयार करा. विद्यमान अधिकृतता त्यांच्या स्वीकारलेल्या सदस्यता आणि आवृत्ती कायम ठेवते जोपर्यंत ग्राहक बदल स्वीकारत नाही. सदस्यता विहंगावलोकनात खाते संख्या आणि वितरणांची तुलना करा, प्रत्येक खाते नवीनतम आवृत्ती वापरते असे गृहीत धरू नका.

सदस्यता · करार स्क्रीनशॉट मोठा करा ↗

ग्राहकांना काय बदलले आहे ते सांगा आणि आवश्यक असल्यास नवीन आवृत्ती स्वीकारण्यासाठी त्यांना संमती प्रवाहातून पाठवा. रीफ्रेश केलेला टोकन स्वीकृती तयार करू शकत नाही. स्वीकारलेले करार ठेवणे हे डीफॉल्ट संक्रमण आहे. नवीन अटी मंजूर करण्यापूर्वी पुढील क्रिया करण्यासाठी नूतनीकरण संमती आवश्यक असल्याचे निवडणे विद्यमान प्रवेशात जाणीवपूर्वक व्यत्यय आणते; प्रकाशनापूर्वी त्या परिणामाचे पुनरावलोकन करा. कोणत्याही परवानगी दिलेल्या कपातीला स्वीकारलेल्या कराराच्या नियमांचे पालन करणे आवश्यक आहे; शुल्क वाढवण्यासाठी ग्राहकाच्या मंजुरीची आवश्यकता आहे.

अनुप्रयोग-स्तरीय दृश्य आणि ओळख सीमा वेगळ्या ठेवा. व्यासपीठ-विशिष्ट ग्राहक ओळखकर्ता त्यांच्या क्लायंट संदर्भात मर्यादित राहतात जरी व्यावसायिक विहंगावलोकन संपूर्ण अनुप्रयोग एकत्रित करते.

पूर्ण करण्यापूर्वी खरेदी पुष्टी करा

तुम्ही एक इच्छित खरेदी तयार कराल, पुष्टी मिळवाल आणि वितरणापूर्वी पेमेंट सत्यापित कराल.

जिथे तुम्ही काम कराल तुमचा backend → ShareAI checkout → Payment verification

हा अध्याय नियुक्ती उदाहरणास स्वतंत्र उत्पादन खरेदीसह विस्तारित करतो. पेमेंट सक्षम केल्यानंतर आणि त्या स्कोपसह ग्राहक टोकन प्राप्त केल्यानंतरच ते चालवा. ऑर्डर आणि पेमेंट स्थिती तुमच्या backend वर ठेवा.

# 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"}'

1. परत आलेला पेमेंट ID आणि checkout URL ऑर्डरसह सेव्ह करा. अचूक दशांश रक्कम स्ट्रिंग वापरा; फ्लोटिंग-पॉइंट पैसे गणना टाळा.
2. परत आलेला checkout URL उघडा. ShareAI खरेदी आणि देणगीदार सादर करते. ग्राहकाने तुमच्या अॅपला अधिकृत केलेल्या खात्याचा वापर करून पुष्टी करणे आवश्यक आहे. checkout उघडणे त्याला डेबिट करत नाही.
3. समान ग्राहक अधिकृततेसह API मधून पेमेंट वाचा. सत्यापित स्थिती paid झाल्यानंतरच ऑर्डर पूर्ण करा.
4. समान idempotency key सह समान इच्छित खरेदी पुन्हा प्रयत्न करा. वेगळी खरेदीसाठी नवीन key आवश्यक आहे. बदललेल्या अटींसाठी key पुन्हा वापरू नका.

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 पेक्षा वेगळे पात्र पेमेंट खाते वापरा. प्रलंबित आमंत्रणांसह पाच परीक्षक जागा आहेत. प्रकाशनात समाविष्ट केलेल्या प्रत्येक प्लॅटफॉर्मसाठी वास्तविक एंडपॉइंट आणि स्कोप पडताळणी पूर्ण करा.

वेब · Verification स्क्रीनशॉट मोठा करा ↗

1. अधिकृतता स्वीकारलेली आणि रद्द केलेली चाचणी करा; निवडलेल्या ग्राहक/खाते सीमा पुष्टी करा.
2. inference किंवा monetization_gateway साठी यशस्वी स्कोप्ड AI विनंती आणि payments साठी आवश्यक यशस्वी पेमेंट API कॉलची चाचणी करा. पेमेंट विनंती डेबिटशिवाय प्रलंबित असू शकते; पूर्ण चेकआउट चाचणी अतिरिक्तपणे स्पष्ट पुष्टीकरण आणि देयक सत्यापित करते.
3. डुप्लिकेट विनंत्या, नाकारलेले आणि कालबाह्य चेकआउट, अपुरी पात्र क्रेडिट्स, खाते खर्च मर्यादा, कालबाह्य टोकन, रीफ्रेश रोटेशन आणि रद्द केलेली अधिकृतता चाचणी करा.
4. परिणामी ग्राहक, स्वीकारलेल्या अटी आणि श्रेय दिलेली क्रियाकलापांसाठी ग्राहक, सबस्क्रिप्शन आणि अ‍ॅनालिटिक्स तपासा. संवेदनशील क्रेडेन्शियल्स आणि अंतर्गत संस्था IDs ग्राहक-सामना करणाऱ्या UI मध्ये दिसत नाहीत याची पुष्टी करा.
5. फक्त त्या प्लॅटफॉर्म्सचा समावेश करा ज्यांची कॉन्फिगरेशन आणि नोंदवलेली तपासणी यशस्वी झाली आहे. अपूर्ण प्लॅटफॉर्म्स वगळा किंवा त्यांना काढून टाका; नंतर डॅशबोर्डमधून अ‍ॅप सबमिट करा.

संस्था पडताळणी आणि प्रोग्राम प्रवेश

अर्ज लागू करण्यापूर्वी कार्यक्रम नोंदणीचे मालक असलेले वैयक्तिक किंवा संघटन खाते निवडा. संघटना सत्यापनापूर्वी अर्ज सादर करू शकतात, परंतु फक्त कर्मचारी मंजुरी प्रवेश सक्रिय करत नाही. Console मधील ऑनबोर्डिंग चेकलिस्टमधून संघटन ईमेल आणि कंपनी सत्यापन पूर्ण करा. मंजूर संघटना दोन्ही तपासण्या पूर्ण होईपर्यंत Pending verification राहते. Builder, Provider आणि Creator कार्यक्रम या नियमाचे पालन करतात.

Monetization Gateway किंमत पहा · ShareAI for Startups अन्वेषण करा · स्कोप्स आणि परवानग्या

परवानग्या आणि स्वीकारलेल्या अटी

तुमचे सार्वजनिक Terms & Conditions, Privacy Policy आणि विलोपन सूचना अर्जाशी जुळले पाहिजेत आणि साइन-इनशिवाय सहज उपलब्ध असले पाहिजेत. ShareAI प्रोग्राम स्वीकारणे, Monetization Gateway मंजुरी, ग्राहकाचे OAuth परवानगी आणि स्वीकारलेला बिलिंग करार हे स्वतंत्र निर्णय आहेत. रीफ्रेश करताना परवानग्या जोडता येत नाहीत किंवा नवीन व्यावसायिक अटी स्वीकारता येत नाहीत.

जुना surcharge स्कोप विद्यमान एकत्रीकरणांसाठी स्वीकारला जातो. नवीन उदाहरणे monetization_gateway वापरतात. surcharge_bps आणि surcharge_percentage सारख्या विद्यमान वायर फील्ड्स अपरिवर्तित ठेवा.

Monetization Gateway किंमत पहा · ShareAI for Startups अन्वेषण करा · स्कोप्स आणि परवानग्या

गेटवे शुल्क आणि Startup समर्थन

5% च्या मानक शुल्कांमध्ये Builder मार्कअपचा समावेश आहे. AI नेटवर्क खर्चाच्या €2.00 आणि 10% मार्कअपसाठी ग्राहक €2.20 भरतो. ShareAI ला €0.01 मिळते €0.20 मार्कअपमधून; Builder कडे Event Ingestion पूर्वी €0.19 असते.

पहिल्या 1,000 स्थिर उत्पादन Monetization Gateway विनंत्या प्रत्येक कॅलेंडर महिन्यात (UTC) मोफत असतात, Builder खात्यामध्ये सामायिक केल्या जातात. अतिरिक्त विनंत्यांची किंमत €0.04 प्रति 1,000 आहे, पात्र सवलतींपूर्वी. एक स्थिर विनंती एक इव्हेंट तयार करते.

Pay with ShareAI स्वतःच, फक्त inference प्रवेश, सामान्य खाते API कीज आणि Staging किंवा चाचणी ट्रॅफिकवर Monetization Gateway Event Ingestion लागत नाही.

ShareAI for Startups मंजूर अर्जासाठी प्रत्यक्ष ShareAI शुल्कासाठी एक सामायिक मासिक भत्ता देते. सध्याचे Launch, Growth आणि Momentum स्तर €1,000, €5,000 आणि €10,000 प्रति महिना सूचीबद्ध करतात. समान बजेट ShareAI च्या टक्केवारी शुल्कावर Builder मार्कअप आणि बिल करण्यायोग्य इव्हेंट इनजेशन एकत्र कव्हर करते. हे एक ग्रॉस-मार्कअप भत्ता, स्वतंत्र फ्री-इव्हेंट कोटा किंवा फ्री AI inference नाही. खात्याचे पहिले 1,000 फ्री इव्हेंट याचा वापर करत नाहीत.

उर्वरित इव्हेंट इनजेशन शुल्क विनंतीच्या नवीन Builder कमाईतून भरले जाते, त्यानंतर उपलब्ध Builder AI कमाई आणि अनियंत्रित AI क्रेडिट्स. ग्राहक AI शुल्क आणि उत्पादन payments स्वतंत्र राहतात.

ShareAI अर्ज-विशिष्ट शुल्क किंवा शुल्क समर्थन निश्चित कालावधीसाठी किंवा बदल होईपर्यंत मंजूर करू शकते. अर्जाच्या सध्याच्या किंमती आणि Console मधील Special Programs त्याच्या मंजूर अटी, वैधता आणि वापरलेल्या भत्त्यासाठी पुनरावलोकन करा. स्तर बदल किंवा किंमत ओव्हरराइड अर्जाच्या मासिक वापराला रीसेट करत नाही.

Launch ShareAI सह लॉग इन वैकल्पिक ठेवते. Growth आणि Momentum यासाठी ते आवश्यक आहे; Momentum ला अर्जाच्या फूटरसाठी अधिकृत ShareAI for Startups बॅज देखील आवश्यक आहे. ShareAI आठवड्याला बॅज तपासते. आवश्यकता टाळण्याचे पुष्टीकरण केलेले प्रयत्न Startup Program मधून पदावनती, काढून टाकणे किंवा स्वीकारलेल्या प्रोग्राम अटींनुसार Marketplace मधून माघार घेण्यास कारणीभूत ठरू शकतात.

एंटरप्राइझ दर ShareAI टीमद्वारे Builder खात्यासाठी वैयक्तिकृत ऑफर मान्य केल्यानंतर कॉन्फिगर केले जातात. नियुक्त टक्केवारी आणि इव्हेंट दर भविष्यातील विनंत्यांवर लागू होतो.

Monetization Gateway किंमत पहा · ShareAI for Startups अन्वेषण करा · स्कोप्स आणि परवानग्या