المسافر
عضو نشيط
- التسجيل
- 2025/12/03
- المشاركات
- 189
- التفاعل
- 0
- النقاط
- 16
بوابات الدفع في تركيا: من موافقة البطاقة إلى تسوية التاجر
Payment Gateways in Turkey: From Card Approval to Merchant Settlement
Payment Gateways in Turkey: From Card Approval to Merchant Settlement
ظهور عبارة «تم الدفع» أمام العميل بداية إجراء مالي، وليس دليلًا على وصول قيمة الطلب إلى حساب المتجر. صاحب المتجر يحتاج أن يعرف من وافق على البطاقة، وأين سُجلت المعاملة، وما الحدث الذي يسمح بالتجهيز، ومتى يستطيع استخدام المال لدفع المورد. هذا الدليل يشرح رحلة المعاملة داخل متجر يبيع من تركيا، مع سجل عملي يفصل الطلب عن الدفع والتحويل البنكي. كل الأرقام المستخدمة لاحقًا أمثلة افتراضية للتدريب، وليست رسوم مزود أو مدة تسوية معلنة. الغرض أن تستطيع قراءة عقدك وتقريرك، وتحديد السؤال الصحيح عند اختلاف الأرصدة.
رحلة الدفع تبدأ من طلب واضح ومبلغ وعملة محددين.
الأطراف التي تشترك في المعاملة
العميل يستخدم بطاقة أصدرها بنك، والمتجر يتعامل مع بنك قبول أو مزود خدمة دفع وفق نموذج الخدمة. شبكة البطاقة تنقل الرسائل بين أطراف المنظومة، بينما منصة المتجر تحفظ الطلب والمنتجات والعنوان. وقد تقدم بوابة الدفع صفحة لإدخال البطاقة وإجراء التحقق وإرسال النتيجة. وجود عدة أطراف يفسر لماذا تكون رسالة المتجر مختلفة عن إشعار الهاتف أو الحركة الظاهرة مؤقتًا في تطبيق البنك.
ابدأ برسم مسار خدمة الدفع التي تعاقدت عليها: من الطرف المتعاقد معك، ومن يتلقى الأموال، ومن يحولها إلى حسابك، ومن يرد على نزاع العميل؟ اسم الإضافة داخل المتجر قد يكون مختلفًا عن الاسم القانوني في العقد. احتفظ ببيانات الدعم المالي والتقني منفصلة، وبمرجع طلبك الداخلي ومرجع المزود. هكذا لا تنتهي مشكلة تسوية في صندوق دعم القالب أو مشكلة إشعار في قسم المحاسبة.
| الطرف | وظيفته العملية | ما تتحقق منه |
|---|---|---|
| المتجر | إنشاء الطلب وتنفيذه | المبلغ والعنوان والمخزون |
| البنك المصدر | قرار البطاقة والتحقق | النتيجة ورمز الرفض عبر المزود |
| مزود الدفع | تسجيل المعاملة وإبلاغ نتيجتها | مرجع المعاملة والعقد والتقرير |
| حساب التاجر البنكي | استقبال التحويل | القيمة والتاريخ ومرجع الدفعة |
إنشاء طلب يمكن تتبعه
أنشئ رقم طلب فريدًا قبل إرسال محاولة الدفع، واحفظ المبلغ النهائي بعد الخصم ورسوم التوصيل والعملة. أضف رقمًا مستقلًا لكل محاولة، لأن العميل قد يعيد المحاولة بعد رفض أو انقطاع. إذا شاركت محاولتان ناجحتان رقم الطلب نفسه، يجب أن تستطيع اكتشافهما دون إنشاء شحنتين. لا تستخدم اسم العميل وحده للمطابقة؛ الأسماء تتكرر، وقد يدفع شخص لطلب شخص آخر.
تغيير السلة أثناء الرجوع من صفحة الدفع يحتاج قاعدة واضحة. خزّن نسخة المبلغ الذي أُرسل بالفعل، ثم قارنها بالمبلغ المعتمد لدى المزود. إذا انتهت صلاحية السعر أو تغير المخزون، لا تعدل المعاملة المالية القديمة صامتًا. افتح مسار معالجة محددًا مع العميل. سجل أوقات إنشاء الطلب ومحاولة الدفع ونتيجة المزود باستخدام منطقة زمنية معروفة، حتى لا يظهر اختلاف منتصف الليل كأنه عملية مفقودة.
الموافقة على البطاقة والخصم
الموافقة تعني أن محاولة الدفع اجتازت القرار الذي يتطلبه المسار، لكن معنى الحجز والخصم والتحصيل يعتمد على الخدمة. بعض الحلول توفر تفويضًا يتبعه تحصيل منفصل، وبعضها ينفذ الدفع في خطوة مرتبطة مباشرة بالطلب. لذلك اسأل مزودك هل تستخدم خدمة بيع مباشر أم تفويضًا مسبقًا، وكيف تُقرأ حالات المعاملة. لا تعتبر أي مبلغ ظاهر في تطبيق العميل تحصيلًا نهائيًا قبل مراجعة الحالة الرسمية.
إذا كانت الخدمة تدعم التفويض المسبق، حدد من يحصّل ومتى، وماذا يحدث لو نفد المخزون أو انتهت صلاحية التفويض. أما في البيع المباشر فراجع نجاح الدفع ومبلغه وعملته قبل الإفراج عن الطلب. يجب أن يفهم فريق التجهيز الفارق بين «محاولة جارية» و«مبلغ محصل»، وأن يملك قائمة حالات مسموحة للشحن. هذا إجراء تشغيلي داخلي تبنيه من وثائق الخدمة التي تستخدمها، وليس قاعدة واحدة لجميع البوابات.
تنبيه: إشعار خصم من العميل أو صورة شاشة لا يحل محل تحقق المتجر من المعاملة لدى المزود.
دور التحقق عبر 3D Secure
التحقق عبر 3D Secure يضيف خطوة مرتبطة بإثبات استخدام البطاقة في مسار الدفع، وقد يطلب البنك إجراءً من العميل. نجاح هذه الخطوة لا يعني تلقائيًا نجاح جميع الخطوات التالية؛ يمكن أن تفشل العودة أو المعالجة أو تسجيل النتيجة. احتفظ ببيانات الحالة التي يسمح المزود بعرضها، ولا تطلب من العميل إرسال رمز التحقق أو كامل بيانات البطاقة إلى موظف الدعم.
تختلف المسؤولية عن النزاع حسب سبب الاعتراض وقواعد الشبكة والبنك والعقد ونتيجة المصادقة. لا تقدم وعدًا بأن استخدام 3D Secure يلغي الاحتيال أو يمنع استردادًا قسريًا. ما يزال نزاع عدم التسليم أو اختلاف المنتج يحتاج إثباتًا. عمليًا، عامل المصادقة ونجاح الدفع والتنفيذ كأحداث مستقلة، واربطها بمرجع واحد. بذلك تستطيع شرح ما حدث دون تحويل حماية تقنية إلى ضمان مالي شامل.
ربط الطلب بالمعاملة يقلل الأخطاء عند التجهيز والاسترداد.
النتيجة المعتمدة وحالة الطلب
صفحة نجاح يراها العميل تساعد تجربة الشراء، لكنها قد تُفتح قبل وصول رسالة الخادم أو حتى تُستدعى دون دفع ناجح إذا كان الربط ضعيفًا. وثائق PayTR تفصل صفحة رجوع العميل عن عنوان إشعار النتيجة، وتطلب معالجة الإشعار وفق تعليماتها. كما توفر حلول مثل iyzico استعلامًا عن المعاملة. استخدم نتيجة موثوقة تتحقق منها آليًا، ثم حدث الطلب وفق قواعد متجرك.
أعدّ خريطة بين حالات المزود وحالات المنصة. لا تجعل «بانتظار الدفع» مرادفًا لـ«مرفوض»، ولا «مدفوع» مرادفًا لـ«وصل التحويل». عند التناقض أوقف التنفيذ مؤقتًا واستعلم بمرجع المعاملة. يتولى موظف محدد قائمة الطلبات غير المحسومة، مع موعد مراجعة وتوثيق القرار. فشل حفظ الطلب بعد دفع ناجح يحتاج إصلاح الربط وإعادة ربط المعاملة، لا مطالبة العميل بالدفع مرة ثانية دون تحقق.
| الحدث | حالة تشغيلية مقترحة | القرار |
|---|---|---|
| المحاولة بدأت | بانتظار نتيجة | حجز مؤقت للمخزون |
| نجاح مؤكد ومبلغ مطابق | مدفوع قابل للتجهيز | تنفيذ حسب فحص المتجر |
| نتيجة متناقضة | قيد التحقق | استعلام وإيقاف التجهيز |
| استرداد مؤكد | مسترد كاملًا أو جزئيًا | تحديث الرصيد والطلب |
من الدفع الناجح إلى التسوية
التسوية تجمع حركات مالية وفق جدول وشروط تعاقدية ثم تنتج مبلغًا مستحقًا أو محولًا للتاجر. قد تقع بين البيع والتحويل أيام عمل أو فترات أخرى، وقد تتأثر بالعطلات ووقت قطع الدفعات وطريقة الدفع والمخاطر. اقرأ الموعد المكتوب لخدمتك، وكيف يبدأ حساب المدة، وهل توجد شروط لاستلام أول دفعة. لا تبن توقع السيولة على تجربة متجر آخر أو إعلان لا يخص نشاطك.
تقرير التسوية قد يجمع عشرات الطلبات، بينما يظهر في البنك تحويل واحد. ولهذا تحتاج مرجع الدفعة مع تفاصيل المعاملات الداخلة فيها. وثائق ملفات التسوية لدى iyzico تعرض حقولًا تتعلق بالمعاملة والعمولة وتاريخ التسوية ومرجعها. اطلب تقريرًا يمكن تصديره، واحتفظ بنسخة لكل فترة. إذا تأخر المال فابدأ بسؤال هل أصبح مستحقًا أصلًا، ثم هل أُرسل، ثم هل استقبله البنك.
العمولة والحجز والاسترداد
هناك فرق بين تكلفة تخصم نهائيًا ومبلغ يبقى محجوزًا ليُفرج عنه لاحقًا. العمولة وفق العقد تكلفة خدمة، أما الاحتياطي أو الحجز فقد يرتبط بالمخاطر أو المرتجعات أو مراجعة نشاط. لا تسجل الحجز كله على أنه خسارة، ولا تعتبره نقدًا متاحًا. اطلب أساس كل خصم، وتاريخ الإفراج المتوقع، والشروط التي تسمح بتغيير الاحتياطي أو تأخير التحويل.
قد تُخصم الاستردادات من رصيد غير محول أو من دفعات لاحقة، وفق آلية الخدمة. اسأل هل تُرد العمولة عند الإلغاء أو الاسترداد، وهل توجد رسوم مستقلة، وكيف يعالج نقص الرصيد. الرد للعميل قد يستغرق وقتًا حتى يظهر لدى بنكه؛ لذلك احتفظ بمرجع الاسترداد ونتيجته. افصل تاريخ قبول طلب رد المال عن تاريخ نجاحه المالي وعن تاريخ ظهوره للعميل.
مثال افتراضي لحركة الأموال
لنفترض متجرًا سجل مدفوعات ناجحة قيمتها عشرة آلاف ليرة خلال فترة واحدة. نفترض فقط لغرض الحساب عمولة ثلاثمئة ليرة، واستردادًا بمبلغ خمسمئة، وحجزًا مؤقتًا بألف. إذا لم توجد حركات أخرى، يصبح المبلغ المحول ثمانية آلاف ومئتي ليرة. هذه القيم لا تصف عرض iyzico أو PayTR ولا تتضمن جميع أنواع الضرائب أو رسوم العقود؛ إنها تكشف الفرق بين المبيعات والتحويل.
إذا أُفرج لاحقًا عن الحجز كاملًا دون خصومات إضافية، تدخل ألف ليرة في دفعة أخرى. لا تنسبها إلى مبيعات جديدة. وإن كان الاسترداد مرتبطًا ببيع سابق، يظهر في الفترة المالية المناسبة مع مرجعه. التفسير الصحيح لتحويل صغير يبدأ بتفكيك البنود، لا باستنتاج أن البنك أخذ الفرق. استخدم إشارات موجبة وسالبة ثابتة في السجل، ودوّن أي تسوية يدوية حتى يمكن إعادة الحساب.
| البند الافتراضي | الأثر بالليرة | التفسير |
|---|---|---|
| مدفوعات ناجحة | 10,000 | إجمالي الحركة |
| عمولة مفترضة | −300 | تكلفة خدمة |
| استرداد مؤكد | −500 | مال أُعيد |
| حجز مؤقت | −1,000 | رصيد غير متاح الآن |
| التحويل المتوقع | 8,200 | 10,000 − 300 − 500 − 1,000 |
النتيجة: التحويل 8,200 ليرة، والحجز 1,000 ليرة بند مستقل يستلزم متابعة.
تقرير التسوية وكشف البنك يوضحان المال المتاح فعليًا.
مطابقة الطلب والمعاملة والدفعة
احفظ ثلاثة مراجع على الأقل: رقم الطلب، ومعرف الدفع لدى المزود، ومرجع التحويل أو التسوية. اربط رد المال بمعرف الدفع الأصلي لا بتاريخ الاسترداد فقط. في نهاية الفترة ابدأ من قائمة المعاملات الناجحة، ثم طابقها مع الطلبات، ثم مع بنود التسوية، وأخيرًا مع كشف البنك. افتح قائمة فروق تحمل مبلغ الفرق وصاحبه وسببًا محتملًا وموعد إغلاق.
تعامل مع فروق التوقيت أولًا، ثم فرق المبلغ والعملة، ثم العمليات غير المرتبطة. قد تقع المعاملة في يوم وتدخل دفعة يوم آخر. وقد يحتفظ التقرير بمبلغ أصلي وبمبلغ مسدد بالليرة. لا تخلط الرقمين أو تستخدم سعر صرف يدويًا دون أساس. أعط المحاسب الملفات الأصلية ووصف البنود، حتى يميز البيع والضريبة والعمولة والرصيد المحجوز وفق المستندات المناسبة.
| حقل السجل | مثال افتراضي | سبب الاحتفاظ به |
|---|---|---|
| رقم الطلب | TR-2501 | ربط المنتج والعميل |
| مرجع الدفع | PAY-EX-01 | الاستعلام والاسترداد |
| مرجع التسوية | SET-EX-07 | ربط التحويل المجمع |
| الفرق ومسؤوله | 50 ليرة / المالية | منع بقاء فرق مجهول |

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

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

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