الاحتيال في الدفع الإلكتروني للتجار: لقطات شاشة مزيفة وإيصالات كاذبة ووصول مسروق

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

الاحتيال في الدفع الإلكتروني للتجار: ما يتركه ‎3-D Secure على عاتقكم

ChariPay منصة دفع مغربية، مزوّد خدمات دفع (PSP) تشغّله Chari Money، مؤسسة أداء مرخَّصة من بنك المغرب. تمرّ الأداءات بالبطاقة عبر مصادقة ‎3-D Secure: يؤكّد حامل البطاقة العملية لدى بنكه، وهو ما يحمي التاجر من معظم حالات عدم الأداء والنزاعات. إنها حماية حقيقية، لا ضمان مطلق، وتخص أمرًا واحدًا: الأداء بالبطاقة نفسه. ولفهم ما يُفشل المصادقة، اقرؤوا ‎3-D Secure ونسب النجاح.

أما عمليات الاحتيال الموصوفة هنا فتلتفّ على البطاقة. فهي لا تحاول الأداء ببطاقة شخص آخر؛ بل تحاول إقناعكم بأن أداءً قد تمّ، أو دفعكم إلى إعادة مال، أو الاستيلاء على حسابكم. ولا يستطيع ‎3-D Secure شيئًا هنا، لأنه لا يوجد أداء بالبطاقة أصلًا. إليكم السيناريوهات الستة في هذا الدليل، مع ما يُعتدّ به أو يحميكم في كل منها:

احتيال لقطة شاشة الدفع والإيصال الكاذب

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

ما يُعتدّ به هو حالة الأداء لدى ChariPay، التي تقرؤونها بأنفسكم. فلرابط الدفع حالة واضحة — نشط، مدفوع، ملغى، منتهي الصلاحية — ويصلكم إشعار في بوابة التاجر عند الاستخلاص. وإن كنتم مدمجين عبر API، فأكّدوا الطلبية عند استلام الويب هوك الموقَّع. وبالنسبة إلى الإيداع نقدًا في الوكالة، القاعدة نفسها: بمجرد أن تؤكد الشبكة الإيداع، يصبح الرابط «مدفوعًا» ويصلكم الإشعار في بوابة التاجر؛ ومن جهة الخادم تُقرأ حالة الرابط عبر GET /v1/payment-links/{reference}. وصورة إيصال الإيداع لا تعوّض هذه الحالة.

قبل شحن أي طلبية، طبّقوا هذه الخطوات:

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

وفي البيع عبر المراسلة، يُبرَم البيع في محادثة ويصل «الإثبات» في المحادثة نفسها: والقاعدة لا تتغيّر. والمسار الكامل، من الرسالة إلى رابط الدفع، في البيع عبر إنستغرام وواتساب.

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

إعادة التوجيه المزوّرة: الويب هوك هو المرجع

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

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

• التوقيع: X-CHARI-SIGNATURE هو HMAC-SHA256 يُحسب على الطابع الزمني والمحتوى الخام للطلب بالسرّ الخاص بنقطة الاستقبال لديكم؛ أعيدوا حسابه على البايتات الخام، قبل أي تحليل، وقارنوا في زمن ثابت.
• الطابع الزمني: ارفضوا كل طلب يتجاوز فيه فارق X-CHARI-TIMESTAMP خمس دقائق زيادةً أو نقصانًا، حتى لا تُعاد رسالة قديمة اعتُرضت.
• إزالة التكرار: اعتمدوا على Chari-Event-Id، الثابت للحدث نفسه في كل المحاولات، حتى لا يعتمد تسليم مكرَّر الطلبية نفسها مرتين.

والتنفيذ، مع المستقبِل الكامل، مفصَّل في إنجاح دمج الويب هوك.

طلب الاسترداد نحو وسيلة أداء أخرى

سيناريو «المبلغ الزائد» أكثر دهاءً. يدّعي زبون أنه دفع مرتين، أو أكثر من اللازم، ويطلب منكم إعادة الفرق بتحويل بنكي، إلى RIB يرسله لكم في رسالة. وأحيانًا لا يوجد الأداء الأصلي أصلًا: لا يرافقه سوى إثبات مزيف. وأحيانًا يوجد، لكن الـRIB لطرف ثالث.

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

لا تستردّوا أبدًا بتحويل نحو RIB وصلكم عبر رسالة. فمن بوابة التاجر، التحويل المنفَّذ لا يمكن إلغاؤه: وإن كان الـRIB لمحتال، فقد ذهب المال.

الاستيلاء على بوابة التاجر

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

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

وبالنسبة إلى التحويلات، تعمل حمايتان إضافيتان. كل تحويل يُرسَل من بوابة التاجر يُصادِق على إرساله رمز لمرة واحدة من ستة أرقام، يُرسَل بالبريد الإلكتروني إلى كل عنوان موافقة معيَّن في «Paramètres → Sécurité» (Settings → Security)؛ وتحدّدون عدد الموافِقين المطلوب. وتُطبَّق مهلة أمان بعد إضافة مستفيد جديد: فلا يستطيع متسلّل إضافة مستفيد مجهول وتحويل رصيدكم إليه في الحال. وتفاصيل كل طبقة في تأمين الوصول إلى بوابة التاجر.

مفتاح API المكشوف

يمنح مفتاح API برنامجًا ما وصولًا إلى حسابكم. والمفتاح سرّ: لا يوضع أبدًا في المتصفح، ولا في تطبيق محمول، ولا في مستودع git، ولا في لقطة شاشة. وأسباب التسريب عادية: مفتاح ملصوق في شفرة صفحة ويب، أو مستودع صار عموميًا، أو لقطة شاشة أُرسلت إلى مقدّم خدمات.

وإن احتُمل أن يكون أحدٌ قد اطّلع على مفتاح، فاستبدلوه دون انتظار: يمكن أن يتعايش مفتاحان مدة التدوير دون انقطاع، وهو ما يتيح لكم الانتقال قبل سحب المفتاح القديم. والسلوك الواجب، خطوة بخطوة، في حماية مفاتيح API.

الاحتيال الداخلي

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

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

عمليًا: اعهدوا بإعداد التحويلات والموافقة عليها إلى شخصين مختلفين، وأعطوا كل شخص أضيق دور يكفيه.

قائمة التحقق ضد الاحتيال لدى التاجر

1. 1لا تشحنوا أبدًا بناءً على لقطة شاشة أو صورة إيصال: اقرؤوا الحالة في بوابة التاجر.
2. 2أكّدوا الطلبيات الإلكترونية عند الويب هوك الموقَّع، لا عند إعادة التوجيه أبدًا.
3. 3تحقّقوا من كل ويب هوك: التوقيع على المحتوى الخام، والطابع الزمني في حدود خمس دقائق، وإزالة التكرار عبر Chari-Event-Id.
4. 4لا تستردّوا إلا العملية الأصلية، من بوابة التاجر أو عبر API، لا بتحويل نحو RIB وصلكم في رسالة.
5. 5لا تتقاسموا أي وصول أبدًا: لكل مستخدم دخوله الخاص إلى بوابة التاجر، ويفعّل المصادقة الثنائية (TOTP) من إعدادات حسابه.
6. 6وزّعوا الأدوار: أمناء صندوق للاستخلاص، ومحاسب للقراءة، وعدد محدود من الأشخاص المخوَّلين للعمليات الصادرة.
7. 7عيّنوا عناوين الموافقة على التحويلات في «Paramètres → Sécurité» وحدّدوا عدد الموافِقين المطلوب.
8. 8اعتبروا كل مستفيد جديد إشارة: فالإضافة التي لم تقوموا بها تستدعي تحققًا فوريًا.
9. 9أبقوا مفاتيح API من جهة الخادم ودوّروها عند أدنى شك.
10. 10راجعوا صلاحيات الوصول عند مغادرة أي متعاون.

وما تقوم به المنصة من جهتها — محاسبة بالقيد المزدوج تُطابَق يوميًا، ومراقبة مستمرة، وإخفاء المعطيات الحساسة في السجلات — موجود في صفحة الأمان والامتثال.

أسئلة شائعة

كيف أعرف إن كانت لقطة شاشة الدفع حقيقية؟

لا يمكنكم معرفة ذلك من الصورة، ولا تحتاجون إليه. افتحوا بوابة التاجر من جلستكم أنتم واقرؤوا حالة الرابط أو المعاملة: «مدفوع»، بالمبلغ الصحيح. وإن كنتم مدمجين عبر API، فانتظروا الويب هوك الموقَّع. وما دامت هذه الحالة لا تظهر من جهتكم، فالطلبية غير مؤدّاة، مهما كانت اللقطة التي وصلتكم.

أرسل لي زبون صورة إيصال إيداعه النقدي: هل هذا كافٍ؟

لا. بالنسبة إلى أداء نقدي عبر رابط دفع، بمجرد أن تؤكد الشبكة الإيداع، يصبح الرابط «مدفوعًا» ويصلكم الإشعار في بوابة التاجر؛ ومن جهة الخادم تُقرأ حالة الرابط عبر GET /v1/payment-links/{reference}. وبالنسبة إلى طلبية من متجركم المستضاف، اقرؤوا حالتها في بوابة التاجر. انتظروا هذه الحالة قبل التسليم: فصورة الإيصال لا تعوّضها.

هل تكفي صفحة التأكيد لإثبات أن الزبون قد أدّى؟

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

هل يحمي ‎3-D Secure التاجر من كل أنواع الاحتيال؟

لا. يحمي ‎3-D Secure التاجر من معظم حالات عدم الأداء والنزاعات في الأداءات بالبطاقة، لأن حامل البطاقة يؤكد العملية لدى بنكه. لكنه لا يستطيع شيئًا أمام احتيال لا يقع فيه أي أداء بالبطاقة: لقطة شاشة مزيفة، أو إيصال كاذب، أو إعادة توجيه مزوّرة، أو طلب استرداد نحو حساب آخر، أو وصول مسروق إلى بوابة التاجر.

يطلب زبون استرداد المبلغ في حساب آخر: ماذا أفعل؟

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

كيف أمنع متعاونًا من إطلاق تحويل بمفرده؟

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

ماذا أتحقق منه قبل شحن طلبية مؤدّاة عبر الإنترنت؟

ثلاثة أمور، تُقرأ من جهتكم لا في رسالة الزبون: حالة الأداء — في بوابة التاجر أو عبر API أو في الويب هوك الموقَّع —، والمبلغ المستخلَص مقارنةً بمبلغ الطلبية، والمرجع الذي يربط الأداء بالزبون الصحيح. وبالنسبة إلى الإيداع النقدي، انتظروا أن يصبح الرابط «مدفوعًا».

الخطوة التالية

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