بنية المدفوعات وتكامل بوابات الدفع

ما بنية المدفوعات، ومتى تحتاج إلى اهتمام مستقل؟

بنية المدفوعات هي الهيكل البرمجي الذي يحدد كيف تبدأ عملية الدفع، وكيف يُتحقق من هوية حامل البطاقة، وكيف تُسجَّل النتيجة في نظامكم وبأي درجة من اليقين، وكيف تُتابَع المبالغ المستردة والقيود المحاسبية. فخلف زر دفع واحد تعمل أنظمة الطلبات والمخزون والفوترة والإشعارات والتقارير معًا.

إضافة الدفع القياسية في منصة تجارة إلكترونية جاهزة تكفي معظم المتاجر البسيطة. أما تصميم مسار الدفع بشكل مستقل فيصبح ضروريًا في الحالات التالية:

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

ما الذي تفعله UNIT İstanbul في بنية الدفع، وما الذي لا تفعله؟

تقديم خدمات الدفع ومعالجة بيانات البطاقات والاحتفاظ بأموال العملاء أنشطة مرخّصة وخاضعة للتنظيم في تركيا وفي الأسواق الأخرى التي نعمل فيها. وUNIT İstanbul ليست مؤسسة دفع ولا مؤسسة نقود إلكترونية ولا بنكًا. فنحن نصمم ونبني البرمجيات التي ترتبط بالبنية التي تقدمها المؤسسات الحاصلة على هذه التراخيص.

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

تكامل نقاط البيع الافتراضية للبنوك أم مؤسسة دفع؟

نقطة البيع الافتراضية (Virtual POS) خدمة يقدمها البنك للتاجر ليتمكن من قبول البطاقات عبر الإنترنت. أما مؤسسات الدفع فتضع واجهة واحدة أمام بنوك ووسائل دفع متعددة؛ فيكون الانضمام والتكامل أسرع، لكن التوازن بين الرسوم والتحكم يختلف. ويعتمد الخيار الأنسب على حجم معاملاتكم، وحاجتكم إلى التقسيط، والقدرة التشغيلية لفريقكم.

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

كيف يُبنى مسار مصادقة حامل البطاقة (Three-Domain Secure)؟

مصادقة حامل البطاقة هي الخطوة التي يطلب فيها البنك من حامل البطاقة رمزًا لمرة واحدة أو موافقة عبر تطبيقه المصرفي قبل اعتماد الدفع، وتُعرف على نطاق واسع باسم Three-Domain Secure. ينتقل المستخدم لفترة وجيزة إلى شاشة البنك، وإذا لم يُبنَ المسار بعناية فقد يبقى الطلب غير مؤكد رغم أن المبلغ قد خُصم.

1. 1.قبل الدفع، يُحفظ الطلب بمعرّف فريد وحالة «قيد الانتظار».
2. 2.يبدأ طلب الدفع من الخادم، ويُؤخذ المبلغ والعملة من سجل الطلب لا من البيانات التي يرسلها المتصفح.
3. 3.يُوجَّه المستخدم إلى شاشة المصادقة أو تُفتح داخل الصفحة، وعلى الهاتف تُصمَّم لتكتمل دون مغادرة التطبيق.
4. 4.عند العودة من البنك، تُعالَج النتيجة استنادًا إلى استعلام تحقق من جهة الخادم لدى المزوّد أو إلى إشعار موقّع، لا إلى متصفح المستخدم.
5. 5.يُؤكَّد الطلب ويُخصم المخزون وتُرسل الإشعارات، وتكتمل هذه الخطوة على الخادم حتى لو أغلق المستخدم صفحة العودة.

كيف تُحفظ البطاقات ويُقلَّص نطاق PCI DSS؟

PCI DSS هو معيار أمن قطاع البطاقات الذي يجب أن تلتزم به كل مؤسسة تعالج بيانات البطاقات أو تنقلها أو تخزنها. والطريقة الأكثر فاعلية لتخفيف عبء الامتثال هي ضمان ألا تصل أرقام البطاقات إلى خوادمكم أصلًا.

• حقول الدفع المستضافة: تُدخل بيانات البطاقة في حقول آمنة يضمّنها المزوّد في صفحتكم أو في صفحة الدفع الخاصة به، ولا يتلقى نظامكم سوى رمز مميز (token).
• الترميز (Tokenisation): تستخدم المدفوعات المتكررة بالبطاقة المحفوظة والاشتراكات الرمز الذي يصدره المزوّد بدلًا من رقم البطاقة.
• عدم حفظ رموز الأمان: لا يُكتب الرمز الموجود على ظهر البطاقة في أي قاعدة بيانات أو سجل أو سجل أخطاء.
• إخفاء البيانات في السجلات: تُحجب بيانات البطاقات والهوية والتواصل تلقائيًا في سجلات الطلبات والاستجابات.
• فصل الصلاحيات: تُحفظ مفاتيح خدمة الدفع في مخزن أسرار مستقل، وتُمنح الصلاحيات لكل شخص على حدة، وتُبدَّل المفاتيح بانتظام.

يؤثر هذا النهج أيضًا في استبيان التقييم الذاتي لمعيار PCI DSS الذي ينطبق عليكم، ونوصي بإجراء التقييم النهائي مع مزوّدكم ومع مقيّم مؤهل عند الحاجة. وتُضبط معالجة البيانات الشخصية وفترات الاحتفاظ بها بما يتوافق مع إشعار الخصوصية الخاص بكم وفق قانون حماية البيانات التركي (KVKK).

كيف تُصمَّم الاشتراكات والأسواق الإلكترونية وتقسيم المدفوعات؟

الاشتراكات والمدفوعات المتكررة

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

مدفوعات الأسواق الإلكترونية والتجار الفرعيين

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

كيف تُدار المبالغ المستردة والإلغاءات والتسوية؟

الإلغاء (void) يعكس المعاملة بالكامل قبل التسوية في نهاية اليوم، أما الاسترداد فيعيد كامل المبلغ أو جزءًا منه إلى البطاقة بعد تسوية المعاملة. وأما الاعتراض على المعاملة (chargeback) فيبدأ بنزاع يرفعه حامل البطاقة لدى بنكه ويتطلب جمع الأدلة. وينبغي نمذجة هذه الحالات الثلاث بوصفها حالات منفصلة في البرنامج.

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

كيف تُدمج المدفوعات داخل التطبيقات والتدفقات المالية؟

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

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

كيف تُعالَج أخطاء الدفع وانتهاء المهلة والاحتيال؟

أخطر حالة في المدفوعات هي المعاملة مجهولة النتيجة: أُرسل الطلب وانتهت مهلة الاستجابة. وإعادة محاولة الدفع دون تبصّر قد تؤدي إلى خصم مزدوج. وتقوم بنية الدفع المتينة على المبادئ التالية:

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

كيف يُقاس التحويل في خطوة الدفع ويُحسَّن؟

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

تفيدنا جذورنا في وكالة التسويق هنا: فنحن نُعدّ أحداث الدفع باللغة نفسها التي يُقاس بها الإعلان والتحليلات، ونخطط منذ البداية لكيفية عودة بيانات الإيرادات بدقة إلى الحملات. وننفذ التحسينات على مسار التحويل كاملًا مع فريق CRO والتحليلات لدينا؛ وللموقع التجاري ككل، اطلعوا على خدمة المواقع والتجارة الإلكترونية.

ما الذي يحدد تكلفة مشروع بنية الدفع؟

تتحدد التكلفة أساسًا بعدد المزودين المطلوب ربطهم، ونموذج الدفع (لمرة واحدة، أو اشتراك، أو سوق إلكترونية)، وعدد القنوات (الويب والهاتف ومركز الاتصال)، وعمق تكاملات المحاسبة وERP، وحالة النظام القائم. كما يؤثر في الجدول الزمني الوصول إلى بيئة الاختبار لدى المزوّد، وعملية الموافقة على التاجر، واختبارات المزوّد قبل الإطلاق. وبعد الاستكشاف نعرض النطاق والمخرجات وشروط الصيانة في عرض مكتوب. ويمكنكم الاطلاع على خدماتنا البرمجية الأخرى ومراجعنا في صفحة Unit Software، أو التواصل معنا للحديث عن مشروعكم.