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

كل معاملة تجارة إلكترونية تتضمن بطاقة دفع تنشئ التزامًا بالامتثال بموجب PCI DSS - معيار أمان بيانات صناعة بطاقات الدفع. إن عدم الامتثال لا يشكل خطراً نظرياً: فالعلامات التجارية للبطاقات (Visa، وMastercard، وAmex) يمكنها فرض غرامات تتراوح بين 5000 إلى 100000 دولار شهرياً على البنوك المستحوذة، التي تنقل المسؤولية مباشرة إلى التجار من خلال اتفاقيات معالجة الدفع الخاصة بهم. بعد حدوث الانتهاك، يواجه التجار غير الممتثلين غرامات تتراوح بين 50 إلى 90 دولارًا لكل بطاقة تم اختراقها، وتكاليف التحقيق الجنائي في العلامة التجارية للبطاقة، و- في الحالات الأكثر خطورة - إنهاء حساب التاجر الخاص بهم.

أدخل الإصدار 4.0 من PCI DSS، الذي تم إصداره في مارس 2022 مع الامتثال الإلزامي اعتبارًا من مارس 2025، تغييرات مهمة على متطلبات التشفير ومعايير المصادقة والتعامل مع البرامج النصية على صفحات الدفع. يمنح هذا الدليل فرق التجارة الإلكترونية خريطة طريق كاملة للتنفيذ.

الوجبات الرئيسية

• أصبح الإصدار 4.0 من PCI DSS إلزاميًا اعتبارًا من 31 مارس 2025 — ويجب أن يكون جميع تجار التجارة الإلكترونية متوافقين مع الإصدار الجديد
• يعد تحديد النطاق الخطوة الأولى الأكثر أهمية: قم بتقليل بيئة بيانات حامل البطاقة (CDE) قدر الإمكان
• يؤدي استخدام صفحة الدفع المستضافة لمعالج الدفع (Stripe وBraintree وAdyen) إلى تقليل النطاق بشكل كبير
• ينطبق SAQ A على معظم تجار صفحات الدفع المستضافة - ولكن فقط إذا لم تمس بيانات حامل البطاقة خوادمك
• تتضمن متطلبات الإصدار 4.0 الجديدة MFA لجميع عمليات الوصول إلى CDE، وضوابط سلامة البرنامج النصي على صفحات الدفع، وتحليل المخاطر المستهدفة
• تمت معالجة عملية القشط على الويب (هجمات Magecart) من خلال المتطلب الجديد 6.4.3 المتعلق بمخزون البرنامج النصي لصفحة الدفع
• تظل اختبارات الاختراق السنوية وعمليات فحص الثغرات الربع سنوية إلزامية
• يتم فرض عقوبات عدم الامتثال من العلامات التجارية للبطاقات ← البنوك المستفيدة ← التجار

---

أساسيات إطار عمل PCI DSS

تتم صيانة PCI DSS من قبل مجلس معايير أمان صناعة بطاقات الدفع (PCI SSC)، وهي هيئة أسستها American Express وDiscover وJCB وMastercard وVisa. المعيار الحالي هو PCI DSS v4.0.

يتم تنظيم المعيار في 12 متطلبًا عبر 6 أهداف:

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

---

الخطوة الأولى — تحديد نطاقك وتقليله

بيئة بيانات حامل البطاقة (CDE) هي أي نظام يقوم بتخزين أو معالجة أو نقل بيانات حامل البطاقة (CHD) أو بيانات المصادقة الحساسة (SAD). إن تقليل النطاق هو الخطوة الأكثر تأثيرًا التي يمكنك اتخاذها.

بيانات حامل البطاقة مقابل بيانات المصادقة الحساسة:

استراتيجيات تقليل النطاق للتجارة الإلكترونية:

1. استخدم صفحة دفع مستضافة: قم بإعادة توجيه العملاء إلى صفحة الدفع المستضافة لمعالج الدفع الخاص بك (Stripe Checkout، Braintree Hosted Fields، Adyen Drop-in). لا توجد بيانات خاصة بحامل البطاقة تمس خوادمك، وأنت مؤهل للحصول على SAQ A - وهو أبسط استبيان للتقييم الذاتي.

2. الترميز: استبدل أرقام البطاقات بالرموز المميزة التي ينشئها المعالج مباشرة بعد التفويض. قم بتخزين الرمز المميز فقط، وهو أمر غير مفيد للمهاجمين دون الوصول إلى مخزن الترميز الخاص بالمعالج.

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

4. تجزئة الشبكة: عزل أنظمة CDE (خوادم معالجة الدفع وقواعد البيانات) عن الأنظمة خارج النطاق باستخدام جدران الحماية. تعمل الشبكات المجزأة بشكل صحيح على تقليل نطاق التدقيق بشكل كبير.

---

الخطوة الثانية — تحديد نوع SAQ الخاص بك

يعد استبيان التقييم الذاتي (SAQ) أداة للتحقق للتجار ومقدمي الخدمات الذين لا يحتاجون إلى تقييم أمني مؤهل (QSA) في الموقع. يتم تحديد نوع SAQ حسب كيفية قبولك للمدفوعات:

SAQ A — ينطبق على التجار الذين لا يملكون بطاقة (التجارة الإلكترونية) والذين يستعينون بمصادر خارجية بالكامل لمعالجة الدفع إلى جهة خارجية متوافقة مع PCI DSS. لا يتم تخزين أو معالجة أو نقل أي بيانات خاصة بحامل البطاقة الإلكترونية على أنظمتك أو مقرك. يتم تسليم صفحة الدفع الخاصة بك بالكامل بواسطة معالج الدفع الخاص بك. حوالي 22 متطلبات.

SAQ A-EP — لتجار التجارة الإلكترونية الذين يستعينون جزئيًا بمصادر خارجية لمعالجة الدفع ولكن لا يزال لديهم صفحة دفع مستضافة على خادمهم الخاص، والتي تتضمن إطار iframe للدفع من جهة خارجية. يؤثر خادم الويب الخاص بك بشكل غير مباشر على أمان معالجة الدفع. متطلبات أكثر من SAQ A. تأثرت بشدة بمتطلبات الإصدار 4.0 الجديد 6.4.3.

SAQ D — للتجار الذين لا يستوفون معايير أي نوع SAQ آخر، أو الذين يقومون بتخزين بيانات حامل البطاقة. يغطي جميع المتطلبات الـ 12. مطلوبة للتجار الذين يقومون بتشغيل البنية التحتية لمعالجة الدفع الخاصة بهم. عادةً ما يزيد عن 300+ من المتطلبات الفرعية.

مستويات المستوى (معيار Mastercard/Visa):

---

الخطوة 3 - التغييرات الرئيسية في PCI DSS v4.0 للتجارة الإلكترونية

قدم PCI DSS v4.0 العديد من المتطلبات التي تؤثر بشكل خاص على تجار التجارة الإلكترونية. أصبحت جميعها إلزامية اعتبارًا من 31 مارس 2025.

المتطلب 6.4.3 — إدارة البرنامج النصي لصفحة الدفع

يستهدف هذا المتطلب بشكل مباشر هجمات Magecart/التصفح عبر الويب - حيث يقوم المهاجمون بحقن JavaScript ضار في صفحات الدفع الخاصة بالتجارة الإلكترونية لسرقة بيانات حامل البطاقة في الوقت الفعلي. بموجب 6.4.3، يجب على التجار الذين يستخدمون SAQ A-EP أو أعلى:

-الاحتفاظ بجرد لجميع البرامج النصية المصرح لها بالتنفيذ على صفحات الدفع

• تبرير الضرورة التجارية أو التقنية لكل نص
• تنفيذ طريقة للتأكد من سلامة كل برنامج نصي (تجزئات تكامل المصدر الفرعي للبرامج النصية التابعة لجهات خارجية، أو توجيهات سياسة أمان المحتوى)

بالنسبة لتجار SAQ A الذين لديهم صفحة دفع خارجية بالكامل، ينطبق هذا المطلب على صفحات معالج الدفع الخاص بك — ويجب عليهم إثبات الامتثال نيابة عنك.

المتطلب 11.6.1 — اكتشاف التغيير والتلاعب بصفحات الدفع

يجب على التجار نشر آلية (على سبيل المثال، سياسة أمان المحتوى، خدمة مراقبة البرنامج النصي) لاكتشاف التعديلات غير المصرح بها على رؤوس HTTP ومحتويات البرنامج النصي على صفحات الدفع. يجب إنشاء التنبيهات خلال 7 أيام من حدوث أي تغييرات غير معتمدة.

** المتطلب 8.4.2 — MFA لجميع عمليات الوصول إلى CDE **

المصادقة متعددة العوامل مطلوبة الآن لجميع حسابات المستخدمين الذين لديهم حق الوصول إلى CDE - وليس فقط الوصول عن بعد. يتضمن ذلك وصول المستخدمين الداخليين إلى أنظمة دفع الإنتاج من داخل شبكة الشركة.

** المتطلب 3.3.1.1 — لا يمكن الاحتفاظ بـ SAD بعد الترخيص **

يحظر بشكل صريح تخزين بيانات المصادقة الحساسة (بيانات المسار الكامل، CVV، PIN) بعد الترخيص. لقد كان هذا محظورًا دائمًا ولكن تمت صياغته الآن بشكل أكثر دقة لسد الثغرات في كيفية تسجيل بعض الأنظمة لـ SAD في مخرجات التصحيح/التشخيص.

تحليل المخاطر المستهدفة (TRA)

يقدم الإصدار 4.0 مفهوم تحليل المخاطر المستهدفة - يمكن للتجار إظهار أساليب بديلة لبعض المتطلبات إذا قاموا بإجراء تحليل مخاطر موثق يوضح الحماية المكافئة. وهذا يوفر المرونة لبيئات أكبر وأكثر تعقيدًا.

---

الخطوة 4 – هندسة أمن الشبكات

بالنسبة للتجار الذين لديهم أنظمة في نطاق يتجاوز SAQ A، يعد أمان الشبكة مجالًا أساسيًا للامتثال.

المتطلب 1 — تثبيت وصيانة عناصر التحكم في أمان الشبكة:

• تنفيذ جدار حماية بين الشبكات غير الموثوقة (الإنترنت) وCDE
• تنفيذ جدار حماية بين CDE والشبكات الداخلية الأخرى (التجزئة)
• توثيق جميع قواعد جدار الحماية مع مبررات العمل
• مراجعة قواعد جدار الحماية كل 6 أشهر على الأقل
• رفض كل حركة المرور غير المطلوبة بشكل صريح (وضعية الرفض الافتراضية)
• بالنسبة للتجارة الإلكترونية: قم بتطبيق WAF (جدار حماية تطبيقات الويب) أمام خوادم الويب

اختبار تجزئة الشبكة:

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

بنية DMZ للتجارة الإلكترونية:

Internet → WAF/Load Balancer → DMZ (Web Servers) → Internal Firewall → CDE (Payment Servers, DB) → Internal Network

تخدم خوادم الويب في المنطقة المجردة من السلاح واجهة متجرك. فقط حركة المرور المحددة والموثقة (HTTPS إلى واجهة برمجة تطبيقات الدفع، وSQL على منفذ معين إلى قاعدة بيانات محددة) تعبر من DMZ إلى CDE. تم حظر كافة حركة المرور الأخرى.

---

الخطوة 5 - متطلبات أمان التطبيق

المتطلب 6 — تطوير وصيانة الأنظمة والبرامج الآمنة:

• الاحتفاظ بجرد لجميع البرامج المخصصة وبرامج الطرف الثالث في النطاق
• معالجة نقاط الضعف كجزء من عملية إدارة الثغرات الرسمية
• حماية التطبيقات التي تواجه الويب من الهجمات المعروفة (OWASP Top 10)
• إجراء مراجعات لرمز الأمان أو اختبارات اختراق التطبيق قبل نشر التغييرات المهمة في الإنتاج
• استخدم فقط البرامج المقدمة من البائعين ذوي السمعة الطيبة والذين لديهم عمليات تصحيح أمان ملتزمة

جدار حماية تطبيقات الويب (WAF) — المتطلب 6.3.2 و6.4.2:

يعد WAF إلزاميًا لجميع تطبيقات الويب العامة، وتم تكوينه إما لمنع الهجمات أو إنشاء تنبيهات ومراجعتها خلال ساعة واحدة. بالنسبة للتجارة الإلكترونية، يجب أن يغطي WAF ما يلي:

• منع حقن SQL
• حماية البرمجة النصية عبر المواقع (XSS).
• الحماية من تزوير الطلبات عبر المواقع (CSRF).
• الكشف عن الروبوتات الضارة
• تحديد معدل لمنع القوة الغاشمة

إدارة برامج التبعية والجهات الخارجية:

تعتمد منصات التجارة الإلكترونية (تخصيصات WooCommerce وMagento وShopify) بشكل كبير على المكونات الإضافية والإضافات. يجب تقييم كل مكون إضافي في النطاق من حيث الأمان. احتفظ بمخزون وقم بتطبيق التصحيحات ضمن اتفاقية مستوى الخدمة الخاصة بالتصحيح (حاسمة: 7 أيام من إصدار تصحيح البائع).

---

الخطوة 6 - التحكم في الوصول والمصادقة

المطلب 7 — تقييد الوصول إلى مكونات النظام وبيانات حامل البطاقة:

• تنفيذ التحكم في الوصول على أساس الدور على أساس أقل الامتيازات
• الوصول الافتراضي إلى "رفض الكل" مع توثيق المنح الصريحة
• مراجعة حقوق وصول المستخدم على الأقل كل 6 أشهر

المتطلب 8 — تحديد المستخدمين ومصادقة الوصول:

• قم بتعيين معرف فريد لكل شخص لديه حق الوصول إلى CDE
• الحد الأدنى لكلمات المرور هو 12 حرفًا (الإصدار 4.0 يزيد من 7 في الإصدار 3.2.1)، ومتطلبات التعقيد
• قفل الحسابات بعد 10 محاولات غير صالحة كحد أقصى (الإصدار 4.0 الافتراضي، أو حسب هيئة تنظيم الاتصالات)
• مهلة الجلسة بعد 15 دقيقة كحد أقصى من عدم النشاط لجلسات CDE
• MFA مطلوب لجميع عمليات الوصول إلى CDE (توسيع الإصدار 4.0 من جهاز التحكم عن بُعد فقط)
• يجب إدارة حسابات الخدمة وحسابات النظام بشكل منفصل عن حسابات المستخدمين

---

الخطوة 7 – إدارة الثغرات الأمنية واختبارها

المتطلب 11 — اختبار أمان الأنظمة والشبكات:

فحص الثغرات الداخلية ربع السنوية: فحص جميع الأنظمة الموجودة في النطاق. قم بمعالجة جميع نقاط الضعف الحرجة وعالية الخطورة قبل الفحص التالي. يمكن إجراء عمليات المسح من قبل الموظفين الداخليين باستخدام الأدوات المعتمدة (Nessus، Qualys، OpenVAS).

عمليات فحص الثغرات الخارجية ربع السنوية بواسطة بائع فحص معتمد (ASV): يجب إجراء عمليات الفحص الخارجية لجميع الأنظمة التي يمكن الوصول إليها خارجيًا بواسطة ASV معتمد من PCI SSC. يجب أن يجتاز الفحص (لا توجد ثغرات أمنية عالية/حرجة مفتوحة) قبل أن تتمكن من إثبات الامتثال.

اختبار الاختراق السنوي: يتم إجراؤه بواسطة مورد داخلي مؤهل أو شركة خارجية ذات سمعة طيبة. يجب أن تغطي:

• جميع الأنظمة والشبكات الموجودة في النطاق
• ضوابط التجزئة (التحقق من عزل CDE بشكل صحيح)
• OWASP Top 10 لتطبيقات مواجهة الويب
• الهندسة الاجتماعية (للبيئات عالية المخاطر)

معالجة جميع نتائج اختبار الاختراق وإجراء اختبار التحقق لتأكيد العلاج.

** مراقبة سلامة الملفات (FIM) **: انشر FIM على كافة ملفات النظام الهامة وملفات التكوين وملفات المحتوى. تنبيه خلال ساعة واحدة (الإصدار 4.0) من أي تغييرات غير مصرح بها.

---

قائمة التحقق من الامتثال لـ PCI DSS للتجارة الإلكترونية

• تحديد نطاق معالجة الدفع وتقليله (يتم استخدام صفحة الدفع المستضافة أو الترميز حيثما أمكن ذلك)
• تم تحديد نوع SAQ بناءً على طريقة قبول الدفع
• تم تنفيذ وتوثيق تجزئة الشبكة
• اكتمل جرد بيانات حامل البطاقة - لم يتم تخزين SAD في أي مكان
• تخزين جميع بيانات حامل البطاقة مشفر (AES-256 أو ما يعادله)
• تطبيق TLS 1.2+ لجميع عمليات نقل بيانات الدفع
• توثيق مخزون البرنامج النصي لصفحة الدفع (المتطلب 6.4.3)
• نشر اكتشاف التغيير/التلاعب في صفحات الدفع (المتطلب 11.6.1)
• يتم نشر WAF أمام جميع تطبيقات الويب العامة
• فرض MFA لجميع عمليات الوصول إلى CDE (المتطلبات 8.4.2)
• معرفات المستخدم الفريدة، وكلمات المرور القوية، وتم تكوين قفل الحساب
• تم الانتهاء من عمليات فحص الثغرات الربع سنوية (داخلي + ASV خارجي).
• تم الانتهاء من اختبار الاختراق السنوي، وتم معالجة النتائج
• مراقبة سلامة الملفات المنتشرة على أنظمة CDE
• تمت مراجعة قواعد جدار الحماية خلال آخر 6 أشهر
• تم الانتهاء من التدريب على الوعي الأمني لجميع موظفي CDE
• خطة الاستجابة للحوادث تغطي سيناريوهات اختراق بطاقة الدفع
• تم التحقق من امتثال البائع/موفر الخدمة لـ PCI DSS

---

الأسئلة المتداولة

نحن نستخدم Shopify لمتجرنا - هل ما زلنا بحاجة إلى الامتثال لـ PCI DSS؟

Shopify هو مزود خدمة معتمد من PCI DSS من المستوى 1. إذا كنت تستخدم معالجة الدفع القياسية في Shopify (Shopify Payments أو الدفع المستضاف على Shopify)، فسيتم تقليل نطاق الامتثال الخاص بك بشكل كبير. لا يزال لديك التزامات - في المقام الأول SAQ A - تغطي استخدامك لخدمات Shopify. إذا أضفت JavaScript مخصصًا إلى صفحة الدفع الخاصة بك على Shopify أو استخدمت تطبيقات دفع تابعة لجهات خارجية تعالج بيانات البطاقة خارج بيئة Shopify، فسيتم توسيع النطاق.

ما الفرق بين توافق PCI DSS وشهادة PCI DSS؟

لا توجد "شهادة PCI DSS" رسمية للتجار. يشهد التجار على الامتثال من خلال استبيانات التقييم الذاتي أو (تجار المستوى الأول) من خلال تقرير الامتثال (RoC) الذي تجريه وكالة ضمان الجودة. يمكن إدراج مقدمي الخدمات في السجل العالمي لمقدمي الخدمات التابع لشركة Visa. غالبًا ما يتم استخدام المصطلحين "معتمد" و"متوافق" بالتبادل في اتصالات السوق، ولكن التجار من الناحية الفنية يشهدون بأنفسهم أو يحصلون على امتثال مصدق من QSA.

ما هي العقوبات التي يواجهها التجار في حالة عدم الامتثال؟

العقوبات ليست مباشرة من PCI SSC - فهي تتدفق من العلامات التجارية للبطاقات من خلال البنوك المستحوذة. تتراوح الغرامات الشهرية عادةً بين 5000 و100000 دولار اعتمادًا على مستوى التاجر ومدة عدم الامتثال. بعد حدوث الانتهاك، قد تفرض العلامات التجارية للبطاقات غرامات على كل بطاقة (50 إلى 90 دولارًا لكل بطاقة فيزا، على غرار ماستركارد)، وتكاليف التحقيق الجنائي (20000 إلى 200000 دولار +)، وتكاليف إعادة إصدار البطاقة الإلزامية. وفي الحالات الشديدة، يفقد التجار قدرتهم على قبول مدفوعات البطاقة بالكامل. يواجه المخالفون المتكررون أو التجار الذين لديهم تأثيرات خرق كبيرة أعلى العقوبات.

ما هو هجوم Magecart وكيف يتعامل معه PCI DSS v4.0؟

يشير Magecart إلى الهجمات التي يتم فيها حقن JavaScript ضار في صفحات الخروج الخاصة بالتجارة الإلكترونية لاعتراض بيانات حامل البطاقة في الوقت الفعلي أثناء قيام العملاء بكتابتها. تستغل هذه الهجمات نصوص الطرف الثالث (التحليلات، وأدوات الدردشة، ومديري العلامات) التي يدرجها التجار في صفحات الدفع. تعالج متطلبات PCI DSS v4.0 6.4.3 و11.6.1 هذا الأمر بشكل مباشر: يجب على التجار جرد جميع النصوص البرمجية الموجودة على صفحات الدفع والتحقق من سلامتها، ونشر المراقبة للكشف عن التغييرات غير المصرح بها في رمز صفحة الدفع.

كيف نتعامل مع PCI DSS لبنية التجارة الإلكترونية بدون رأس؟

تفصل التجارة الإلكترونية بدون رأس طبقة عرض الواجهة الأمامية عن محرك التجارة الخلفي. لأغراض PCI DSS، ما يهم هو أين تتدفق بيانات حامل البطاقة. إذا كانت الواجهة الأمامية بدون رأس لديك تستخدم Stripe Elements أو حلًا مشابهًا يستند إلى iFrame، فستنتقل بيانات البطاقة مباشرةً من المتصفح إلى معالج الدفع دون لمس خوادم الواجهة الأمامية - وهذه هي منطقة SAQ A. إذا كانت البنية بدون رأس الخاصة بك تتضمن معالجة دفع مخصصة من جانب الخادم، فسيتوسع النطاق بشكل كبير ويجب عليك إشراك QSA للحصول على إرشادات تحديد النطاق.

هل نحتاج إلى QSA لتقييم PCI DSS الخاص بنا؟

يُطلب من التجار من المستوى الأول فقط (أكثر من 6 ملايين معاملة سنويًا لـ Visa/Mastercard) إشراك QSA لإعداد تقرير سنوي حول الامتثال (RoC). يمكن للتجار من المستوى 2 إلى 4 التصديق الذاتي عبر SAQ. ومع ذلك، فإن العديد من التجار يستعينون طوعًا بوكالة ضمان الجودة (QSA) أو شركة تقييم الأمان المؤهل (QSAC) للحصول على التوجيه حتى عندما لا تكون هناك حاجة لذلك، لا سيما عندما لا يكونون متأكدين من نطاقهم أو لديهم بنية تحتية معقدة.

---

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

يحمي الامتثال لـ PCI DSS بيانات الدفع الخاصة بعملائك، ويحد من تعرضك للمسؤولية، وهو شرط أساسي للحفاظ على قبول البطاقة. بالنسبة لشركات التجارة الإلكترونية على Shopify أو المنصات المخصصة، فإن الخطوة الأولى دائمًا هي تقليل النطاق - فالوصول إلى SAQ A من خلال الاستخدام السليم لصفحات الدفع المستضافة هو المسار الأسرع والأكثر فعالية من حيث التكلفة.

يتمتع فريق تنفيذ التجارة الإلكترونية في ECOSIRE بخبرة واسعة في بناء متاجر Shopify المتوافقة مع PCI DSS ومنصات التجارة المخصصة، مع بنية دفع مصممة من الألف إلى الياء لتقليل نطاق CDE.

البدء: خدمات ECOSIRE Shopify

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