لماذا من المهم استخدام نماذج الدفع الأصلية

نموذج الدفع هو النقطة التي يدخل فيها المستخدم البيانات الأكثر حساسية: رقم البطاقة، CVC، تسجيل الدخول إلى المحفظة. إذا كان النموذج غير أصلي (موقع مزيف، حقل بطاقة «مكتوب ذاتيًا» في التاجر بدلاً من النموذج الذي يستضيفه المزود، والتكامل المعطل)، فأنت تخاطر بتسرب البيانات، وإخفاقات البنوك، واسترداد التكاليف والأقفال. النموذج الأصلي عبارة عن صفحة/أداة لمزود الدفع (PSP/bank) الذي اجتاز شهادة الأمان وهو متصل وفقًا للسيناريو الصحيح (iFrame/Hosted Fields/redirect).

ما هو «نموذج الدفع الأصلي»

تستضيفه PSP: PAN/CVC/term fields - داخل iFrame/Hosted Fields الخاص بالمزود أو على مجاله (إعادة التوجيه).

يتوافق مع PCI DSS: التاجر لا يرى ولا يخزن بيانات البطاقة «الخام»، ولا يتلقى سوى رمز.

يدعم SCA/3-D Secure 2: تأكيد الدفع من خلال البنك (الدفع/الرسائل القصيرة/القياسات الحيوية).

محمي بالبروتوكولات: TLS الصارمة، HSTS، CSP، حماية النقر.

يمكن تحديده: النطاق/الشهادة الصحيحة و UX يمكن التنبؤ به مع تفاصيل التاجر.

لماذا هو مهم (للمستخدم والأعمال)

للمستخدم

حماية بيانات البطاقات: الترميز وعزل حقول البطاقات باستثناء «الاختلاس» من قبل التاجر والنصوص.

تقليل التصيد وسرقة الحساب: يؤكد اسم المستلم 3-DS2 الدفع إلى البنك الذي تتعامل معه.

زيادة فرص الدفع الناجح: التكامل الصحيح = عدد أقل من الإخفاقات التقنية.

للعمل

الامتثال والعقوبات الأقل: يقلل امتثال PCI DSS من التزامات مراجعة الحسابات والتكلفة.

ناقص استرداد التكاليف: ينقل 3-DS2 المسؤولية إلى المُصدر في النزاع.

المزيد من التحويل: SCA السريعة، Apple/Google Pay، حفظت الرموز لنقرة واحدة.

حماية العلامة التجارية: لا يوجد «اختطاف» (تضمين نصوص ضارة) والتسريبات.

كيف يجب أن يبدو التكامل المناسب

1. أعد التوجيه إلى PSP أو مجال الحقول المستضافة/iFrame داخل صفحة التاجر.

2. حقول البطاقات (PAN/CVC/انتهاء الصلاحية) تنتمي تقنيًا إلى المزود - يتلقى التاجر رمزًا.

3. يبدأ SCA/3-DS 2 تلقائيًا: ادفع إلى التطبيق المصرفي، القياسات الحيوية، رمز الرسائل القصيرة.

4. حماية مستوى الصفحة: HSTS، سياسة أمان المحتوى (CSP)، X-Frame-Options، تجزئة غير نصية/نصية.

5. UX الخالص: خط/تخطيط واحد أو أداة PSP خاصة، الوصف الصحيح للتاجر.

لماذا الأشكال غير الأصلية خطيرة

Formjacking (Magecart): إزالة JS الخبيثة PAN/CVC أثناء الطيران.

استبدال التصيد/المجال: عناوين URL مماثلة، شعارات مزيفة، «قفل» في حد ذاته لا يضمن أي شيء.

عدم امتثال PCI: الغرامات، التدقيق الإلزامي، الحصول على الحظر.

الإعفاءات والاحتجازات: قطع المصدرون الاندماجات الرمادية، والمزيد لا تحترم.

تسريبات شركة KYC: طلب «بطاقة مصورة من كلا الجانبين» وجواز سفر بالبريد الإلكتروني يعد انتهاكًا جسيمًا.

خصائص النموذج الأصلي (للمستخدم)

تقع حقول الخرائط في iFrame المدمج (المؤشر والإطار «داخل» نافذة صغيرة) أو تصل إلى مجال PSP/بنك معروف.

شريط العنوان: HTTPS، شهادة صالحة، المجال الصحيح بدون أخطاء مطبعية.

تظهر 3-D Secure/SCA تلقائيًا (الدفع/الرسائل القصيرة/القياسات الحيوية من البنك الذي تتعامل معه).

لا توجد طلبات لإرسال بطاقات PAN/CVC/للدردشة/البريد.

سياسة الخصوصية وشروط الدفع مفتوحة ويمكن قراءتها.

الأعلام الحمراء (توقف على الفور)

حقول الخرائط مباشرة على موقع التاجر بدون iFrame/الحقول المستضافة.

اطلب PAN/CVC عن طريق البريد الإلكتروني/messenger أو «بطاقة الصورة على كلا الجانبين».

المجال غريب: "الدفع آمن. التحقق من العلامة التجارية للمتجر. نت "بدلاً من العلامة التجارية/مجال PSP.

تسحب الصفحة الموارد غير السرية (http) عند خطوة الدفع أو «تقسم» الشهادة.

توطين مكسور، شعارات بكسل، أخطاء إملائية، مؤقتات «ادفع 2:59».

قائمة مرجعية للمستخدم (دقيقة 1)

يتم الدفع من خلال إعادة التوجيه إلى PSP أو iFrame/Hosted Fields.
شهادة HTTPS/صالحة، نطاق لا بدائل.
عمل SCA/3-DS2 (الدفع/الرسائل القصيرة/القياسات الحيوية).
لا أرسل بطاقات PAN/CVC/الصور إلى الدردشة/البريد.
حافظ على سياسة الخصوصية والاتصالات الخاصة بك.

قائمة مرجعية للأعمال التجارية (التكامل/الأمن)

استخدام الحقول المستضافة/iFrame أو إعادة توجيه PSP ؛ تاجر لا يرى PAN/CVC.
PCI DSS: SAQ A/SAQ A-EP حسب نوع التكامل، الترميز، تجزئة الشبكة.
تمكين CSP/HSTS/XFO ؛ النصوص الخارجية - عن طريق قائمة السماح مع التجزئة/عدم التجزئة.
3-DS 2/SCA ؛ الاحتياطي на OTP/الدفع ؛ دعم المحافظ (Apple/Google Pay).
رصد التغييرات الأمامية (SRI، canary scripts)، الحماية من الاختطاف.
نصوص واضحة: من هو المستحوذ/PSP، كيف تتم معالجة البيانات، تواريخ الإرجاع.
اختبارات الاختراق المنتظمة ومراقبة التبعية (SCA - تحليل تكوين البرمجيات).

المشاكل الشائعة وكيفية حلها بسرعة

أعراض	سبب	قرار
الكثير من «رفض/لا تكرم»	دمج غير صحيح، نقص 3-DS2	تمكين 3-DS2 والتحقق من صحة قواعد BIN والوصف و MCC
العملاء يشتكون من «الضفادع»	اختطاف/برامج ضارة في الجبهة	تمكين CSP/SRI، وترجمة الحقول إلى الحقول المستضافة والتدرج والتناوب الرئيسي
يطلب بطاقة صور بالبريد الإلكتروني	عملية دعم غير صحيحة	الحظر الفوري ؛ فقط من خلال مزود آمن لشركة KYC، بدون PAN/CVC
كثيرًا ما يطلب البنك من SCA	إشارات المخاطر/الأجهزة الجديدة	قم بإعداد التنسيق، وحفظ الرموز/الأجهزة، وتحسين التسجيل السلوكي

الأسئلة الشائعة (قصيرة)

قفل شريط العنوان = آمن ؟

لا ، ليس كذلك هذا مجرد تشفير انظر إلى المجال والشكل المستضاف 3-DS2 والسياسة.

لماذا iFrame أفضل من الحقول الموجودة في الموقع ؟

نظرًا لأن PAN/CVC تذهب مباشرة إلى PSP ولا تلمس واجهة التاجر - فهناك مخاطر ومتطلبات PCI أقل.

هل يمكنني أخذ تفاصيل البطاقة عبر الهاتف/الدردشة ؟

لا ، ليس كذلك هذا انتهاك جسيم لـ PCI. استخدم رابط الدفع/الفاتورة مع النموذج المضيف.

إذا كان النموذج «معلق» بدون SCA ؟

إعادة التشغيل، تحقق من الشبكة/المتصفح. تأكد من عدم منع PSP المنبثقة/النصوص.

سياسة مصغرة للشركة (إطار جاهز)

1. الحقول المستضافة فقط/إعادة توجيه PAN/CVC.

2. 3-DS 2/SCA إلزامي للبطاقات ؛ متصل بواسطة Apple/Google Pay.

3. CSP/HSTS/XFO/SRI + نطاقات قائمة السماح الصارمة.

4. مراقبة المقدمة والتنبيهات لاستبدال النص.

5. مراجعة حسابات SAQ/PCI سنويًا ؛ في الموعد المحدد.

6. لا يطلب الدعم أبدًا بطاقة PAN/CVC/photo card ؛ فقط قنوات KYC المحمية.

نموذج الدفع الأصلي ليس جماليات، بل أمن وشرعية. تقوم الحقول المستضافة والترميز و SCA بحماية حامل البطاقة وزيادة التحويل وإزالة جزء كبير من المخاطر من العمل. المستخدم - اختر المجال والنموذج و SCA ؛ - استخدام عمليات التكامل المعتمدة فقط مع الدفاعات الأمامية الصلبة. باتباع هذه القواعد، تغلق 90٪ من سيناريوهات تسرب البيانات وفشل الدفع.