عندما يختار العميل حفظ بطاقته للشراء لاحقًا، لا يلزم أن يحتفظ المتجر برقم البطاقة داخل قاعدة بياناته، إذ يمكن أن يحتفظ بمعرّف بديل يستخدمه ضمن تكامله مع مزود الدفع، وهنا تظهر قيمة ترميز المدفوعات في تقليل انتشار البيانات الحساسة مع الإبقاء على إمكانية تنفيذ العمليات التي يحتاجها العمل.
لكن وجود رمز في سجل الطلب لا يجيب عن جميع الأسئلة الأمنية، فقد تمر بيانات البطاقة قبل ترميزها بخادم المتجر أو تتسرب إلى سجل تقني، وقد تكون صلاحيات استخدام الرمز أوسع مما يتوقع الفريق، لذلك يبدأ تقييم الحل من مسار البيانات وحدود الصلاحيات، ثم يُنظر إلى أثره الفعلي على المخاطر ونطاق متطلبات PCI DSS.
ما ترميز المدفوعات، وماذا يستبدل تحديدًا؟
رقم الحساب الأساسي للبطاقة، المعروف اختصارًا بـPAN، هو القيمة التي يستهدف الترميز استبدالها، ففي نموذج شائع يتولى مزود الدفع الاحتفاظ بالعلاقة بين الرقم ورمز بديل، بينما يتعامل المتجر مع هذا الرمز وفق العمليات التي يسمح بها المزود، مثل حفظ وسيلة الدفع أو تنفيذ دفعات لاحقة.
الرمز ليس مجرد إخفاء لبعض أرقام البطاقة على الشاشة، فإظهار آخر أربعة أرقام يساعد المستخدم على تمييز بطاقته، لكنه لا يثبت أن الأنظمة الخلفية توقفت عن تخزين الرقم كاملًا، والمراجعة الصحيحة تسأل عما يُجمع ويُنقل ويُحفظ بالفعل، لا عما يظهر في واجهة المستخدم فقط.
كيف تسير العملية في تكامل يستضيفه مزود الدفع؟
في المثال التالي تستقبل واجهة مزود الدفع بيانات البطاقة مباشرة، ويستلم المتجر معرّفًا بديلًا ونتيجة العملية، وهذا وصف مبسط لأحد نماذج التكامل وليس حكمًا على كل إضافة أو بوابة تحمل اسم الترميز.
يدخل العميل بيانات البطاقة في صفحة أو حقول مخصصة يقدمها مزود الدفع وفق تعليماته.
تنتقل البيانات إلى بيئة المزود لمعالجتها وإنشاء القيمة البديلة المستخدمة في التكامل.
يستقبل المتجر معرّف وسيلة الدفع أو العملية والنتيجة اللازمة لتحديث الطلب.
يربط المتجر المعرّف بسجل العميل أو الطلب عند الحاجة ووفق آلية الحفظ المعتمدة.
تُنفذ العمليات اللاحقة من خلال واجهات المزود، دون الحاجة إلى إعادة إدخال الرقم في أنظمة المتجر.
النقطة الحاسمة هي الخطوة الأولى، فإذا كان نموذج المتجر يستقبل الرقم ثم يرسله من خادمه إلى جهة أخرى كي ترمّزه، فقد تعامل الخادم مع البيانات الحساسة بالفعل، أما تجنب وصولها إليه منذ البداية فيحتاج إلى تصميم مختلف وتحقق من طريقة عمل التكامل.
الفرق بين الترميز والتشفير وإخفاء الأرقام
يحوّل التشفير البيانات إلى صيغة لا تُقرأ دون آلية فك التشفير والمفتاح المناسب، بينما يوفر الترميز قيمة بديلة تُستخدم وفق تصميم خدمة الترميز، وقد تعتمد بعض الحلول على أساليب تشفير داخليًا، لذلك لا يصح افتراض أن كل رمز عشوائي أو أن جميع الرموز لها الخصائص الأمنية نفسها.
أما إخفاء الأرقام في الواجهة فهو إجراء يتعلق بطريقة عرض البيانات، ويمكن أن تعمل هذه الإجراءات معًا ضمن النظام نفسه، لكن إثبات وجود أحدها لا يغني عن معرفة أين يوجد رقم البطاقة الأصلي ومن يستطيع الوصول إليه، ولا يحول تلقائيًا الأنظمة المتصلة إلى أنظمة خارج نطاق PCI DSS.
ليست جميع الرموز من النوع نفسه
يميز مجلس PCI بين رموز تنشأ ضمن خدمات التاجر أو الجهة المستحوذة، ورموز تصدرها جهات إصدار البطاقات، ورموز دفع تتبع إطار EMV، وقد يكون المعرّف الذي يحتفظ به المتجر خاصًا بمزود معين، ولذلك ينبغي معرفة إمكان نقله أو استخدامه عند تغيير مزود الخدمة بدل افتراض أنه يعمل في أي بيئة.
توضح EMVCo أن رمز الدفع وفق إطارها يمكن تقييد استخدامه بتاجر أو جهاز أو سيناريو دفع محدد، وتقلل هذه القيود من قيمة البيانات المسروقة خارج سياقها المسموح، لكن وجود كلمة Token في واجهة برمجية لا يثبت وحده أن القيمة رمز دفع متوافق مع EMV أو أنها محمية بقيود الاستخدام نفسها.
أين تظهر الفائدة في العمليات اليومية؟
الشراء المتكرر وحفظ وسيلة الدفع
يمكن ربط حساب العميل بمعرّف وسيلة دفع لدى المزود، بحيث يختارها في عملية لاحقة دون أن يحفظ المتجر رقمها الأصلي، وتبقى مراجعة صلاحية الوصول إلى هذا الحساب مهمة، لأن حماية بيانات البطاقة لا تحل وحدها مشكلة الاستيلاء على حساب العميل أو إساءة استخدام وظائف المتجر.
الاشتراكات والدفعات الدورية
يساعد الترميز على تنفيذ الدفع المتكرر من خلال وسيلة الدفع المحفوظة لدى المزود، ويؤكد مجلس PCI أن رمز التحقق مثل CVV أو CVC لا يُحتفظ به بعد اعتماد العملية، حتى لو كان مشفرًا أو وافق العميل على تخزينه، كما أن الدفعات الدورية ليست مبررًا للاحتفاظ بهذا الرمز.
الاسترجاع وخدمة العملاء
في مثال موثق من Stripe، يُنشأ طلب الاسترجاع بالرجوع إلى معرّف الدفعة أو العملية الأصلية، ويمكن أن يكون كاملًا أو جزئيًا ضمن المبلغ المتاح للاسترجاع، وهذا يوضح أن إجراء الاسترجاع لا يستلزم مطالبة العميل بإرسال صورة بطاقته أو رقمها الكامل إلى موظف الدعم، مع اختلاف تفاصيل التنفيذ بين المزودين.
ما علاقة الترميز بنطاق PCI DSS؟
نطاق التقييم يحدد الأنظمة والأشخاص والإجراءات التي تنطبق عليها متطلبات حماية بيانات الدفع، ويذكر مجلس PCI أن رموز الدفع المتوافقة مع إطار EMV، والموجودة خارج بيئة بيانات الرموز لدى مزودها، لا تعد بيانات حساب ضمن الشروط التي يوضحها، بينما تبقى الأنظمة التي تخزن بيانات الحساب أو تعالجها أو تنقلها، والأنظمة المتصلة بها وفق الحالة، خاضعة للمتطلبات ذات الصلة.
لذلك قد يسهم التكامل المناسب في تقليل نطاق التقييم، لكن اسم المنتج أو وجود شهادة لدى مزود الخدمة لا يكفيان للحكم على بيئة المتجر، إذ يجب ربط الاستنتاج بطريقة التنفيذ الفعلية وتدفقات البيانات، ثم مراجعة نموذج التقييم المطلوب مع الجهة التي تقبل إثبات الامتثال، مثل البنك المستحوذ أو جهة الدفع المعنية.
وفي توضيح خاص بشروط أهلية SAQ A، يفرق مجلس PCI بين نموذج دفع مضمّن داخل صفحة المتجر، مثل iframe، وبين إعادة توجيه العميل إلى صفحة المزود، فشرط التحقق من عدم التعرض لهجمات السكربتات الوارد في ذلك التوضيح يخص الحالة المضمّنة، ولا تعني هذه التفرقة أن إعادة التوجيه تلغي بقية شروط الأهلية أو مسؤوليات المتجر الأمنية.
ما المخاطر التي تبقى بعد تطبيق الترميز؟
يقلل الترميز التعامل المباشر مع بيانات البطاقة عندما يُنفذ كما ينبغي، لكنه لا يحمي تلقائيًا عناوين العملاء وبيانات دخولهم ومراسلاتهم، ولا يمنع اختراق حساب إداري أو تعطل مزود الدفع، ولهذا يظل تأمين الحسابات وإدارة الصلاحيات والتحديثات والاستجابة للحوادث جزءًا من تشغيل المتجر.
ويستحق مسار الدعم مراجعة مستقلة، فقد يكون الدفع منظمًا بينما يطلب موظف من العميل إرسال بيانات حساسة في رسالة لحل مشكلة طلب، عندها تعود البيانات إلى بيئة لم تُصمم لاستقبالها، وتحتاج الإجراءات المكتوبة والتدريب إلى منع هذا الالتفاف على مسار الدفع المعتمد.
مراجعة عملية قبل اعتماد الحل
يمكن للفريق استخدام الخطوات التالية كأساس لمراجعة داخلية مشتركة بين المسؤول التقني والجهة المالية، ثم إرفاق نتائجها بمستندات التكامل، والمقصود تحويل الأسئلة العامة إلى أدلة يمكن التحقق منها.
ارسم مسار البيانات، من إدخال البطاقة حتى تأكيد الطلب، وحدد كل نظام يستقبل الرقم الأصلي أو الرمز أو نتيجة العملية.
راجع السجلات والنسخ الاحتياطية وأدوات متابعة الأخطاء، وتحقق من أن الإعدادات لا تسجل بيانات البطاقة دون قصد.
اطلب من المزود تحديد نوع الرمز وحدود استخدامه ومسؤوليات الطرفين، وراجع ما يحدث للوسائل المحفوظة عند إنهاء الخدمة.
حدد صلاحيات إنشاء الدفعات وتنفيذ الاسترجاع وتغيير إعدادات البوابة، ومن يراجع هذه الصلاحيات داخل المنشأة.
اختبر الدفع الناجح والمرفوض والاسترجاع الجزئي وانقطاع الاتصال باستخدام بيئة الاختبار والبيانات التجريبية التي يتيحها المزود.
راجع نطاق التقييم ونموذجه المناسب مع الجهة المختصة، ثم وثق الأدلة والقرارات وموعد المراجعة التالية.
مثال توضيحي لمتجر يريد الاحتفاظ بميزة الشراء السريع
لنفترض متجرًا يقدم ميزة حفظ البطاقة لعملائه، يمكن أن يكون هدف المراجعة الاحتفاظ بهذه الميزة مع تقليل وصول بيانات البطاقة إلى أنظمته، فيبدأ الفريق بتوثيق الجهة التي تقدم حقول الدفع، والبيانات التي يستلمها المتجر، والصلاحيات التي تستخدم المعرّف المحفوظ، ثم يختبر تنفيذ الطلب والاسترجاع وتحديث وسيلة الدفع.
وتكون مخرجات المراجعة واضحة، مثل مخطط تدفق معتمد وسجل صلاحيات ونتائج اختبارات ووصف لمسؤوليات المزود والمتجر، ويستطيع الفريق العودة إلى هذه المستندات عند تغيير الإضافة أو تحديث طريقة الدفع، بدل بدء المراجعة من الصفر في كل مرة.
تأكيد الدفع وتحديث الطلب جزء من سلامة التكامل
تقليل بيانات البطاقة لا يحل تلقائيًا مشكلة اختلاف حالة الطلب عن حالة الدفع، فقد تكتمل العملية ثم يغلق العميل الصفحة أو ينقطع اتصاله قبل العودة إلى المتجر، ولهذا ينبغي أن يوضح تصميم التكامل كيف يتأكد الخادم من نتيجة العملية وكيف يحدث الطلب، بدل اعتبار ظهور صفحة النجاح وحده دليلًا كافيًا لتنفيذ التسليم.
توضح وثائق Stripe أن إشعارات الأحداث قد تصل أكثر من مرة وقد لا تصل بترتيب إنشائها، وأن على النظام التحقق من مصدرها والتعامل مع التكرار، ويمكن تحقيق ذلك ضمن تصميم التكامل بتسجيل معرفات الأحداث المعالجة وربطها بالعملية والطلب، مع مراجعة الحالة من المصدر المعتمد عند الحاجة بدل تنفيذ الإجراء مرة جديدة لكل إشعار.
ومن اختبارات القبول المفيدة محاكاة نجاح الدفع مع إغلاق المتصفح، وتأخر الإشعار، ووصول إشعار مكرر، ثم التحقق أن الطلب ينتقل إلى الحالة الصحيحة وأن التسليم أو منح الخدمة لا يتكرر دون قصد، وهذه أمثلة لاختبار سلامة المسار التشغيلي، وتُنفذ في بيئة الاختبار بحسب آلية المزود المستخدم دون تعميم خصائص مزود واحد على جميع البوابات.
أسئلة شائعة
هل الرمز بديل آمن يمكن مشاركته دون قيود؟
لا يفترض الفريق أن كل رمز غير مؤثر إذا كُشف، فخصائصه تعتمد على نوعه وسياق استخدامه والصلاحيات المرتبطة به، والأفضل التعامل مع المعرّفات وبيانات الدخول إلى البوابة وفق حدود الوصول المعتمدة، وطلب شرح واضح من المزود لما تسمح به القيم المحفوظة.
هل يكفي وجود الترميز لاختيار SAQ A؟
لا، اختيار نموذج التقييم يتطلب استيفاء شروطه وفق البيئة الفعلية، ويُراجع مع الجهة التي تقبل إثبات الامتثال، ولا يمكن حسمه من اسم البوابة أو طريقة عرض البطاقة في صفحة الحساب.
هل تحتاج المتاجر إلى تخزين CVV لتنفيذ الاشتراكات؟
لا، يوضح مجلس PCI أن الاحتفاظ برمز التحقق بعد اعتماد العملية محظور لهذا الغرض أيضًا، ولا تغيّر موافقة العميل أو تشفير القيمة هذا الحكم.
ربط حماية المدفوعات ببقية أولويات المنشأة
تكتمل قيمة الترميز عندما يعرف الفريق ما الذي أخرجه من مسار البيانات، وما الذي بقي مسؤولًا عنه، ويمكن متابعة موضوع ترتيب الأولويات في مقال خريطة المخاطر السيبرانية، أو مراجعة دور التوعية في الحد من التصيّد الذي يستهدف حسابات العمل.
