دریافت اولین پرداخت: افزودن پول واقعی به اپ ساختهشده با هوش مصنوعی بدون اشتباه کردن
افزودن پرداخت به اپ ساختهشده با هوش مصنوعی، همان لحظهای است که سرگرمی به کسبوکار تبدیل میشود. این چیزی است که چطور به آن فکر کنید — چه چیزی را به اپساز هوش مصنوعیتان بسپارید، چه چیزی را هرگز خودتان نسازید، و چطور پیش از آنکه یک کارت واقعی به آن برسد آزمایشش کنید.
یک لحظهٔ مشخص وجود دارد که در آن یک اپ ساختهشده با هوش مصنوعی دیگر اسباببازی نیست و به یک کسبوکار تبدیل میشود: اولین باری که پول واقعی از میان آن جابهجا میشود. تا آن نقطه، اشتباهها ارزاناند. یک دکمهٔ خراب آزاردهنده است. یک مجموع اشتباه روی صفحهای که هیچکس بابتش پول نمیدهد، یک تایپو است. اما روزی که کارت یک مشتری واقعی شارژ میشود، یک اشتباه پول واقعی هزینه میبرد — مال شما یا مال او — و «هوش مصنوعی اینطوری ساختش» جملهای نیست که بخواهید به کسی که در حال اعتراض به یک پرداخت است بگویید.
خبر خوب: دریافت پرداخت در یک اپ ساختهشده با هوش مصنوعی از آن چیزی که به نظر میرسد در دسترستر است، به شرطی که بدانید کدام بخشها را به اپساز هوش مصنوعیتان بسپارید و کدام بخشها را هرگز خودتان دست نزنید. این راهنمایی است دربارهٔ همان خط.
آن یک قاعدهای که شما را در امان نگه میدارد: هرگز شمارهٔ کارت را ذخیره نکنید
از اینجا شروع کنید، چون این قاعدهای است که هر چیز دیگری به آن آویزان است. اپ شما هرگز نباید یک شمارهٔ خام کارت اعتباری را ببیند، ذخیره کند یا با آن کار کند. نه در یک پایگاه داده، نه در فرمی که خودتان ساختید، نه «فقط موقتاً». کار کردن مستقیم با دادهٔ کارت، یک کوه از تعهدات حقوقی و امنیتی روی دوش شما میریزد که هیچ سازندهٔ تازهکاری نباید آن را بر دوش بکشد.
بهجای آن، از یک ارائهدهندهٔ پرداخت استفاده میکنید — Stripe رایجترین است، و بیشتر اپسازهای هوش مصنوعی آن را خوب میشناسند. ارائهدهنده یک فرم پرداخت امن و ازپیشساخته به شما میدهد. مشتری کارتش را در فرمِ ارائهدهنده تایپ میکند، ارائهدهنده آن را شارژ میکند، و اپ شما فقط یک پیام «بله، این پرداخت شد» دریافت میکند. اپ شما میداند که پرداخت اتفاق افتاده. هرگز شمارهٔ کارت را نمیداند.
وقتی به اپساز هوش مصنوعیتان میگویید پرداخت اضافه کند، این را صریح بگویید: «از Stripe Checkout (یا فرم پرداخت میزبانیشدهٔ Stripe) استفاده کن تا اپ من هرگز با دادهٔ خام کارت کار نکند.» اگر اپساز شروع به تولید یک فرم سفارشی با فیلد شمارهٔ کارت کرد، متوقفش کنید. این آن یک چیزی است که نمیخواهید بسازد.
«افزودن پرداخت» واقعاً شامل چه چیزی است
مفید است که پیش از شروع، اجزای متحرک را بشناسید، تا بتوانید تشخیص دهید کی چیزی کم است. یک جریان پرداخت کارآمد چهار قطعه دارد:
۱. یک قیمت. آنچه بابتش پول میگیرید، و اینکه یکبارمصرف است یا تکرارشونده. این در ارائهدهندهٔ پرداخت شما زندگی میکند، نه بهصورت ثابت در اپتان کدنویسیشده. ۲. یک گام پرداخت. دکمهای که مشتری کلیک میکند، که او را به فرم امن ارائهدهنده میفرستد. ۳. یک تأییدیه به اپ شما. بعد از پرداخت، ارائهدهنده به اپ شما میگوید «این شخص بابت این چیز پرداخت کرد». این بخشی است که تازهکارها بیشتر از همه از قلم میاندازند — و از قلم انداختنش همان راهی است که آخرش به آدمهایی میرسید که پرداخت کردهاند اما دسترسی نگرفتهاند. ۴. یک سابقه از اینکه چه کسی بابت چه چیزی پرداخت کرد. تا اپ شما بتواند چیز درست را باز کند و تا بتوانید بعداً به «آیا این شخص پرداخت کرد؟» پاسخ دهید.
اگر اپساز هوش مصنوعیتان یک دکمهٔ پرداخت به شما بدهد که یک کارت را شارژ میکند اما اپ شما بعدش کار متفاوتی انجام نمیدهد، قطعهٔ ۲ را ساخته و قطعههای ۳ و ۴ را فراموش کرده. این رایجترین جریان پرداختِ نیمهساخته است، و درست تا لحظهای که یک مشتری پرداخت کند و هیچچیز نگیرد، به نظر میرسد کار میکند.
چطور آن را به اپساز هوش مصنوعیتان توصیف کنید
این هم یک پرامپت که قطعههای بالا را پوشش میدهد:
با استفاده از Stripe Checkout دسترسی پولی به این اپ اضافه کن. یک پلن هست: ۱۹ دلار در ماه.
وقتی یک کاربر واردشده روی «ارتقا» کلیک میکند، او را به صفحهٔ پرداخت میزبانیشدهٔ Stripe بفرست. یک فرم کارت سفارشی نساز — اپ من هرگز نباید با شمارههای کارت کار کند.
بعد از یک پرداخت موفق، آن کاربر را در پایگاه داده «پرداختکرده» علامت بزن و صفحهٔ گزارشها را برایش باز کن. بعد از یک پرداخت ناموفق یا لغوشده، او را با یک پیام به صفحهٔ قیمتگذاری برگردان.
از یک webhook استرایپ برای تأیید پرداخت در سمت سرور پیش از باز کردن هر چیزی استفاده کن — صرفاً بر اساس فرود کاربر روی صفحهٔ موفقیت چیزی را باز نکن.
آن پاراگراف آخر همان است که یک جریان پرداخت واقعی را از یک جریان شکننده جدا میکند. اجازه دادن به اینکه صفحهٔ موفقیت دسترسی را باز کند یعنی هر کسی که نشانی صفحهٔ موفقیت را یاد بگیرد، میتواند آن را رایگان باز کند. webhook — یک پیام مستقیم و تأییدشده از Stripe به backend اپ شما — همان سیگنال قابلاعتماد است. اپساز هوش مصنوعیتان میداند چطور این را راهاندازی کند؛ شما فقط باید به اسم درخواستش کنید.
با پول قلابی آزمایش کنید پیش از پول واقعی
Stripe (و بیشتر ارائهدهندگان) یک حالت آزمایشی با شمارههای کارت قلابی به شما میدهند که مثل کارتهای واقعی رفتار میکنند — از جمله کارتهایی که موفق میشوند، کارتهایی که رد میشوند و کارتهایی که خطا ایجاد میکنند. از آن استفاده کنید. پیش از اینکه حتی یک کارت واقعی به اپ شما برسد، هر مسیر را طی کنید:
- یک پرداخت موفق. آیا چیز درست باز شد؟ آیا وضعیت کاربر به «پرداختکرده» تغییر کرد؟
- یک کارت ردشده. آیا اپ آن را بهخوبی مدیریت کرد، یا کاربر را روی یک صفحهٔ خراب گیر انداخت؟
- یک پرداخت لغوشده — کاربر بهجای پرداخت روی «بازگشت» کلیک میکند. آیا جایی منطقی فرود آمد، و همچنان ارتقانیافته ماند؟
- پرداخت، بعد خروج و ورود دوباره. آیا هنوز «پرداختکرده» است؟ (این آن اپهایی را میگیرد که فقط برای نشست جاری دسترسی را باز میکنند و فردا فراموشش میکنند.)
شمارههای کارت آزمایشی را از اپساز هوش مصنوعیتان بخواهید، یا در مستندات ارائهدهندهتان پیدایشان کنید. یک کارت آزمایشی رایج برای «این پرداخت موفق میشود» همان چیزی است که اپساز شما در صورت درخواست میتواند به شما بدهد. هر چهار سناریو را اجرا کنید. مسیرهای کارتردشده و پرداختلغوشده آنهاییاند که اپسازهای هوش مصنوعی بیشتر از همه خراب رهایشان میکنند، چون مسیر خوشفرجام همان است که برایش بهینه میکنند.
اشتباههایی که پول واقعی هزینه میبرند
چند حالت شکست مشخص بارها و بارها در جریانهای اولین پرداخت ظاهر میشوند:
باز کردن دسترسی روی صفحهٔ موفقیت بهجای webhook. بالاتر پوشش داده شد، اما ارزش تکرار دارد چون پرهزینهترین است. اگر اپ شما به محض فرود کاربر روی /success قابلیتهای پولی را باز کند، دارید به مرورگر کاربر اعتماد میکنید که دربارهٔ پرداخت یا عدم پرداخت صادق باشد. همیشه نیستند. روی webhook باز کنید.
نبودن سابقه از اینکه بابت چه چیزی پرداخت کردند. اگر اپ شما فقط یک پرچم سراسری «پرداختکرده: بله» را روشن کند، به محض اینکه بیش از یک پلن داشته باشید، یا کسی لغو کند، یا نیاز به صدور بازپرداخت داشته باشید، به مشکل میخورید. چیز مشخص را ذخیره کنید: کدام پلن، کی، و شناسهٔ ارائهدهنده برای آن پرداخت. بعداً برای پرسشهای پشتیبانی به آن نیاز دارید.
فراموش کردن اینکه اشتراکها پایان مییابند. یک پرداخت یکبارمصرف ساده است: پرداختشده یعنی پرداختشده. یک اشتراک تکرارشونده میتواند منقضی شود — کارت منقضی میشود، پرداخت ماه بعد ناموفق میشود. اگر اپ شما فقط به «پرداخت کردند» گوش بدهد و هرگز به «اشتراکشان تمام شد» گوش ندهد، آدمهایی خواهید داشت که بعد از قطع پرداخت همچنان دسترسی رایگان نگه میدارند. به اپسازتان بگویید پیام «اشتراک لغو شد یا پرداخت ناموفق بود» را هم مدیریت کند، نه فقط موفقیت را.
شارژ کردن مبلغ اشتباه چون قیمت در دو جا زندگی میکند. اگر قیمت هم در صفحهٔ اپ شما نوشته شده باشد و هم در ارائهدهندهٔ پرداختتان تنظیم شده باشد، بالاخره از هم فاصله میگیرند، و یک مشتری ۱۹ دلار میبیند اما ۲۹ دلار شارژ میشود. قیمت را در یک جا نگه دارید — ارائهدهندهتان — و کاری کنید اپ شما هر چه ارائهدهنده میگوید نمایش دهد. یک منبع حقیقت.
یک چکلیست کوتاه پیش از فعال شدن
پیش از اینکه از حالت آزمایشی به پول واقعی سوئیچ کنید:
- اپ من هیچ فیلدی ندارد که کسی در آن یک شمارهٔ خام کارت تایپ کند.
- پرداخت با یک webhook از ارائهدهنده تأیید میشود، نه با رسیدن کاربر به یک صفحهٔ موفقیت.
- یک پرداخت موفق، یک کارت ردشده و یک پرداخت لغوشده را آزمایش کردهام — هر سه منطقی رفتار میکنند.
- بعد از پرداخت، دسترسی بعد از خروج و فردای آن روز باز میماند.
- اپ من ثبت میکند هر کس بابت چه چیزی پرداخت کرد، نه فقط اینکه پرداخت کرد.
- اگر یک اشتراک منقضی شود، دسترسی بهصورت خودکار حذف میشود.
- کلیدهای ارائهدهنده را از حالت آزمایشی به حالت زنده سوئیچ کردهام (فراموشکردنش آسان است — اولین مشتری واقعی شما که به کلیدهای آزمایشی برخورد کند، یک خطای گیجکننده میگیرد).
اگر هر خانه تیک خورده، آمادهٔ یک کارت واقعی هستید. اگر نه، این موضوع گفتوگوی بعدی شما با اپساز هوش مصنوعیتان است — پیش از به اشتراک گذاشتن لینک، نه بعد از اولین اعتراض.
نگرشی که کمک میکند
پول، آن بخش از اپ شماست که در آن «به نظر میرسد کار میکند» و «واقعاً کار میکند» بیشترین فاصله را دارند. یک چیدمان خراب را بلافاصله میبینید. یک جریان پرداخت که بدون تأیید پرداخت دسترسی را باز میکند، بینقص به نظر میرسد — تا وقتی کسی متوجه شود و به دوستانش بگوید.
پس با جریان پرداخت مثل تنها بخشی از اپ ساختهشده با هوش مصنوعیتان رفتار کنید که مثل یک آدم بدبین آزمایشش میکنید. سعی کنید بدون پرداخت وارد شوید. سعی کنید خرابش کنید. پرداخت کنید و بعد سعی کنید دسترسیتان را از دست بدهید. آن ۳۰ دقیقهای که صرف تقلب کردن در اپ خودتان میکنید، ارزانترین بیمهای است که تا به حال رویش خواهید خرید.
میخواهید به چیزی که ساختهاید پرداخت اضافه کنید؟ نشست بعدی اپساز هوش مصنوعیتان را با توصیف کل جریان شروع کنید — قیمت، پرداخت، تأیید با webhook، و اینکه چه چیزی باز میشود — یکجا، بهجای اینکه فقط یک دکمهٔ پرداخت بخواهید. دکمهٔ پرداخت آن ۱۰٪ آسان است. آن ۹۰٪ دیگر همان است که پول را صادق نگه میدارد.