- "आप Stripe को कितना भुगतान कर रहे हैं?"
- कई SaaS संस्थापकों से पूछा गया, तो सबने अलग-अलग जवाब दिया: लगभग 4~8%
- बेस प्राइस "2.9% + 30 सेंट" है, लेकिन Stripe के 20 से अधिक अतिरिक्त प्रोडक्ट होने की वजह से यह जटिल हो जाता है
उदाहरण 1: B2B SaaS
- Stripe के SaaS उदाहरण पेज पर मौजूद काल्पनिक कंपनी "Typographic" के आधार पर गणना करें तो
Billing + Quote + Checkout + Payments + Invoicing + Tax + Revenue Recognition + Data Pipeline का उपयोग मानने पर
- राजस्व का 4.2% + $0.33 (प्रति ट्रांजैक्शन) + $10/माह
- यह केवल कार्ड के आधार पर गणना है। बैंक ट्रांसफर या SEPA Debits जैसे अन्य पेमेंट मेथड पर अतिरिक्त शुल्क लगता है
उदाहरण 2: Vertical SaaS
- Toast, Mindbody जैसी किसी खास vertical के लिए बने SaaS के पास 2 revenue streams होते हैं
- मानक SaaS Pricing: subscription cost और usage-based pricing
- ऑनबोर्ड किए गए merchants की बिक्री पर आधारित शुल्क (Mindbody के मामले में, yoga studio द्वारा किए गए भुगतान का 2% लिया जाता है)
- उदाहरण 1 वाली कंपनी की तरह ही Stripe प्रोडक्ट्स का उपयोग होता है, लेकिन अतिरिक्त रूप से Stripe Connect भी चाहिए (ऑनबोर्ड merchants को भुगतान redirect करने की सुविधा)
- Stripe Connect के लिए प्रति active account $2/माह देना होता है, और ट्रांजैक्शन लागत के रूप में अतिरिक्त 0.25% + $0.25 देना पड़ता है
Stripe की अप्रत्यक्ष लागत
- ऊपर बताए गए प्रोडक्ट्स प्रत्यक्ष लागत हैं, और अप्रत्यक्ष लागत अलग है
- Stripe बाज़ार का सबसे बेहतरीन payment processing API हो सकता है, लेकिन इसे लागू करने के लिए engineering resources की ज़रूरत होती है
- केवल Stripe Payments ही नहीं, बल्कि billing, invoicing, checkout जैसे प्रोडक्ट्स का उपयोग करने के लिए business process और pricing model को इनके अनुरूप ढालना पड़ता है
- इसके अलावा Stripe को किराया (Rent) भी देना पड़ता है
- Billflow नाम का एक solution था जो Stripe का उपयोग आसान बनाता था, लेकिन उसे भी Stripe ने अधिग्रहित कर लिया
- उसका pricing model भी Stripe जैसा ही था, यानी राजस्व का एक हिस्सा percentage के रूप में लिया जाता था
- Grow प्लान ($1M~$3M ARR) के लिए $350/माह + राजस्व का 0.5%
- Scale प्लान ($3M+ ARR) के लिए $1200/माह + राजस्व का 0.2%
- Stripe के अधिकांश प्रोडक्ट्स... केवल दूसरे Stripe प्रोडक्ट्स के साथ ही उपयोग किए जा सकते हैं
अगर आप सिर्फ Stripe प्रोडक्ट्स पर निर्भर हैं, तो switching cost बढ़ जाती है
- Stripe पर निर्भरता जितनी बढ़ती है, शुल्क पर मोलभाव करना उतना मुश्किल हो जाता है
- payment solution बदलना कष्टदायक है, और अगर आप अभी Stripe Payments उपयोग कर रहे हैं तथा billing के लिए Stripe Billing इस्तेमाल कर रहे हैं, तो कोई दूसरा payment method जोड़ना संभव नहीं होता
- Stripe यह जानता है, इसलिए उसके लिए कीमत बढ़ाना संभव है, और उन चीज़ों पर भी अलग शुल्क लगाना संभव है जो पहले Stripe Payments में शामिल थीं
- कई ग्राहक Stripe के साथ शुल्क पर बातचीत करने की कोशिश करते हैं, लेकिन यह बहुत जटिल प्रक्रिया है और कॉन्ट्रैक्ट में आमतौर पर multi-year commitment होता है
- धीरे-धीरे अधिक टीमें Stripe के साथ अपने संबंध में जोखिम कम करने की कोशिश कर रही हैं
- अलग PG(Payment Gateway) जोड़कर शुल्क को नियंत्रित करना और स्वस्थ प्रतिस्पर्धा को बढ़ावा देना: Primer या Inai जैसे solutions
- billing के नज़रिए से, कई payment systems से जुड़ सकने वाला solution और उसे सपोर्ट करने वाला invoicing तथा analytics software विकसित करना एक मज़बूत Financial Stack बनाने में मदद करेगा
- Stripe की बहुत प्रशंसा है, लेकिन उसके बंद ecosystem मॉडल से संतुष्टि नहीं है
- इसलिए हमने open source Billing API Lago बनाने का फैसला किया
4 टिप्पणियां
सबसे बड़ा सवाल यही होगा कि क्या इसे कोरिया में लागू किया जा सकेगा या नहीं,, अफ्रीका के Nigeria में भी Stripe payment service जोड़ दी गई थी, लेकिन कोरिया आखिर किस तरह का देश है हाहा
अच्छा लेख, धन्यवाद। इस बात से सहमत हूँ कि इसे तटस्थ नज़रिए से देखना चाहिए। सचमुच, जैसे-जैसे SaaS बाज़ार जटिल होता जा रहा है, solutions की positioning भी काफ़ी बदलती दिख रही है.
Iamport, Bootpay जैसी services की बदौलत payment integration पिछले 10 सालों में काफ़ी आसान हुई है। NICEPAY जैसी PG कंपनियाँ भी खतरा महसूस करने के बाद धीरे-धीरे आसान process अपना रही हैं, इसलिए आजकल एक PG को integrate करना बहुत आसान हो गया है। पहले एक integration करने में 2 हफ्ते +@ लग जाते थे, इसलिए इसकी ज़रूरत काफ़ी थी, लेकिन अब जब यह जल्दी जुड़ जाता है, तो लगता है कि payment integration services के ज़रिए मिलने वाला फायदा आगे चलकर और कम होता जाएगा.
देश में भी अलग-अलग positioning वाली कई services सामने आ रही हैं, इसलिए लगता है कि बाज़ार अगले बदलाव के दौर में है। API-आधारित commerce building solution Clayful का आना भी इसी का हिस्सा था। Stripe जैसी subscription-specialized payment service StepPay भी सामने आई है। यह recurring payments, billing, invoice जैसी कई features को support कर रही है.
घरेलू बाज़ार की प्रकृति को देखते हुए payment की जटिलता कई मामलों में विदेशों से अलग है, इसलिए आगे यह किस दिशा में जाएगा, यह जानने की उत्सुकता है.
Stripe की समस्याओं की ओर इशारा करते हुए, यह समझाने वाला लेख है कि उन्होंने (Lago) आखिर open source billing API क्यों बनाया।
यानि, यह लेख खुद भी अपने प्रचार के लिए है, इसलिए इस पर पूरी तरह भरोसा न करें और तटस्थ नज़रिए से देखें.
HN में यह बात भी आई कि इस लेख को थोड़ा बढ़ा-चढ़ाकर पेश किया गया है, और Stripe के एक कर्मचारी ने आकर अतिरिक्त स्पष्टीकरण भी छोड़ा है.
https://news.ycombinator.com/item?id=33920019
खैर, कोरिया में card के अलावा cultural gift certificates और तरह-तरह के Pay विकल्पों के कारण चीज़ें काफ़ी जटिल रूप से जुड़ी हुई हैं, इसलिए वहाँ की स्थिति इससे अलग है..
लेकिन fee negotiation वाला हिस्सा काफ़ी मिलता-जुलता है. एक ही PG company इस्तेमाल करने की बजाय, कई कंपनियाँ इस्तेमाल करना fee negotiation में ज़्यादा फायदेमंद होता है.
कभी-कभी payment provider की समस्या की वजह से payment failure भी हो सकता है, इसलिए इसे redundancy के तौर पर देखने का मतलब भी है.
बेशक, ऐसे मामले में हर PG company के हिसाब से processing संभव हो, इसके लिए internal system बनाना पड़े तो engineering effort बहुत लगता है..
ऐसा विकल्प कब चुनना है और development कब करना है, यह सोच-समझकर तय करना चाहिए.
पहले की कंपनी में payment methods को सब अलग-अलग जोड़ने में काफ़ी मशक्कत हुई थी, लेकिन आजकल Iamport जैसी चीज़ें हैं, इसलिए कम-से-कम पहले से काफ़ी आसान हो गया है.
मुझे लगता है कि अगर आप विदेशी ग्राहकों को लक्ष्य करके वैश्विक सेवा देना चाहते हैं, तो Stripe जैसा कुछ नहीं है.
Toss Payments का UI भी सच में इतना simple नहीं है ~