تكلفة ربط بوابة دفع بالتطبيق: رسوم التطوير ورسوم العمليات
تريد إضافة الدفع الإلكتروني إلى تطبيقك، وتسمع رقمًا للتطوير ولا تعرف ما ستدفعه للبوابة بعد ذلك. هذه المقالة لصاحب المشروع والإدارة المالية: تفصل الفاتورتين، وما يرفع كلًّا منهما، وكيف تحسب رسوم العمليات بأرقامك قبل التوقيع.
تكلفة ربط بوابة دفع بالتطبيق فاتورتان منفصلتان. الأولى تدفعها مرة واحدة لشركة التطوير: مسار الدفع لكل وسيلة، وحالات الدفع في الخادم، والاسترداد، والمطابقة مع تقارير البوابة، والفواتير، واختبار حالات الفشل والتكرار. والثانية تدفعها للبوابة مع كل عملية ما دام التطبيق يبيع: نسبة من المبلغ أو رسم ثابت أو كلاهما، تختلف بحسب الوسيلة، وقد تضاف إليها رسوم استرداد أو اعتراض أو اشتراك. الأولى يرفعها نموذج البيع: الاشتراكات والتقسيط وتقسيم المبلغ بين البائعين. والثانية يحددها عقدك مع البوابة وحجم مبيعاتك ومتوسط قيمة الطلب.
حين تسأل «كم يكلف إضافة الدفع الإلكتروني؟» يأتيك غالبًا رقم للتطوير وحده، وتكتشف الرسوم الشهرية مع أول تسوية. ويحدث العكس أيضًا: تقارن عروض البوابات بدقة، ثم يُبنى الربط بأقل جهد، فتظهر دفعات ناجحة بلا طلبات، واستردادات لا تنعكس على الفواتير. هذه المقالة تفصل الفاتورتين: ما الذي تشتريه في تكلفة التطوير، وما الذي يرفعها، وكيف تحسب رسوم العمليات قبل أن توقّع مع البوابة.
قبل الحساب: هل تحتاج بوابة دفع أصلًا أم نظام الدفع داخل المتجر؟
أول قرار يغير الحساب كله ليس اختيار البوابة، بل نوع ما تبيعه. المتجران يفرقان بين السلع والخدمات التي تُستهلك خارج التطبيق وبين المحتوى والمزايا الرقمية داخله:
- سلع أو خدمات خارج التطبيق (منتجات تُشحن، وحجز موعد، وخدمة منزلية، وطلب طعام): تنص إرشادات مراجعة App Store في البند 3.1.3(e) على استخدام وسيلة دفع غير الشراء داخل التطبيق، مثل Apple Pay أو إدخال البطاقة. وتنص سياسة المدفوعات في Google Play على ألا يُستخدم نظام فوترة Google Play للسلع والخدمات المادية. هنا تحتاج بوابة دفع، وهي موضوع هذه المقالة.
- محتوى أو مزايا رقمية داخل التطبيق (اشتراك يفتح محتوى، ومزايا مدفوعة، وعملات داخل التطبيق): البند 3.1.1 في إرشادات Apple يلزم بالشراء داخل التطبيق، وسياسة Google تلزم بنظام فوترتها مع استثناءات محددة. هنا نموذج الرسوم مختلف تمامًا، وتفصله مقالة الدفع داخل التطبيق أم بوابة دفع.
التطبيقات التي تجمع النوعين، مثل نادٍ يبيع حصصًا حضورية ومحتوى تدريبيًا مسجلًا، تحتاج قرارًا لكل منتج، ويُكتب هذا القرار قبل التقدير لا بعده.
الفاتورتان: تكلفة التطوير مرة ورسوم العمليات مع كل عملية
| البند | تكلفة التطوير | رسوم البوابة والعمليات |
|---|---|---|
| لمن تُدفع | لشركة التطوير | للبوابة، وتُخصم غالبًا من المبالغ قبل تسويتها في حسابك |
| متى | مرة عند البناء، ثم عند كل تعديل على مسار الدفع | مع كل عملية، وقد يضاف اشتراك أو رسوم إعداد |
| ما يحددها | الوسائل، ونموذج البيع، والحالات، والاسترداد، والمطابقة، والفواتير | الوسيلة، ومتوسط قيمة الطلب، والحجم، وشروط عقدك |
| كيف تنمو | لا تنمو مع المبيعات | تنمو مع كل عملية بيع |
| أين تتفاوض | على النطاق: ما يدخل الإصدار الأول وما يؤجل | على النسب والرسوم الثابتة ومدة التسوية بحسب حجمك |
هذا الجدول يشرح لماذا تخطئ المقارنة بين عرضي تطوير بأرقامهما فقط: عرض يبني مطابقة يومية واستردادًا جزئيًا يكلف أكثر اليوم، ويوفر ساعات المحاسب ومكالمات الدعم كل شهر بعد ذلك.
ما الذي تشتريه في تكلفة التطوير؟
الربط مع البوابة نفسه، أي إرسال المبلغ وعرض صفحة الدفع، هو الجزء الأسهل. الجهد الحقيقي فيما حوله، وأهمه أن الخادم يعرف في كل لحظة حالة كل دفعة:
- طلب جديد
- بانتظار الدفع
- ناجح
- فاشل
- مسترد جزئيًا
- مسترد كليًا
ومكونات التطوير التي يجب أن تجدها في العرض بأسمائها:
- مسار الدفع لكل وسيلة: مدى والبطاقات وApple Pay وغيرها. كل وسيلة لها شاشاتها أو إعداداتها واختبارها.
- إشعارات البوابة في الخادم: استقبالها، والتحقق من توقيعها، ومعالجة التكرار والتأخر، واستعلام دوري عن الدفعات المعلقة.
- منع الخصم المزدوج: عميل ضغط الزر مرتين أو أعاد المحاولة بعد انقطاع الشبكة.
- الاسترداد الكامل والجزئي: من لوحة التحكم، بصلاحية وسجل، وبأثره على الطلب والفاتورة.
- الفواتير وإشعارات الدائن: مع كل عملية ناجحة وكل استرداد، وفق متطلبات الفوترة الإلكترونية لدى هيئة الزكاة والضريبة والجمارك، أو ترحيلها إلى النظام الذي يصدرها.
- المطابقة: مقارنة عمليات النظام بتقارير البوابة يوميًا، وكشف الفروقات بمعرف العملية. التفاصيل في مقالة مطابقة المدفوعات في التطبيق.
- إدارة المدفوعات في اللوحة: البحث، والتصفية، والاسترداد، والتصدير للمحاسبة.
- الاختبار على بيئة البوابة التجريبية: النجاح والفشل والتكرار والتأخر والاسترداد الجزئي، ثم تجربة بمبالغ حقيقية صغيرة في الإنتاج.
ما الذي يرفع تكلفة تطوير الدفع؟
| العامل | لماذا يرفع التكلفة | كيف تقلله |
|---|---|---|
| عدد وسائل الدفع | كل وسيلة مسار واختبار وحالات فشل خاصة بها. | ابدأ بالوسائل التي يستخدمها جمهورك فعلًا، وأضف غيرها بعد قياس الطلب. |
| نموذج الدفع | العربون، والدفع بعد التنفيذ، وتعديل المبلغ بعد المعاينة: كل نموذج حالات جديدة. | نموذج واحد في الإصدار الأول إن أمكن، والاستثناءات يدويًا من اللوحة مؤقتًا. |
| الاشتراكات والدفع المتكرر | حفظ البطاقة لدى البوابة، والتجديد، وفشل التحصيل وإعادة المحاولة، وتحديث البطاقة. | تأكد أولًا أن بوابتك تدعم التحصيل المتكرر؛ وإلا فرابط دفع مع تذكير. مقالة الدفع المتكرر في التطبيق تفصل الخيارين. |
| التقسيط (اشترِ الآن وادفع لاحقًا) | ربط منفصل مع مزود التقسيط، واعتماد منشأتك لديه، واسترداد يمر عبره. | أضفه للمنتجات مرتفعة القيمة حيث يرفع التحويل، لا لكل الطلبات. التفاصيل في مقالة إضافة التقسيط إلى التطبيق. |
| تقسيم المبلغ بين بائعين | العمولات، ونصيب كل بائع، والتسويات، والاسترداد من طرفين؛ وقد يتطلب خدمات خاصة من البوابة. | ابدأ بتسوية دورية من اللوحة قبل الأتمتة الكاملة، واسأل البوابة عما تدعمه. |
| عمق الاسترداد | الاسترداد الجزئي لبند من طلب، مع ضريبته وإشعار دائنه، أعقد من إلغاء كامل. | حدد سياسة الاسترداد كتابيًا قبل التنفيذ، ومن يعتمد كل حالة. |
| الربط المحاسبي | ترحيل كل عملية واسترداد ورسوم إلى النظام المحاسبي تدفق إضافي. | تصدير يومي منظم في البداية، ثم ربط آلي حين يكبر الحجم. |
| حالة التطبيق القائم | إضافة الدفع إلى تطبيق قائم تمس الطلبات وقاعدة البيانات واللوحة، وتحتاج قراءة الكود أولًا. | تحليل أثر قبل التقدير، كما في صفحة تكلفة إضافة ميزة لتطبيق قائم. |
رسوم العمليات: البنود التي تسأل عنها البوابة قبل التوقيع
رسوم البوابات ليست رقمًا واحدًا، وتختلف بين البوابات وبحسب حجمك وعقدك، فلا تعتمد على أرقام متداولة. اطلب عرضًا مكتوبًا يجيب عن هذه البنود كلها:
| البند | ما تسأل عنه | لماذا يهم |
|---|---|---|
| النسبة لكل وسيلة | هل تختلف نسبة مدى عن البطاقات الائتمانية وعن Apple Pay؟ | مزيج وسائل عملائك يحدد متوسط ما تدفعه فعلًا. |
| الرسم الثابت لكل عملية | هل يوجد رسم ثابت فوق النسبة؟ وكم؟ | يثقل كثيرًا على الطلبات الصغيرة، كما يوضح المثال التالي. |
| رسوم الإعداد والاشتراك | هل توجد رسوم تفعيل، أو اشتراك شهري، أو حد أدنى شهري؟ | تكلفة ثابتة تُحسب حتى في الأشهر الضعيفة. |
| الاسترداد | هل تُرد رسوم العملية الأصلية عند الاسترداد؟ وهل للاسترداد رسم؟ | في نشاط كثير الإلغاء، هذا البند وحده قد يغير المقارنة. |
| الاعتراضات | كم رسم الاعتراض على عملية من حامل البطاقة، وكيف تُدار؟ | مهم في السلع مرتفعة القيمة والخدمات المدفوعة مسبقًا. |
| مدة التسوية | بعد كم يوم تصل المبالغ إلى حسابك البنكي؟ | تؤثر على السيولة أكثر مما تؤثر على الربح. |
| الترخيص والامتثال | ما ترخيص البوابة من الجهة التنظيمية؟ وما المطلوب من منشأتك لفتح حساب التاجر؟ | حساب التاجر يُفتح باسم منشأتك، ووثائقه تحدد متى تبدأ. |
مثال: كيف تحسب رسوم العمليات الشهرية، ولماذا يهم متوسط الطلب؟
مثال افتراضي للتوضيح محمصة قهوة مختصة تبيع عبر تطبيقها. النسب والرسوم أدناه افتراضية للحساب فقط، وليست أسعار أي بوابة؛ استبدلها بعرض بوابتك.
- المبيعات الشهرية عبر التطبيق: 360,000 ريال.
- مزيج الوسائل: 65% مدى، و35% بطاقات ائتمانية.
- نسبة افتراضية: 1% لمدى، و2.5% للبطاقات، ورسم ثابت افتراضي 1 ريال لكل عملية.
الرسوم النسبية: (234,000 × 1%) + (126,000 × 2.5%) = 2,340 + 3,150 = 5,490 ريالًا، وهي ثابتة ما دام حجم المبيعات والمزيج ثابتين. أما الرسم الثابت فيعتمد على عدد الطلبات:
| السيناريو | عدد الطلبات | الرسوم الثابتة | إجمالي الرسوم | نسبة من المبيعات |
|---|---|---|---|---|
| متوسط الطلب 120 ريالًا (حبوب واشتراكات) | 3,000 | 3,000 | 8,490 | 2.36% |
| متوسط الطلب 30 ريالًا (مشروبات للاستلام) | 12,000 | 12,000 | 17,490 | 4.86% |
القراءة: حجم المبيعات نفسه تقريبًا ضاعف نسبة الرسوم حين صغر متوسط الطلب، لأن الرسم الثابت صار جزءًا كبيرًا من كل عملية. لهذا لا تقارن البوابات بالنسبة المئوية وحدها، بل احسب بأرقامك: متوسط الطلب، ومزيج الوسائل، ونسبة الاسترداد. وفي نشاط الطلبات الصغيرة يصبح التفاوض على الرسم الثابت، أو تشجيع الوسيلة الأقل رسومًا، أهم من التفاوض على النسبة.
أخطاء شائعة في تقدير تكلفة الدفع الإلكتروني
- مقارنة البوابات بالنسبة المئوية فقط: الرسم الثابت ورسوم الاسترداد ومدة التسوية قد تغير الترتيب.
- الاعتماد على عودة التطبيق لتأكيد الدفع: يصنع دفعات ناجحة بلا طلبات، ومكالمات دعم بإيصالات خصم.
- ترك الاسترداد للوحة البوابة: يُرد المبلغ ولا تتغير حالة الطلب ولا تصدر إشعارات دائنة، فتختلف الأرقام آخر الشهر.
- تأجيل المطابقة: المحاسب يطابق يدويًا، والفروقات تُكتشف بعد أسابيع حين يصعب تتبعها.
- إضافة كل الوسائل والتقسيط من اليوم الأول: تكلفة تطوير واختبار لوسائل قد لا يستخدمها جمهورك.
- بدء التطوير قبل فتح حساب التاجر: الربط جاهز والإطلاق ينتظر اعتماد البوابة والوثائق.
- بوابة لا تدعم نموذجك: اكتشاف أن البوابة لا تدعم التحصيل المتكرر أو تقسيم المبالغ بعد بناء التطبيق على افتراض أنها تدعمه.
ما تطلبه من المطور والبوابة وما تجهزه قبل التقدير
اطلب من شركة التطوير أن يوضح العرض:
- الوسائل المشمولة، ونماذج الدفع (مقدمًا، أو عربون، أو بعد التنفيذ)، والحالات التي يديرها الخادم.
- كيف يُؤكد الدفع: إشعار البوابة الموثق والاستعلام الدوري، ومنع الخصم المزدوج.
- الاسترداد الكامل والجزئي من اللوحة، وأثره على الطلب والفاتورة.
- المطابقة مع تقارير البوابة: يدوية أم آلية، وبأي تكرار.
- الفواتير الإلكترونية: يصدرها التطبيق أم يرحّلها إلى نظام آخر يصدرها.
- خطة الاختبار على بيئة البوابة، والانتقال إلى الإنتاج.
واطلب من البوابة عرضًا مكتوبًا يجيب عن بنود جدول الرسوم أعلاه، مع ما تدعمه تقنيًا: التحصيل المتكرر، والاسترداد الجزئي، وتقسيم المبالغ، وبيئة الاختبار.
وجهّز قبل طلب التقدير:
- ما تبيعه ونموذج الدفع: منتجات، أو خدمات، أو اشتراكات، أو مزيج منها.
- تقديرًا لعدد الطلبات الشهري ومتوسط قيمة الطلب، ولو تقريبيًا.
- سياسة الإلغاء والاسترداد المكتوبة، ومن يعتمد الاستردادات.
- السجل التجاري والحساب البنكي لفتح حساب التاجر، والبوابة المفضلة إن وُجدت.
- النظام المحاسبي الذي تُرحَّل إليه المدفوعات.
في الدفع الذي نبنيه، لا تمر بيانات البطاقة بأنظمتك، فالبوابة تتولاها مباشرة. وحساب التاجر يُفتح باسم منشأتك لأن المبالغ تُسوى في حسابها البنكي، ونعتمد على إشعار البوابة الموثق مع استعلام دوري، ونبني الاسترداد الكامل والجزئي بإشعارات دائنة، ومطابقة يومية مع تقارير البوابة. التفاصيل في صفحة ربط الدفع الإلكتروني بالتطبيقات، والربط بالأنظمة المحاسبية في صفحة تكامل التطبيقات مع الأنظمة.
الخلاصة: قدّر الفاتورتين معًا قبل أن تختار
تكلفة الدفع الإلكتروني ليست رقم التطوير وحده ولا نسبة البوابة وحدها. التطوير يحدده نموذج البيع وعدد الوسائل وعمق الاسترداد والمطابقة، ويُدفع مرة. والرسوم يحددها مزيج الوسائل ومتوسط الطلب وشروط البوابة، وتُدفع ما دمت تبيع. احسب الثانية بأرقامك قبل أن توقع مع البوابة، واطلب في الأولى الحالات والاسترداد والمطابقة بأسمائها.
لتقدير تكلفة إضافة الدفع إلى تطبيقك، أرسل وسائل الدفع ونموذج البيع المطلوبين عبر طلب تقدير لإضافة مزايا، ونرد بتقدير يذكر الحالات المشمولة وما يُدفع للبوابة مباشرة.
أسئلة شائعة
عادة لا. رسوم العمليات تدفعها منشأتك للبوابة مباشرة، وتُخصم غالبًا من المبالغ قبل تسويتها في حسابك. عرض التطوير يغطي بناء مسار الدفع وحالاته والاسترداد والمطابقة. اطلب أن يذكر العرض صراحة ما يُدفع للشركة وما يُدفع للبوابة.
يعتمد على ما تبيعه. السلع والخدمات التي تُستهلك خارج التطبيق، كالطلبات والحجوزات والخدمات المنزلية، تُدفع ببوابة دفع أو Apple Pay. أما المحتوى والمزايا الرقمية داخل التطبيق فتُلزم فيها إرشادات المتجرين غالبًا بنظام الشراء داخل التطبيق، مع استثناءات محددة.
الاشتراكات تحتاج حفظ البطاقة لدى البوابة والتجديد ومعالجة فشل التحصيل وتحديث البطاقة. والتقسيط ربط منفصل مع مزوده واعتماد لمنشأتك لديه واسترداد يمر عبره. كل منهما حالات جديدة تُبنى وتُختبر، فهي ليست زرًا إضافيًا في صفحة الدفع.
احسب بأرقامك لا بالنسبة المئوية وحدها: مزيج الوسائل التي يستخدمها عملاؤك، ومتوسط قيمة الطلب، ونسبة الاسترداد. ثم قارن النسبة لكل وسيلة، والرسم الثابت لكل عملية، ورسوم الإعداد والاشتراك، وسياسة رسوم الاسترداد، ومدة التسوية، وما تدعمه البوابة تقنيًا.
في التصميم السليم لا. بيانات البطاقة تُدخل في واجهة البوابة أو عبر رموزها ولا تمر بخوادم التطبيق، وهذا يقلل متطلبات أمن بيانات البطاقات على منشأتك كثيرًا. حتى الدفع المتكرر يعتمد على رمز تحفظه البوابة لا على رقم البطاقة.
خدمات وصفحات مرتبطة
اقرأ أيضًا
كم يكلف إضافة الدفع إلى تطبيقك تحديدًا؟
أرسل وسائل الدفع ونموذج البيع المطلوبين، ونرد بتقدير يذكر حالات الدفع والاسترداد والمطابقة المشمولة، وما يُدفع للبوابة مباشرة.