अपना पहला payment लेना: अपने AI से बने app में असली पैसा जोड़ें, बिना गड़बड़ किए

एक ख़ास पल होता है जब एक AI से बना app एक खिलौना रहना बंद कर देता है और एक business बन जाता है: पहली बार जब उसमें से असली पैसा गुज़रता है। उस पल तक गलतियां सस्ती होती हैं। एक टूटा बटन झुंझलाहट है। किसी ऐसे screen पर गलत total जिसके लिए कोई pay नहीं करता, वो एक टाइपो है। पर जिस दिन किसी असली customer के card से charge होता है, एक गलती असल पैसे की होती है — आपके या उनके — और किसी charge को लेकर विवाद करने वाले से “AI ने इसे ऐसे ही बनाया” कहना वो वाक्य नहीं है जो आप कहना चाहेंगे।

अच्छी ख़बर: किसी AI से बने app में payments लेना जितना लगता है उससे ज़्यादा आसान है, अगर आप जानते हैं कि कौन-से हिस्से अपने AI builder को सौंपने हैं और कौन-से कभी खुद नहीं छूने। यह उसी रेखा की गाइड है।

वो एक नियम जो आपको सुरक्षित रखता है: card numbers कभी स्टोर मत करें

यहीं से शुरू करें, क्योंकि यही वो नियम है जिस पर बाकी सब टिका है। आपके app को कभी किसी कच्चे credit card number को देखना, स्टोर करना, या संभालना नहीं चाहिए। किसी database में नहीं, आपके बनाए किसी form में नहीं, “बस अस्थायी तौर पर” भी नहीं। card data को सीधे संभालना आप पर कानूनी और security ज़िम्मेदारियों का एक ढेर डाल देता है जो किसी पहली बार बनाने वाले को नहीं उठाना चाहिए।

इसके बजाय, आप एक payment provider इस्तेमाल करते हैं — Stripe आम वाला है, और ज़्यादातर AI app builders इसे अच्छे से जानते हैं। provider आपको एक पहले से बना हुआ, सुरक्षित payment form देता है। customer अपना card provider के form में टाइप करता है, provider उससे charge करता है, और आपके app को बस एक “हां, यह चुका दिया गया” वाला message मिलता है। आपके app को पता होता है कि payment हुआ। उसे कभी card number पता नहीं चलता।

जब आप अपने AI builder को payments जोड़ने को कहें, तो साफ़-साफ़ यह कहें: “Stripe Checkout (या Stripe का hosted payment form) इस्तेमाल करो ताकि मेरा app कभी कच्चा card data न संभाले।” अगर builder card-number field वाला कोई custom form बनाना शुरू करे, तो उसे रोकें। यही वो एक चीज़ है जो आप नहीं चाहते कि वो बनाए।

“payments जोड़ना” असल में किस-किस चीज़ का काम है

शुरू करने से पहले हिस्से जान लेना मददगार है, ताकि आप बता सकें कि कब कुछ छूट रहा है। एक चलते हुए payment flow के चार हिस्से होते हैं:

1. एक price. आप क्या charge कर रहे हैं, और क्या वो one-time है या recurring। यह आपके payment provider में रहता है, आपके app में hard-coded नहीं।
2. एक checkout step. वो बटन जिसे customer क्लिक करता है, जो उन्हें provider के सुरक्षित form पर भेजता है।
3. आपके app को वापस एक confirmation. payment के बाद, provider आपके app को बताता है “इस इंसान ने इस चीज़ के लिए pay किया।” यही वो हिस्सा है जिसे शुरुआती सबसे ज़्यादा छोड़ देते हैं — और इसे छोड़ना ही वो वजह है जिससे आपके पास ऐसे लोग आ जाते हैं जिन्होंने pay तो किया पर access नहीं मिला।
4. किसने किस चीज़ के लिए pay किया, इसका एक record. ताकि आपका app सही चीज़ unlock कर सके और ताकि आप बाद में जवाब दे सकें “क्या इस इंसान ने pay किया?”

अगर आपका AI builder आपको एक Pay बटन देता है जो card से charge करता है पर उसके बाद आपका app कुछ अलग नहीं करता, तो उसने हिस्सा 2 बना दिया और हिस्से 3 और 4 भूल गया। यह सबसे आम अधूरा-बना payment flow है, और यह काम करता हुआ दिखता है ठीक उस पल तक जब कोई customer pay करता है और उसे कुछ नहीं मिलता।

इसे अपने AI builder को कैसे बताएं

यह रहा एक prompt जो ऊपर के हिस्सों को कवर करता है:

Stripe Checkout का इस्तेमाल करके इस app में paid access जोड़ो। एक plan है: $19/month.

जब कोई logged-in user “Upgrade” क्लिक करे, उसे Stripe के hosted checkout page पर भेजो। कोई custom card form मत बनाओ — मेरे app को कभी card numbers नहीं संभालने चाहिए।

किसी सफल payment के बाद, उस user को database में “paid” के तौर पर मार्क करो और उनके लिए Reports page unlock करो। किसी असफल या रद्द किए गए payment के बाद, उन्हें एक message के साथ pricing page पर वापस ले जाओ।

कुछ भी unlock करने से पहले payment को server-side पर पक्का करने के लिए एक Stripe webhook इस्तेमाल करो — सिर्फ़ इस आधार पर unlock मत करो कि user किसी success page पर वापस उतरा।

वो आख़िरी पैराग्राफ़ ही वो है जो एक असली payment flow को एक कमज़ोर flow से अलग करता है। success page को access unlock करने देने का मतलब है कि जो कोई success page का पता जान ले, वो उसे मुफ़्त में unlock कर सकता है। webhook — Stripe से आपके app के backend तक एक सीधा, सत्यापित message — भरोसेमंद संकेत है। आपका AI builder इसे सेट करना जानता है; आपको बस इसका नाम लेकर मांगना है।

असली पैसे से पहले नकली पैसे से टेस्ट करें

Stripe (और ज़्यादातर providers) आपको एक test mode देते हैं जिसमें नकली card numbers होते हैं जो असली जैसा बर्ताव करते हैं — जिनमें ऐसे cards शामिल हैं जो सफल होते हैं, जो decline होते हैं, और जो errors पैदा करते हैं। इसका इस्तेमाल करें। किसी एक भी असली card के आपके app को छूने से पहले, हर रास्ते से गुज़रें:

• एक सफल payment। क्या सही चीज़ unlock हुई? क्या user का status बदलकर “paid” हुआ?
• एक decline हुआ card। क्या app ने इसे ढंग से संभाला, या उसने user को किसी टूटे screen पर अटका छोड़ दिया?
• एक रद्द किया गया checkout — user pay करने के बजाय “back” क्लिक करता है। क्या वो किसी समझदारी वाली जगह पर पहुंचे, अब भी बिना upgrade हुए?
• pay करना, फिर logout करके दोबारा login करना। क्या वो अब भी “paid” हैं? (यह उन apps को पकड़ता है जो सिर्फ़ मौजूदा session के लिए access unlock करते हैं और कल तक भूल जाते हैं।)

अपने AI builder से test card numbers मांगें, या उन्हें अपने provider के docs में देखें। “यह payment सफल होता है” के लिए एक आम test card वो है जो आपका builder मांगने पर आपको दे सकता है। चारों परिदृश्य चलाएं। decline-हुआ-card और रद्द-हुआ-checkout वाले रास्ते वो हैं जिन्हें AI builders सबसे ज़्यादा टूटा हुआ छोड़ देते हैं, क्योंकि happy path ही वो है जिसके लिए वो optimize करते हैं।

वो गलतियां जो असल पैसे की पड़ती हैं

कुछ ख़ास तरह की नाकामियां पहले payment flows के साथ बार-बार दिखती हैं:

webhook के बजाय success page पर unlock करना. ऊपर बताया गया, पर दोहराने लायक है क्योंकि यह महंगी वाली है। अगर आपका app उसी पल paid features unlock कर देता है जब user /success पर उतरता है, तो आप user के browser पर भरोसा कर रहे हैं कि वो इस बारे में ईमानदार होगा कि उन्होंने pay किया या नहीं। वो हमेशा नहीं होते। webhook पर unlock करें।

उन्होंने किस चीज़ के लिए pay किया, इसका कोई record न होना. अगर आपका app बस एक वैश्विक “paid: yes” flag पलट देता है, तो आप उसी पल मुश्किल में पड़ेंगे जब आपके पास एक से ज़्यादा plan हो, या कोई cancel करे, या आपको कोई refund देना पड़े। ख़ास चीज़ स्टोर करें: कौन-सा plan, कब, और उस payment के लिए provider की ID। आपको यह बाद में support सवालों के लिए चाहिए होगी।

यह भूलना कि subscriptions खत्म होते हैं. एक one-time payment आसान है: paid मतलब paid। एक recurring subscription लैप्स हो सकता है — card expire हो जाता है, अगले महीने payment fail हो जाता है। अगर आपका app सिर्फ़ “उन्होंने pay किया” के लिए सुनता है और कभी “उनका subscription खत्म हुआ” के लिए नहीं, तो आपके पास ऐसे लोग होंगे जो pay करना बंद करने के बाद भी मुफ़्त में access रखते हैं। अपने builder से कहें कि वो “subscription cancelled or payment failed” वाले message को भी संभाले, सिर्फ़ success को नहीं।

गलत रकम charge करना क्योंकि price दो जगह रहता है. अगर price आपके app के screen में लिखा है और आपके payment provider में सेट है, तो वो आख़िरकार आपस में बिछड़ जाएंगे, और किसी customer को $19 दिखेगा पर $29 charge होगा। price को एक जगह रखें — अपने provider में — और अपने app से वही दिखवाएं जो provider कहता है। एक ही सच्चाई का स्रोत।

live होने से पहले एक छोटा checklist

test mode से असली पैसे पर जाने से पहले:

• मेरे app में कोई field नहीं है जहां कोई कच्चा card number टाइप करे।
• payment किसी success page तक user के पहुंचने से नहीं, बल्कि provider से आए एक webhook से पक्का होता है।
• मैंने एक सफल payment, एक decline हुआ card, और एक रद्द हुआ checkout टेस्ट किया है — तीनों समझदारी से बर्ताव करते हैं।
• pay करने के बाद, logout के बाद और अगले दिन access खुला रहता है।
• मेरा app रिकॉर्ड करता है कि हर इंसान ने किस चीज़ के लिए pay किया, सिर्फ़ यह नहीं कि उन्होंने pay किया।
• अगर कोई subscription लैप्स होता है, तो access अपने आप हट जाता है।
• मैंने provider keys को test mode से live mode पर बदल दिया है (भूलना आसान है — आपका पहला असली customer test keys से टकराकर एक उलझाने वाला error पाता है)।

अगर हर डिब्बा टिक है, तो आप असली card के लिए तैयार हैं। अगर नहीं, तो यही आपके AI builder के साथ आपकी अगली बातचीत है — link शेयर करने से पहले, पहले विवाद के बाद नहीं।

जो सोच मदद करती है

पैसा आपके app का वो हिस्सा है जहां “काम करता हुआ दिखता है” और “सचमुच काम करता है” एक-दूसरे से सबसे दूर होते हैं। एक टूटा layout आपको फ़ौरन दिख जाता है। एक payment flow जो payment सत्यापित किए बिना access unlock कर देता है, परफ़ेक्ट दिखता है — जब तक कोई इसे भांप न ले और अपने दोस्तों को न बता दे।

तो payment flow को अपने AI से बने app का वो एक हिस्सा मानें जिसे आप किसी शक्की इंसान की तरह टेस्ट करें। बिना pay किए अंदर घुसने की कोशिश करें। इसे तोड़ने की कोशिश करें। pay करें और फिर अपना access खोने की कोशिश करें। अपने ही app को धोखा देने की कोशिश में जो 30 मिनट आप लगाते हैं, वो इस पर खरीदा गया सबसे सस्ता बीमा है।

---

कुछ ऐसा बनाने जा रहे हैं जिसमें payments जोड़ना है? अपने अगले AI builder session की शुरुआत पूरे flow को बताकर करें — price, checkout, webhook confirmation, और क्या unlock होता है — सब एक साथ, सिर्फ़ एक Pay बटन मांगने के बजाय। Pay बटन आसान 10% है। बाकी 90% वो है जो पैसे को ईमानदार रखता है।