अपने ऐप में Payments कैसे जोड़ें: Checkout, Subscriptions और Webhooks

ऐप में भुगतान जोड़ने का सबसे सरल तरीका Stripe है: अगर आपको सिर्फ़ एक "Buy" button चाहिए और orders हाथ से संभाल सकते हैं, तो Payment Link इस्तेमाल करें; अगर आपके ऐप को यह जानना है कि किसने भुगतान किया और अपने आप प्रतिक्रिया देनी है, तो Stripe Checkout; और आवर्ती billing के लिए subscription mode में Checkout के साथ Stripe का customer portal। सबसे सरल वाले को छोड़कर हर स्थिति में आपको एक webhook भी चाहिए, यानी एक सर्वर endpoint जिसे Stripe भुगतान सफल होने पर call करता है, और live keys पर जाने से पहले हर चीज़ Stripe की test keys और test cards से टेस्ट करनी चाहिए।

यह गाइड हर विकल्प समझाती है, वह webhook वाला हिस्सा जिसे ज़्यादातर ट्यूटोरियल छोड़ देते हैं, और असली पैसा लेने से पहले क्या जाँचना है। Stripe का विवरण Stripe के अपने documentation से है, सितंबर 2026 तक के अनुसार।

भुगतान प्रदाता क्यों इस्तेमाल करें

कार्ड नंबर अपने फ़ॉर्म में कभी इकट्ठे न करें। कच्चा कार्ड डेटा संभालने से आप PCI DSS (कार्ड उद्योग का सुरक्षा मानक) के दायरे में आ जाते हैं और यह बड़ी ज़िम्मेदारी है। Stripe जैसा भुगतान प्रदाता भुगतान फ़ॉर्म होस्ट करता है, कार्ड सहेजता है, बैंक की प्रमाणीकरण प्रक्रिया संभालता है, और आपके ऐप को परिणाम बताता है। आपका ऐप केवल यह देखता है: "ग्राहक X ने Y के लिए भुगतान किया"।

यह गाइड Stripe इसलिए इस्तेमाल करती है क्योंकि वह व्यापक रूप से इस्तेमाल होता है, अच्छी तरह documented है, और ज़्यादातर AI app builders उसे सपोर्ट करते हैं। और भी प्रदाता हैं, और कुछ "merchant of record" के रूप में काम करते हैं, जो बिक्री tax की संभाल आपके लिए खुद लेते हैं; अगर tax का पालन आपको परेशान करता है, तो वह मॉडल तुलना के लायक है।

Stripe से भुगतान लेने के तीन तरीके

Payment Links

Payment Link एक Stripe-होस्टेड भुगतान पेज है जिसे आप Stripe Dashboard में बिना कोड के बनाते हैं। आपको एक URL मिलता है जिसे अपने ऐप में button के पीछे रख सकते हैं, email में साझा कर सकते हैं, या QR code के रूप में दिखा सकते हैं। Stripe के docs के अनुसार Payment Links एक उत्पाद, एक subscription बेच सकते हैं, या दान ले सकते हैं, और आप ग्राहकों को तय करने दे सकते हैं कि कितना भुगतान करना है, या खरीद की संख्या सीमित कर सकते हैं।

पकड़ यह है: आपका ऐप अपने आप नहीं जानता कि कोई खास logged-in user ने भुगतान किया है। दान पेज या छोटी दुकान के लिए, जहाँ आप Stripe के email notifications से हाथ से orders पूरे करते हैं, यह ठीक है। "Pro फ़ीचर खोलने के लिए भुगतान करें" के लिए यह ठीक नहीं है।

Stripe Checkout

Checkout एक भुगतान पेज है जिसे आपका सर्वर माँग पर किसी खास खरीद के लिए बनाता है। आपका सर्वर Stripe को बताता है कि क्या खरीदा जा रहा है (और चाहें तो कौन खरीद रहा है), Stripe एक URL लौटाता है, और आप ग्राहक को वहाँ भेजते हैं। Stripe के docs इसे एक-बार और subscription दोनों भुगतान सपोर्ट करने वाला बताते हैं, जो एक पूरा Stripe-होस्टेड पेज, आपकी साइट में एम्बेड किया हुआ पेज, या एम्बेडेड फ़ॉर्म हो सकता है।

प्रवाह:

1. ग्राहक आपके ऐप में Buy पर क्लिक करता है।
2. आपका सर्वर अपनी secret key से एक Checkout Session बनाता है, जिसमें एक ID होती है जो उसे आपके user या order से जोड़ती है।
3. ग्राहक को Stripe पर भेजा जाता है और वह भुगतान करता है।
4. Stripe उसे आपके success page पर वापस भेजता है।
5. Stripe आपके webhook को checkout.session.completed event भेजता है, और आपका सर्वर order को paid मार्क करता है या access खोलता है।

चरण 2 सर्वर पर होना ज़रूरी है, क्योंकि वह आपकी secret key इस्तेमाल करता है। Checkout को backend चाहिए, इसका यही मुख्य कारण है।

Subscriptions

Subscriptions Checkout के subscription mode का इस्तेमाल करते हैं, जिसमें Stripe में आपके सेट किए आवर्ती price होते हैं। पहला भुगतान ऊपर के प्रवाह जैसा काम करता है। उसके बाद renewals, विफल कार्ड, upgrades और cancellations समय के साथ होते हैं — अक्सर तब जब ग्राहक आपके ऐप में नहीं होता — इसलिए आपका ऐप इनके बारे में केवल webhooks के ज़रिए जानता है।

ग्राहकों को उनका अपना subscription संभालने देने के लिए Stripe एक होस्टेड customer portal देता है। Stripe के docs के अनुसार, ग्राहक वहाँ भुगतान के तरीके और billing विवरण अपडेट कर सकते हैं, subscriptions बदल या रद्द कर सकते हैं, और invoices देख व डाउनलोड कर सकते हैं। आप इसे Stripe Dashboard में कॉन्फ़िगर करते हैं और एक "Manage billing" button जोड़ते हैं जो ग्राहक को वहाँ भेजता है। इससे वे स्क्रीन ख़ुद बनाने की मेहनत बच जाती है।

Webhooks: वह हिस्सा जिसे आप छोड़ नहीं सकते

Webhook एक HTTP request है जो Stripe कुछ होने पर आपके सर्वर को भेजता है। (सामान्य विचार के लिए webhook क्या है देखें।) Stripe की fulfilment गाइड साफ़ कहती है: orders पूरे करने के लिए केवल success page पर भरोसा न करें, क्योंकि ग्राहक भुगतान कर सकता है और उस पेज के लोड होने से पहले उसका connection टूट सकता है। Subscriptions और देरी से होने वाले भुगतान तरीकों के लिए webhooks ज़रूरी हैं।

संभालने लायक events

सही webhook handler के नियम

ये सीधे Stripe के webhook documentation से हैं, और AI से बने handlers कभी-कभी इनमें से कोई चूक जाते हैं:

• Signature जाँचें। हर event में एक Stripe-Signature header होता है। आपका handler उसे endpoint की signing secret (जो whsec_ से शुरू होती है) से जाँचता है। इसके बिना कोई भी आपके सर्वर को नकली "भुगतान सफल" संदेश भेज सकता है।
• कच्चा request body इस्तेमाल करें। अगर आपका framework body को पहले parse या बदल दे, तो signature जाँच विफल होती है।
• जल्दी 2xx response लौटाएँ, फिर धीमा काम करें। Timeout विफलता गिने जाते हैं।
• Duplicates संभालें। Stripe एक ही event एक से ज़्यादा बार भेज सकता है। संसाधित event IDs दर्ज करें, या पूरा करने की प्रक्रिया को दो बार चलाना सुरक्षित बनाएँ।
• क्रम पर भरोसा न करें। Stripe गारंटी नहीं देता कि events उसी क्रम में आएँगे जिसमें वे हुए।
• दोबारा प्रयास की उम्मीद रखें। Live mode में Stripe विफल deliveries को तीन दिन तक दोबारा भेजता है, इसलिए छोटी रुकावट से भुगतान नहीं खोते — पर आपका handler देर से आए events को भी संभालना चाहिए।

Webhooks को एक सार्वजनिक HTTPS पते की ज़रूरत है, इसलिए वे आमतौर पर तभी काम करते हैं जब आपका ऐप publish हो (डेवलपर्स के लिए Stripe का CLI events को स्थानीय मशीन पर forward कर सकता है)।

पूरे प्रवाह के लिए एक prompt

"Pro pack" के लिए Stripe Checkout के साथ एक-बार की खरीद जोड़ो (price ID STRIPE_PRICE_ID में)। Checkout Session सर्वर पर बनाओ, secrets से STRIPE_SECRET_KEY इस्तेमाल करके, और session में logged-in user की ID शामिल करो। एक POST /api/stripe/webhook endpoint जोड़ो जो raw request body का इस्तेमाल करके STRIPE_WEBHOOK_SECRET से Stripe signature जाँचे, checkout.session.completed संभाले, और उस user को Pro pack वाला मार्क करे। अगर वही event दो बार आए तब भी यह सुरक्षित हो। Success और cancel पेज बनाओ। Secret key को कभी browser तक न पहुँचने दो।

Subscriptions के लिए जोड़ें: "STRIPE_PRICE_ID के साथ subscription mode इस्तेमाल करो। invoice.paid, invoice.payment_failed, customer.subscription.updated और customer.subscription.deleted संभालो। एक Manage billing button जोड़ो जो Stripe customer portal खोले।"

Test mode

Stripe के अलग sandbox (test) और live वातावरण हैं, जिनकी keys अलग हैं। Sandbox keys pk_test_, sk_test_ या rk_test_ से शुरू होती हैं; live keys pk_live_, sk_live_ या rk_live_ से। Test transactions से पैसा नहीं चलता।

Stripe के testing docs के उपयोगी test cards (कोई भी भविष्य की expiry तारीख, कोई भी तीन अंकों का CVC):

कम से कम ये टेस्ट करें:

• सफल भुगतान सही user के लिए सही चीज़ खोलता है
• अस्वीकृत कार्ड एक साफ़ संदेश दिखाता है और कुछ नहीं खोलता
• भुगतान के तुरंत बाद browser tab बंद करने पर भी access मिलता है (इससे साबित होता है कि webhook काम करता है, केवल success page नहीं)
• Stripe पेज पर रद्द करने पर user आपके ऐप में लौटता है और कुछ चार्ज नहीं होता
• Subscriptions के लिए: customer portal में रद्द करें और पुष्टि करें कि access सही समय पर खत्म होता है

लाइव होना

1. अपना Stripe account अपने व्यवसाय और बैंक विवरण के साथ सक्रिय करें।
2. ऐप के secrets में live keys बदलें। Stripe सामान्य secret key की जगह केवल उतनी permissions वाली restricted keys की सिफ़ारिश करता है जितनी आपके integration को चाहिए।
3. एक live webhook endpoint बनाएँ जो आपके published ऐप की ओर इशारा करे। उसकी अपनी signing secret होती है, जो test वाली से अलग है — उसे अपडेट करें।
4. Live mode में products और prices दोबारा बनाएँ; test mode के IDs वहाँ मौजूद नहीं हैं।
5. एक असली छोटी खरीद करें और उसका refund करें।

हर key अपने प्रोजेक्ट के secrets में रखें, कभी कोड या चैट में नहीं। हमारी सुरक्षा चेकलिस्ट keys और webhook verification को और विस्तार से समझाती है।

Tax, refunds और कागज़ी काम

भुगतान कुछ ऐसी ज़िम्मेदारियाँ लाते हैं जिन्हें कोड हल नहीं करता। यह tax सलाह नहीं है; किसी accountant से जाँचें।

• Sales tax, VAT और GST। इस पर निर्भर कि आप और आपके ग्राहक कहाँ हैं, आपको रजिस्टर करना, tax वसूलना और फ़ाइल करना पड़ सकता है। Stripe Tax checkout पर tax की गणना और वसूली कर सकता है, देख सकता है कि आपकी बिक्री कहाँ ज़िम्मेदारी बना सकती है, और रजिस्ट्रेशन व फ़ाइलिंग में मदद कर सकता है — पर ज़िम्मेदारी आपकी ही रहती है। Merchant-of-record प्रदाता एक विकल्प हैं जो इसका ज़्यादा हिस्सा ख़ुद लेते हैं।
• Refunds और विवाद। लॉन्च से पहले अपनी refund नीति तय करें और उसे अपनी साइट पर रखें। विवाद (chargebacks) होते हैं; क्या खरीदा और क्या दिया गया, उसका रिकॉर्ड रखें।
• रसीदें और invoices। Stripe रसीदें email कर सकता है; व्यवसायों को उचित invoices की ज़रूरत पड़ सकती है।
• फ़ीस। हर प्रदाता हर लेन-देन पर शुल्क लेता है। लेखों के आँकड़ों पर भरोसा करने की बजाय प्रदाता का मौजूदा pricing पेज देखें।

आपके ऐप के लिए कौन सा सेटअप सही है

• दान या कुछ गिने-चुने उत्पाद: Payment Links। देखें गैर-लाभकारी दान वेबसाइट कैसे बनाएँ।
• कार्ट वाली दुकान: line items और webhook के साथ Checkout। देखें ऑनलाइन स्टोर कैसे बनाएँ।
• SaaS या memberships: subscription mode में Checkout, webhooks और customer portal। देखें SaaS MVP कैसे बनाएँ और SaaS उत्पाद की कीमत कैसे तय करें।
• एक marketplace जो विक्रेताओं को भुगतान देता है: एक अलग, अधिक नियमित सेटअप (Stripe Connect या समान)। इसकी योजना अलग से बनाएँ।

Mythex में payments जोड़ना

Mythex पर बनाए ऐप्स में payments आपके अपने Stripe account और keys इस्तेमाल करते हैं; आपके ऐप के लिए "Connect Stripe" का एक-क्लिक विकल्प नहीं है। आम प्रवाह:

1. Stripe की test keys लें।
2. STRIPE_SECRET_KEY (और बाद में webhook secret) को प्रोजेक्ट secrets में जोड़ें — /secrets के ज़रिए, प्रोजेक्ट settings से, या उस secrets card से जो agent को key चाहिए होने पर दिखाता है।
3. ऊपर जैसे prompt से agent से Checkout माँगें।
4. Preview में test cards से टेस्ट करें। Webhook रजिस्टर करने से पहले publish करें, क्योंकि उसे आपका सार्वजनिक URL चाहिए।
5. Live keys पर बदलने के बाद, live ऐप उन्हें उठाए इसके लिए फिर से publish करें।

Docs में Stripe से भुगतान स्वीकार करें और अपने backend में webhooks संभालें देखें।

सवाल