أمان المدفوعات في تطبيقك يقوم على ثلاث قواعد: لا تجعل بيانات البطاقة تمر عبر خادمك، بل استخدم صفحة دفع أو حقولاً مستضافة لدى البوابة تعطيك رمزاً بدل الرقم؛ وفعّل التحقق الثلاثي 3D Secure ليؤكد البنك هوية حامل البطاقة؛ وأكّد كل عملية من الخادم عبر Webhook موقّع بمبلغ تحسبه أنت. بهذا يبقى نطاق التزامك بمعايير PCI DSS في أصغر حد ممكن.
- ما هو 3d secure
- هل احتاج شهادة pci لمتجري
- كيف احمي بيانات البطاقات في موقعي
- امان الدفع الالكتروني في التطبيقات
- لماذا يطلب رمز تحقق عند الدفع بالبطاقة
- هل حفظ بيانات البطاقة في قاعدة البيانات قانوني
كيف تجعل الدفع في تطبيقك آمناً؟
لكي تجعل الدفع في تطبيقك آمناً طبّق ثلاث قواعد قبل أي شيء: أولاً، لا تجعل رقم البطاقة يمر عبر خادمك؛ دع البوابة تجمعه في صفحتها أو في حقول مستضافة لديها، وتعطيك رمزاً بدلاً منه. ثانياً، فعّل التحقق الثلاثي 3D Secure ليؤكد بنك العميل أنه صاحب البطاقة. ثالثاً، أكّد كل عملية من الخادم عبر إشعار موقّع من البوابة، بمبلغ حسبته أنت لا المتصفح.
هذه القواعد تحميك من أكثر المخاطر شيوعاً: تسرب بيانات البطاقات، والعمليات الاحتيالية ببطاقات مسروقة، والتلاعب بالأسعار من المتصفح، والطلبات المعتمدة دون دفع حقيقي. والجميل أنها لا تحتاج فريق أمن معلومات؛ تحتاج اختيارات صحيحة عند الربط.
هذا مهم أكثر إن بُني تطبيقك بالذكاء الاصطناعي، لأن الكود قد يبدو صحيحاً ويخفي ثغرة في منطق الدفع. راجع أيضاً هل الكود المولد بالذكاء الاصطناعي آمن؟.
أفضل طريقة لحماية بيانات البطاقة ألا تلمسها أصلاً.
ما هو 3D Secure وكيف يعمل؟
3D Secure طبقة تحقق إضافية يطلب فيها بنك العميل تأكيد أنه صاحب البطاقة. تعرفه من رمز يصلك برسالة نصية، أو طلب موافقة في تطبيق البنك أثناء الدفع. اسمه التجاري يختلف حسب شبكة البطاقة، والفكرة واحدة: البنك المصدر يشارك في القرار.
النسخة الحديثة منه (3DS2) أذكى من القديمة. ترسل البوابة للبنك معلومات عن العملية والجهاز، فيقرر البنك أحد مسارين:
- البنك يرى العملية منخفضة المخاطر
- تتم الموافقة في الخلفية دون رمز
- تجربة أسرع وسلات متروكة أقل
- شائع مع العملاء المعتادين والأجهزة المعروفة
- البنك يريد تأكيداً إضافياً
- يُطلب رمز أو موافقة من تطبيق البنك
- خطوة إضافية لكنها تحمي من الاحتيال
- شائع مع المبالغ الكبيرة أو الأنماط غير المعتادة
الفائدة لك كتاجر مزدوجة: احتيال أقل، وفي كثير من الحالات تنتقل مسؤولية اعتراضات الاحتيال إلى البنك المصدر عندما تكون العملية موثقة بنجاح. القواعد التفصيلية تحددها شبكات البطاقات وبوابتك، فاسأل بوابتك عنها.
ما معايير PCI DSS ومتى تنطبق عليك؟
PCI DSS معيار أمني عالمي يضعه مجلس معايير أمان صناعة بطاقات الدفع، وينطبق على كل من يقبل أو يعالج أو يخزن بيانات البطاقات. الخبر الجيد: حجم ما تلتزم به يتحدد بدرجة كبيرة بطريقة ربطك مع البوابة.
| طريقة الربط | هل تمر البطاقة بخادمك؟ | حجم العبء عليك |
|---|---|---|
| تحويل لصفحة دفع البوابة | لا | الأصغر عادة: استبيان تقييم ذاتي مختصر |
| حقول دفع مستضافة داخل صفحتك | لا، الحقول تتبع البوابة | صغير، مع حماية صفحتك من السكربتات الضارة |
| Apple Pay أو محافظ رقمية | لا، يصلك رمز مشفر | صغير |
| إرسال رقم البطاقة من خادمك للبوابة | نعم | كبير جداً: ضوابط وفحوص ومراجعات واسعة |
| تخزين أرقام البطاقات لديك | نعم، ومخزنة | الأكبر، ونادراً ما يكون مبرراً لمشروع ناشئ |
كيف تبقي بيانات البطاقات خارج تطبيقك؟
- 1اختر نموذج الدفع المستضاف
استخدم صفحة الدفع الجاهزة من البوابة أو حقولها المستضافة. شكلها قابل للتخصيص غالباً، والأرقام تذهب مباشرة للبوابة.
- 2احفظ الرمز لا البطاقة
إن أردت الدفع بنقرة واحدة أو الاشتراكات، اطلب من البوابة حفظ البطاقة وخزّن الرمز وآخر أربعة أرقام ونوع البطاقة فقط.
- 3فعّل 3D Secure
اجعله مفعلاً لكل عمليات البطاقات ما لم تنصحك البوابة بغير ذلك لحالة محددة.
- 4نظّف السجلات
تأكد أن أدوات التتبع والتحليل لا تقرأ حقول الدفع، وأن سجلات الخادم لا تحتوي بيانات حساسة.
- 5أغلق الأبواب الجانبية
لا نماذج تواصل تقبل أرقام بطاقات، ولا دفع يدوي بإملاء الرقم على الهاتف دون نظام مخصص.
في فنّان يتم ربط الدفع عبر بوابات مرخصة من خلال صفحة المدفوعات، بحيث تجمع البوابة بيانات البطاقة ويتلقى تطبيقك النتيجة فقط. ولمزيد عن الاستضافة والضوابط راجع صفحة الثقة والأمان.
أخطاء أمنية في منطق الدفع لا تتعلق بالبطاقة
حتى لو لم تلمس البطاقة أبداً، يمكن أن يُخترق منطق الدفع نفسه. هذه أخطاء نراها كثيراً في التطبيقات المبنية بسرعة:
- السعر من المتصفح: إن أرسل المتصفح المبلغ للخادم يمكن تعديله. احسب المبلغ دائماً في الخادم من المنتجات والكميات والكوبونات.
- التأكيد من صفحة النجاح: من يفتح رابط صفحة النجاح يدوياً قد يحصل على طلب معتمد. اعتمد على Webhook من البوابة.
- Webhook دون تحقق: تحقق من توقيع كل إشعار أو استعلم عن العملية لدى البوابة، وإلا أمكن لأي أحد إرسال إشعار مزيف.
- المعالجة المكررة: البوابة قد ترسل الإشعار أكثر من مرة. عالج كل عملية مرة واحدة فقط بمعرّفها.
- مفاتيح مكشوفة: المفتاح السري للبوابة مكانه إعدادات الخادم، لا كود الواجهة ولا مستودع GitHub.
- اختبار البطاقات المسروقة: محتالون يجربون مئات البطاقات بمبالغ صغيرة. حدد عدد المحاولات وأضف تحققاً عند النشاط المريب.
للتعمق في حماية المفاتيح اقرأ مفاتيح API والأسرار، وللاحتيال وإساءة استخدام رموز التحقق اقرأ إيقاف التسجيلات الوهمية والاحتيال.
احمِ ما حول الدفع: الحسابات والخوادم والبيانات
- التحقق الثنائي على حساب البوابة ولوحة إدارة تطبيقك وحساب الاستضافة والبريد.
- صلاحيات محدودة: موظف خدمة العملاء يرى الطلبات، لكنه لا يصدر استرداداً كبيراً دون موافقة.
- HTTPS في كل مكان مع شهادة SSL سارية، لا صفحة دفع فقط.
- سجل تدقيق لكل استرداد أو تعديل سعر أو تغيير إعدادات دفع: من فعل ماذا ومتى.
- نسخ احتياطية لقاعدة الطلبات مع اختبار الاستعادة.
- البيانات الشخصية: أسماء العملاء وجوالاتهم وعناوينهم تخضع لأنظمة حماية البيانات مثل نظام حماية البيانات الشخصية في السعودية وقانون حماية البيانات في الإمارات.
قائمة فحص أمان الدفع وطلب جاهز للمراجعة
- بيانات البطاقة تُجمع في صفحة البوابة أو حقولها المستضافة فقط.
- لا يوجد رقم بطاقة أو CVV في قاعدة البيانات أو السجلات.
- 3D Secure مفعل ومختبر على الجوال.
- المبلغ يُحسب في الخادم، والطلب يُعتمد بإشعار موقّع.
- كل إشعار يُعالج مرة واحدة فقط.
- المفاتيح السرية في إعدادات الخادم، والتحقق الثنائي مفعل على كل الحسابات.
- حد لعدد محاولات الدفع من نفس الجهاز أو الحساب.
راجع مسار الدفع في تطبيقي كمختبر أمان. تأكد أن بيانات البطاقة لا تمر عبر الخادم وأن الدفع يستخدم صفحة البوابة أو حقولها المستضافة، وأن 3D Secure مفعل. تحقق أن المبلغ يُحسب في الخادم من المنتجات والكوبونات لا من المتصفح، وأن الطلب لا يُعتمد إلا بعد Webhook تم التحقق من توقيعه، وأن تكرار الإشعار لا يكرر الطلب. ابحث عن أي مفتاح سري في كود الواجهة، وأي سجل يحفظ بيانات حساسة. أضف حداً لمحاولات الدفع الفاشلة. اعرض قائمة بالمشكلات مرتبة حسب الخطورة واقترح الإصلاح، ثم نفذه بعد موافقتي.
جرّبه في فنّانبعد هذه المراجعة امرّ على قائمة أمان التطبيقات المبنية بالذكاء الاصطناعي لتغطي بقية التطبيق.
الخلاصة
- أصغر عبء أمني تحققه عندما لا تدخل أرقام البطاقات إلى خادمك أو قاعدة بياناتك أبداً.
- 3D Secure يضيف تحقق البنك من حامل البطاقة، وغالباً يمر دون إزعاج للعملاء منخفضي المخاطر.
- معايير PCI DSS تنطبق على كل من يقبل البطاقات، لكن حجم ما تلتزم به يتحدد بطريقة ربطك.
- احسب المبلغ في الخادم، وتحقق من توقيع كل Webhook، ولا تثق بما يرسله المتصفح.
- احمِ مفاتيح البوابة وحسابات الإدارة بنفس جدية حماية البطاقات.
أسئلة شائعة
ما هو 3D Secure؟
هل احتاج شهادة PCI لمتجري؟
هل يجوز حفظ بيانات البطاقة في قاعدة بيانات تطبيقي؟
لماذا يطلب رمز تحقق عند الدفع بالبطاقة أحياناً ولا يطلبه أحياناً؟
هل Apple Pay يغني عن 3D Secure؟
اسأل مساعدك الذكي عن هذا الموضوع
انسخ هذا الطلب والصقه في مساعد الذكاء الاصطناعي الذي تستخدمه، ثم أضف تفاصيل حالتك.
أقرأ هذا الدليل: «أمان المدفوعات: 3D Secure وPCI وإبعاد بيانات البطاقات عن تطبيقك» https://fanann.com/ar/blog/payment-security-3d-secure/ سؤالي: ما هو 3d secure اعتمد على هذه الصفحة كمصدر واشرح لي الإجابة خطوة بخطوة بما يناسب حالتي، واذكر ما يجب أن أتحقق منه قبل أن أبدأ، واذكر رابط الصفحة كمرجع.