أول دفعة تحصّلها: إضافة المال الحقيقي إلى تطبيقك المبنيّ بالذكاء الاصطناعي دون أخطاء

هناك لحظة محدّدة يكفّ فيها التطبيق المبنيّ بالذكاء الاصطناعي عن كونه لعبة ويصبح عملاً: أول مرّة يتحرّك فيها المال الحقيقي عبره. حتى تلك النقطة، تكون الأخطاء رخيصة. زرّ معطّل أمر مزعج. مجموع خاطئ على شاشة لا يدفع أحد مقابلها هو خطأ مطبعي. لكن في اليوم الذي تُخصم فيه بطاقة عميل حقيقي، يكلّف الخطأ مالاً فعلياً — مالك أو ماله — وعبارة “هكذا بناه الذكاء الاصطناعي” ليست جملة تريد أن تقولها لشخص يعترض على خصم.

والخبر السار: تحصيل المدفوعات في تطبيق مبنيّ بالذكاء الاصطناعي أيسر ممّا يبدو، إن عرفت أي الأجزاء تسلّمها لمنصّتك لبناء التطبيقات وأيّها لا تلمسها بنفسك أبداً. هذا دليل إلى ذلك الخطّ الفاصل.

القاعدة الوحيدة التي تبقيك بأمان: لا تخزّن أرقام البطاقات أبداً

ابدأ من هنا، لأنها القاعدة التي يتعلّق بها كل شيء آخر. ينبغي ألّا يرى تطبيقك رقم بطاقة ائتمان خاماً، أو يخزّنه، أو يتعامل معه أبداً. لا في قاعدة بيانات، ولا في نموذج بنيته، ولا “بشكل مؤقّت فقط”. إن التعامل المباشر مع بيانات البطاقات يضع على عاتقك كومة من الالتزامات القانونية والأمنية التي لا ينبغي لأي مبتدئ أن يتحمّلها.

بدلاً من ذلك، تستخدم مزوّد مدفوعات — Stripe هو الشائع، وتعرفه معظم منصّات بناء التطبيقات بالذكاء الاصطناعي جيداً. يمنحك المزوّد نموذج دفع آمناً جاهزاً. يكتب العميل بطاقته في نموذج المزوّد، ويتولّى المزوّد خصمها، ولا يستقبل تطبيقك سوى رسالة “نعم، تمّ الدفع”. يعرف تطبيقك أن الدفعة حدثت. لكنه لا يعرف رقم البطاقة أبداً.

حين تطلب من منصّتك لبناء التطبيقات إضافة المدفوعات، قل هذا صراحةً: “استخدم Stripe Checkout (أو نموذج الدفع المستضاف من Stripe) كي لا يتعامل تطبيقي أبداً مع بيانات البطاقات الخام.” إن بدأت المنصّة بتوليد نموذج مخصّص فيه حقل لرقم البطاقة، أوقفها. هذا هو الشيء الوحيد الذي لا تريدها أن تبنيه.

ما الذي تتضمّنه “إضافة المدفوعات” فعلاً

من المفيد أن تعرف الأجزاء المتحرّكة قبل أن تبدأ، لتميّز حين يكون شيء ما ناقصاً. مسار الدفع العامل يتكوّن من أربعة أجزاء:

1. سعر. ما الذي تتقاضاه، وهل هو لمرّة واحدة أم متكرّر. هذا يعيش في مزوّد المدفوعات، لا مكتوباً بشكل ثابت في تطبيقك.
2. خطوة دفع. الزرّ الذي ينقر عليه العميل، فيرسله إلى نموذج المزوّد الآمن.
3. تأكيد يعود إلى تطبيقك. بعد الدفع، يخبر المزوّد تطبيقك “هذا الشخص دفع مقابل هذا الشيء”. هذا هو الجزء الذي يتخطّاه المبتدئون أكثر من غيره — وتخطّيه هو ما ينتهي بك إلى أشخاص دفعوا لكنهم لم يحصلوا على وصول.
4. سجلّ لمن دفع مقابل ماذا. كي يستطيع تطبيقك فتح الشيء الصحيح، وكي تستطيع لاحقاً الإجابة عن “هل دفع هذا الشخص؟”.

إن أعطتك منصّتك لبناء التطبيقات زرّ دفع يخصم البطاقة لكن تطبيقك لا يفعل أي شيء مختلف بعد ذلك، فهي بنت الجزء الثاني ونسيت الثالث والرابع. هذا هو مسار الدفع نصف المبنيّ الأكثر شيوعاً، ويبدو أنه يعمل تماماً حتى يدفع عميل ولا يحصل على شيء.

كيف تصفه لمنصّتك لبناء التطبيقات

إليك نصّاً يغطّي الأجزاء أعلاه:

أضف وصولاً مدفوعاً إلى هذا التطبيق باستخدام Stripe Checkout. هناك خطّة واحدة: 19 دولاراً/شهرياً.

حين ينقر مستخدم مسجّل الدخول على “ترقية”، أرسله إلى صفحة الدفع المستضافة من Stripe. لا تبنِ نموذج بطاقة مخصّصاً — ينبغي ألّا يتعامل تطبيقي أبداً مع أرقام البطاقات.

بعد دفعة ناجحة، علّم ذلك المستخدم كـ”مدفوع” في قاعدة البيانات وافتح له صفحة التقارير. وبعد دفعة فاشلة أو ملغاة، أعِده إلى صفحة التسعير مع رسالة.

استخدم Stripe webhook لتأكيد الدفعة من جهة الخادم قبل فتح أي شيء — لا تفتح بناءً على وصول المستخدم إلى صفحة النجاح فقط.

تلك الفقرة الأخيرة هي التي تفصل مسار دفع حقيقياً عن مسار هشّ. فترك صفحة النجاح تفتح الوصول يعني أن أي شخص يعرف عنوان صفحة النجاح يمكنه فتحها مجاناً. أما الـ webhook — وهو رسالة مباشرة ومُتحقّق منها من Stripe إلى خلفية تطبيقك — فهو الإشارة الجديرة بالثقة. تعرف منصّتك لبناء التطبيقات كيف تعدّ هذا؛ كل ما عليك هو أن تطلبه بالاسم.

اختبر بمال مزيّف قبل المال الحقيقي

يمنحك Stripe (ومعظم المزوّدين) وضع اختبار فيه أرقام بطاقات مزيّفة تتصرّف كالحقيقية — بما في ذلك بطاقات تنجح، وبطاقات تُرفض، وبطاقات تطلق أخطاءً. استخدمه. قبل أن تلمس تطبيقَك بطاقةٌ حقيقية واحدة، اعبر كل مسار:

• دفعة ناجحة. هل انفتح الشيء الصحيح؟ هل تغيّرت حالة المستخدم إلى “مدفوع”؟
• بطاقة مرفوضة. هل تعامل التطبيق معها بأناقة، أم ترك المستخدم عالقاً على شاشة معطّلة؟
• دفع ملغى — ينقر المستخدم “رجوع” بدل الدفع. هل انتهى به الأمر إلى مكان منطقي، ولا يزال غير مرقّى؟
• الدفع، ثم تسجيل الخروج والدخول مجدّداً. هل لا يزال “مدفوعاً”؟ (هذا يكشف التطبيقات التي تفتح الوصول للجلسة الحالية فقط ثم تنساه بحلول الغد.)

اطلب من منصّتك لبناء التطبيقات أرقام بطاقات الاختبار، أو ابحث عنها في وثائق مزوّدك. وهناك بطاقة اختبار شائعة لحالة “هذه الدفعة تنجح” يمكن لمنصّتك أن تعطيك إياها عند الطلب. اعبر السيناريوهات الأربعة كلها. فمساري البطاقة المرفوضة والدفع الملغى هما اللذان تتركهما منصّات بناء التطبيقات معطّلَين أكثر من غيرهما، لأن المسار السعيد هو الذي تحسّنه.

الأخطاء التي تكلّف مالاً حقيقياً

تظهر بضعة أنماط فشل محدّدة مراراً وتكراراً مع مسارات الدفع الأولى:

فتح الوصول على صفحة النجاح بدلاً من الـ webhook. غطّيناه أعلاه، لكنه يستحقّ التكرار لأنه المكلِف. إن فتح تطبيقك الميزات المدفوعة لحظةَ وصول المستخدم إلى /success، فأنت تثق بمتصفّح المستخدم في أن يكون صادقاً بشأن ما إن كان قد دفع. وهم ليسوا دائماً كذلك. افتح الوصول على الـ webhook.

لا سجلّ لـ ماذا دفعوا. إن كان تطبيقك يقلب فقط علامة عامّة “مدفوع: نعم”، فستواجه صعوبة لحظةَ أن يصبح لديك أكثر من خطّة، أو يلغي أحدهم، أو تحتاج إلى إصدار استرداد. خزّن الشيء المحدّد: أي خطّة، ومتى، ومعرّف المزوّد لتلك الدفعة. ستحتاج إليه لأسئلة الدعم لاحقاً.

نسيان أن الاشتراكات تنتهي. الدفعة لمرّة واحدة بسيطة: المدفوع مدفوع. أما الاشتراك المتكرّر فقد ينقطع — تنتهي صلاحية البطاقة، أو تفشل الدفعة الشهر القادم. إن كان تطبيقك يستمع فقط لـ”لقد دفعوا” ولا يستمع أبداً لـ”انتهى اشتراكهم”، فسيكون لديك أشخاص يحتفظون بالوصول مجاناً بعد أن يتوقّفوا عن الدفع. أخبر منصّتك بأن تتعامل أيضاً مع رسالة “أُلغي الاشتراك أو فشلت الدفعة”، لا مع النجاح فقط.

خصم المبلغ الخطأ لأن السعر يعيش في مكانَين. إن كان السعر مكتوباً في شاشة تطبيقك و مضبوطاً في مزوّد مدفوعاتك، فسينحرفان عن بعضهما في النهاية، وسيرى عميل 19 دولاراً لكن يُخصم منه 29 دولاراً. أبقِ السعر في مكان واحد — مزوّدك — واجعل تطبيقك يعرض ما يقوله المزوّد أياً كان. مصدر واحد للحقيقة.

قائمة تحقّق قصيرة قبل الانطلاق

قبل أن تنتقل من وضع الاختبار إلى المال الحقيقي:

• تطبيقي لا يحوي أبداً حقلاً يكتب فيه أحدهم رقم بطاقة خاماً.
• الدفعة مؤكَّدة بـ webhook من المزوّد، لا بوصول المستخدم إلى صفحة نجاح.
• اختبرت دفعة ناجحة، وبطاقة مرفوضة، ودفعاً ملغى — وتتصرّف الثلاثة بشكل منطقي.
• بعد الدفع، يبقى الوصول مفتوحاً بعد تسجيل الخروج وفي اليوم التالي.
• تطبيقي يسجّل ماذا دفع كل شخص، لا أنه دفع فقط.
• إن انقطع اشتراك، يُزال الوصول تلقائياً.
• بدّلت مفاتيح المزوّد من وضع الاختبار إلى الوضع الحيّ (يسهل نسيانه — أول عميل حقيقي يصطدم بمفاتيح الاختبار يحصل على خطأ محيّر).

إن كان كل مربّع محدّداً، فأنت جاهز لبطاقة حقيقية. وإن لم يكن، فتلك هي محادثتك التالية مع منصّتك لبناء التطبيقات — قبل أن تشارك الرابط، لا بعد أول اعتراض.

العقلية التي تساعد

المال هو الجزء من تطبيقك الذي يكون فيه “يبدو أنه يعمل” و”يعمل فعلاً” أبعد ما يكونان عن بعضهما. التخطيط المعطّل تراه فوراً. أما مسار الدفع الذي يفتح الوصول دون التحقّق من الدفع فيبدو مثالياً — حتى يلاحظه أحدهم ويخبر أصدقاءه.

لذا عامِل مسار الدفع باعتباره الجزء الوحيد من تطبيقك المبنيّ بالذكاء الاصطناعي الذي تختبره كمشكّك. حاوِل الدخول دون دفع. حاوِل كسره. ادفع ثم حاول أن تفقد وصولك. الثلاثون دقيقة التي تقضيها في محاولة الغشّ على تطبيقك هي أرخص تأمين ستشتريه عليه على الإطلاق.

---

على وشك إضافة المدفوعات إلى شيء بنيته؟ افتتح جلستك التالية مع منصّة بناء التطبيقات بوصف المسار كاملاً — السعر، والدفع، وتأكيد الـ webhook، وما الذي يُفتح — دفعةً واحدة، بدلاً من مجرّد طلب زرّ دفع. زرّ الدفع هو الـ10% السهلة. أما الـ90% الأخرى فهي ما يبقي المال نزيهاً.