🚀 AllWDbook — من الفكرة إلى الإطلاق
AllWDbook Build Journal
كيف بحثنا عن بوابة الدفع المناسبة لـAllWDbook: من Lemon Squeezy إلى Paddle ثم FastSpring
تجربة حقيقية في البحث عن بوابة الدفع المناسبة لـAllWDbook، من Lemon Squeezy وتجميد المدفوعات إلى تجربة Paddle ثم الانتقال إلى FastSpring.
اختيار بوابة الدفع لم يكن مجرد خطوة تقنية صغيرة في بناء AllWDbook.
عندما بدأت مرحلة التفكير في تحقيق الدخل، كان المطلوب أكثر من زر يدفع المستخدم من خلاله. كنا نحتاج إلى مزود دفع يمكن دمجه مع المنصة، والتعامل معه بصورة عملية، والمحافظة في الوقت نفسه على نظام الوصول الموجود بالفعل داخل AllWDbook.
بدأت الرحلة مع Lemon Squeezy، ثم وصلنا إلى مرحلة اضطررنا فيها إلى تجميد المدفوعات الجديدة أثناء انتظار التحقق. بعد ذلك درسنا Paddle وحاولنا استخدام بيئة Sandbox، لكن تجربة التسجيل والإعداد لم تكن مناسبة لمسار المشروع في تلك المرحلة. ومن هناك انتقل البحث إلى FastSpring، حيث ظهرت عقبة جديدة مرتبطة باستخدام بريد إلكتروني شخصي، ثم تم إرسال طلب استثناء وانتظار الرد.
هذه المقالة لا تحاول إعلان أن إحدى هذه الشركات هي الأفضل للجميع. إنها توثق تجربة حقيقية داخل AllWDbook، وكيف يمكن أن يتحول قرار يبدو بسيطًا مثل اختيار بوابة دفع إلى مجموعة من القرارات التقنية والتجارية وتجربة المستخدم.
بوابة الدفع ليست مجرد زر Checkout
عند النظر إلى بوابات الدفع من الخارج، يبدو القرار بسيطًا: نختار شركة، نضيف رابط الدفع، ثم يبدأ المستخدمون في الاشتراك.
لكن داخل منتج حقيقي توجد طبقات أخرى يجب أخذها في الاعتبار. كيف يتم تأكيد عملية الشراء؟ كيف تصل المنصة إلى معلومة أن المستخدم أصبح مدفوعًا؟ ماذا يحدث إذا تعطل مزود الدفع؟ وكيف نحافظ على حق مستخدم اشترى سابقًا إذا قررنا تغيير المزود لاحقًا؟
في AllWDbook كان هذا مهمًا بصورة خاصة لأن نظام الوصول لم يكن مرتبطًا فقط بصفحة Checkout. لدينا AWD-KEY والاستعادة وحالات وصول سابقة يجب ألا تتوقف لمجرد أن بوابة الدفع الجديدة لم تصبح جاهزة بعد.
لهذا أصبح قرار مزود الدفع قرارًا في بنية المنتج نفسه، وليس قرارًا منفصلًا عن بقية النظام.
البداية مع Lemon Squeezy
كان Lemon Squeezy جزءًا من أول بنية دفع تم إعدادها في AllWDbook. تم بناء التكامل بحيث تستطيع المنصة التعامل مع شراء الخطط ومنح الوصول للمستخدم بعد نجاح العملية.
وجود نظام يعمل بالفعل مهم جدًا في أي مشروع، لأن التكامل لا يمثل مجرد رابط خارجي. هناك مسارات داخل التطبيق تعتمد على النتيجة القادمة من مزود الدفع، وهناك مستخدمون قد يكون لديهم وصول سابق يجب الحفاظ عليه.
لكن مع تطور المشروع ظهرت مرحلة تحقق جعلت استمرار استقبال المدفوعات الجديدة غير مناسب مؤقتًا.
هنا كان القرار الأكثر أمانًا هو عدم محاولة تجاوز مرحلة التحقق، بل تجميد المدفوعات الجديدة حتى تصبح الصورة واضحة.
تجميد المدفوعات دون تجميد المنتج
إيقاف استقبال عمليات شراء جديدة لا يجب أن يعني تعطيل الموقع بالكامل.
لذلك تم فصل حالة الدفع عن بقية AllWDbook. الأدوات المجانية بقيت تعمل، ونظام AWD-KEY بقي متاحًا، والاستعادة بقيت تعمل، كما لم يتم إلغاء الوصول الذي حصل عليه مستخدمون سابقون.
هذه النقطة أصبحت من أهم الدروس في بنية المشروع: مزود الدفع يجب ألا يكون نقطة فشل توقف المنتج كله.
إذا كانت كل وظائف المنصة مرتبطة مباشرة بحالة Checkout، فإن أي مشكلة في مزود خارجي قد تتحول إلى مشكلة لجميع المستخدمين، حتى الذين لا يحاولون الدفع أصلًا.
لماذا لم نحذف تكامل Lemon Squeezy القديم؟
عندما يبدأ البحث عن مزود جديد، قد يبدو حذف التكامل السابق وإعادة البناء من الصفر حلًا نظيفًا. لكنه لم يكن الخيار الصحيح في AllWDbook.
التكامل القديم يمثل جزءًا من تاريخ عمليات الوصول السابقة. وقد توجد بيانات أو معاملات أو مفاتيح وصول تم إنشاؤها عندما كان ذلك النظام يعمل.
حذف الكود لمجرد أننا نبحث عن بديل يمكن أن يجعل صيانة الوصول السابق أصعب، أو يقطع مسارات استعادة ما زالت مهمة للمستخدمين.
لذلك كان المبدأ هو الحفاظ على النظام القديم بما يخدم المستخدمين السابقين، وبناء أي مزود جديد للمدفوعات الجديدة بصورة منفصلة قدر الإمكان.
المحطة الثانية: تجربة Paddle
بعد تجميد المدفوعات الجديدة بدأ البحث عن بديل يمكن تجربته قبل اتخاذ قرار نهائي.
كان Paddle أحد الخيارات التي تمت دراستها، وكانت الفكرة أن نبدأ أولًا ببيئة اختبار Sandbox حتى لا نربط النظام الحقيقي قبل التأكد من طريقة العمل.
لكن تجربة التسجيل والوصول إلى بيئة الاختبار لم تكن بالوضوح الذي احتجناه في تلك المرحلة. بدل الدخول سريعًا إلى Sandbox والبدء في اختبار التكامل، أصبحت عملية الإعداد نفسها عائقًا.
وهنا اتخذنا قرارًا مهمًا: لا يجب أن نستمر في مزود فقط لأننا بدأنا معه. إذا كانت الخطوات الأولى تستهلك وقتًا أكبر من قيمتها للمشروع الحالي، فمن الطبيعي تقييم خيار آخر.
بيئة Sandbox نفسها جزء من تقييم المزود
غالبًا ما تتم مقارنة بوابات الدفع بناءً على الرسوم أو قائمة المزايا، لكن تجربة المطور تبدأ قبل أول عملية دفع حقيقية.
وجود مسار اختبار مفهوم، ووثائق يمكن تطبيقها، وطريقة واضحة للانتقال من الاختبار إلى الإنتاج، كلها تؤثر مباشرة في تكلفة التكامل من ناحية الوقت.
في مشروع صغير أو متوسط، الوقت الذي يُصرف على فهم نظام معقد هو تكلفة حقيقية حتى إذا لم تظهر في فاتورة مالية.
تجربة Paddle ذكرتنا بأننا لا نختار المنتج النهائي فقط؛ نحن نختار أيضًا عملية التطوير والصيانة التي سنعيش معها بعد الإطلاق.
الانتقال إلى FastSpring
بعد تجربة Paddle انتقل البحث إلى FastSpring كخيار آخر يمكن تقييمه.
لكن هذه المرة ظهرت العقبة في مرحلة مبكرة جدًا: نموذج التواصل أو التسجيل لم يقبل البريد الشخصي المستخدم في البداية، وطُلب بريد عمل أو بريد مرتبط بنطاق تجاري.
بالنسبة إلى مشروع رقمي مستقل، هذه التفاصيل قد تبدو صغيرة، لكنها تؤثر فعليًا في قدرة صاحب المشروع على بدء العلاقة مع المزود.
بدل التوقف عند الرسالة الأولى، تم إرسال طلب استثناء إلى FastSpring لشرح الحالة والاستفسار عن إمكانية المتابعة.
طلب الاستثناء وانتظار الرد
بعد إرسال الطلب ظهرت رسالة تؤكد أن FastSpring استلم الاستفسار وأن الفريق سيتواصل لاحقًا.
في هذه المرحلة لم يكن من المنطقي كتابة تكامل جديد قبل معرفة ما إذا كان الحساب سيُقبل وما هي الخطوات التالية.
لذلك بقي الدفع في AllWDbook متوقفًا للعمليات الجديدة، بينما استمرت بقية المنصة في العمل بصورة مستقلة.
هذه المقالة تم إعدادها كتوثيق أثناء الرحلة. قبل نشرها نهائيًا سيتم تحديث هذا الجزء بنتيجة التواصل مع FastSpring، سواء تم اعتمادها كمزود جديد أو تم الانتقال إلى خيار آخر.
ما الذي نقارنه فعلًا عند اختيار مزود دفع؟
بعد المرور بهذه المراحل أصبح واضحًا أن المقارنة لا يجب أن تنحصر في سؤال واحد مثل: من يملك الرسوم الأقل؟
بالنسبة إلى AllWDbook أصبح التقييم يشمل سهولة بدء الحساب، وضوح عملية التحقق، سهولة الاختبار، تجربة التكامل، طريقة التعامل مع العمليات بعد الدفع، واستقرار العلاقة بين المزود ونظام الوصول داخل المنصة.
كما نحتاج إلى التفكير في تجربة المستخدم. عملية الدفع يجب أن تكون مفهومة ولا تجعل المشتري يشعر أنه خرج إلى مسار غريب أو غير مرتبط بالمنتج الذي كان يستخدمه.
وأخيرًا تأتي قابلية الصيانة: إذا احتجنا بعد عام إلى تغيير شيء في الخطط أو نظام الوصول، هل سيكون التكامل واضحًا بما يكفي لتعديله دون إعادة بناء المشروع؟
أهم قرار تقني: فصل الدفع عن حق الوصول
أهم نتيجة خرجنا بها من هذه الرحلة لم تكن اسم شركة معينة، بل مبدأ في تصميم AllWDbook.
الدفع هو حدث يمنح المستخدم حقًا معينًا، لكنه لا يجب أن يصبح الطريقة الوحيدة التي يعرف بها النظام أن هذا الحق موجود.
بعد نجاح عملية الشراء يمكن تسجيل الاستحقاق داخل نظام AllWDbook، ومن هناك تعمل AWD-KEY والاستعادة وبقية آليات الوصول بصورة مستقلة عن صفحة الدفع نفسها.
هذا الفصل يجعل تغيير مزود الدفع في المستقبل أقل خطورة، ويحمي المستخدم من فقدان الوصول بسبب تغييرات تجارية أو تقنية لا علاقة له بها.
لماذا لا نستعجل إعادة تشغيل الدفع؟
من السهل الشعور بأن وجود زر شراء أهم من الانتظار، خصوصًا بعد أن تصبح المنصة جاهزة للاستخدام.
لكن تشغيل مدفوعات جديدة قبل التأكد من المزود والتكامل والاستعادة قد يخلق مشكلات أكبر من خسارة بعض المبيعات المؤقتة.
الأولوية هي أن تكون أول عملية دفع بعد إعادة التفعيل قابلة للتتبع والاستعادة، وأن يحصل المستخدم على ما دفع مقابله دون خطوات يدوية غامضة.
لهذا بقي قرار إعادة تفعيل الدفع منفصلًا عن تطوير الأدوات والمقالات وتحسين تجربة الموقع. المنتج يستمر في النمو، بينما بوابة الدفع تأخذ الوقت اللازم للوصول إلى حل مستقر.
ما الذي علمتنا إياه رحلة Lemon Squeezy وPaddle وFastSpring؟
اختيار مزود الدفع ليس مسابقة للعثور على اسم مثالي، بل عملية للعثور على الخيار المناسب لمرحلة المشروع وبنيته واحتياجات مستخدميه.
ما يعمل بصورة ممتازة لمشروع كبير قد يكون أكثر تعقيدًا من اللازم لمشروع في بدايته، وما يبدو سهلًا في البداية قد يصبح أقل ملاءمة عندما تبدأ متطلبات التحقق أو الاستعادة أو الصيانة.
كما أن تغيير المزود ليس فشلًا في التخطيط. أحيانًا يكون نتيجة طبيعية لأننا تعلمنا أكثر عن احتياجات المنتج أثناء البناء.
بالنسبة إلى AllWDbook ستنتهي هذه الرحلة فقط عندما نستطيع إعادة تشغيل المدفوعات الجديدة بثقة، مع الحفاظ على بساطة الاستخدام وحماية الوصول السابق.