> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # أجهزة نقاط البيع POS والدفع بالجوال SoftPOS - URL: https://arabroot.io/articles/اجهزة-نقاط-البيع-pos-والدفع-بالجوال-softpos/ - Published: 2026-10-27T16:47:16.000Z - Updated: 2026-10-27T19:06:42.000Z - Description: ماذا يحدث بين لمس البطاقة وموافقة البنك، وكيف يقبل جوال عادي الدفع بأمان، مع مختبر يبني رسالة تفويض بحقل الشريحة ويتحقق من رمزها. - Author: فريق عرب رووت - Tags: الأدلة التقنية, التقنية المالية والمدفوعات لنفرض أن الشركة الناشئة التي تبيع اشتراكات الأندية الرياضية، والتي تتبعنا أموالها في مقالات هذا القسم، بدأت تدير استقبال بعض الأندية الشريكة بنفسها: العضو يأتي إلى الاستقبال ليجدد اشتراكه أو يشتري حصة تدريب خاصة، فيدفع بالبطاقة على جهاز نقاط بيع مستأجر من بنك. وبعد شهرين جاءت الشكاوى من فريق التشغيل: الجهاز في أحد الأندية يتعطل في ساعات الذروة، وجهاز آخر يحتاج شحناً ونسيه الموظف، والنادي الجديد ينتظر جهازه منذ أسبوعين، والمدرب الشخصي الذي يبيع حصصه في الصالة لا يستطيع أن يأخذ الجهاز معه. واقترح مدير المنتج حلاً سمع عنه: «لماذا لا يقبل جوال الموظف الدفع مباشرة؟ العضو يلمس جوال الموظف ببطاقته أو جواله وتنتهي العملية». فسأل مهندس الأمن في الفريق سؤالين لم يجب عنهما أحد في الاجتماع: إذا كان جوال الموظف عليه تطبيقات من كل نوع وقد يكون مخترقاً، فكيف نثق بأن المبلغ الذي دفعه العضو هو المبلغ الذي وصل إلى البنك؟ وماذا عن الرقم السري PIN، هل يكتبه العضو على شاشة جوال لا نعرف ما عليه؟ والإجابة عن السؤالين تحتاج أن نفهم ما يحدث في الثانيتين بين لمس البطاقة وظهور كلمة «مقبولة»، وهذا موضوع هذا المقال. ففي مقال [كيف يعمل الدفع بالبطاقة](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B9%D9%85%D9%84-%D8%B9%D9%85%D9%84%D9%8A%D8%A9-%D8%A7%D9%84%D8%AF%D9%81%D8%B9-%D8%A8%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A9-%D8%A7%D9%84%D8%AA%D9%81%D9%88%D9%8A%D8%B6-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%A7%D8%B9%D8%AA%D8%B1%D8%A7%D8%B6/) شرحنا أطراف العملية والتفويض والتسوية والاعتراض، وذكرنا باختصار الدفع بحضور البطاقة في استقبال النادي، وفي مقال [رسائل البنوك ISO 8583](https://arabroot.io/articles/%D8%B1%D8%B3%D8%A7%D8%A6%D9%84-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-iso-8583-%D9%84%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%88-iso-20022-%D9%84%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84%D8%A7%D8%AA/) شرحنا شكل رسالة التفويض بايتاً بايتاً. وهنا نكمل من جهة جهاز القبول نفسه: الجهاز التقليدي، والقارئ المتصل بالجوال، والجوال وحده الذي يسمى SoftPOS، وما تحمله الشريحة في رسالة التفويض، ولماذا يستطيع البنك المصدر أن يكتشف المبلغ المعدل حتى لو كان الجهاز نفسه مخترقاً. وسوف نناقش في هذا المقال ما يلي: - أطراف الدفع بحضور البطاقة، ومن يملك القرار، وأين يقف جهاز القبول. - ثلاثة أشكال لقبول البطاقة: جهاز نقاط البيع التقليدي، والقارئ المتصل بالجوال mPOS، والجوال وحده SoftPOS. - ما يحدث في ثانيتين بعد اللمس: بيانات الشريحة، والرمز الذي تحسبه لمرة واحدة ARQC، والعداد ATC. - الحقل 55 في رسالة ISO 8583، وصيغة TLV التي تحمل بها بيانات الشريحة. - مختبر في Python: رسالة تفويض حقيقية بحقل الشريحة ورمز يحسب بمفتاح اختبار، وخمس حالات يقبلها المصدر أو يرفضها. - أمن SoftPOS ومعيار PCI MPoC، وانتهاء معياري SPoC وCPoC، وما أعلنه البنك المركزي عن قبول الدفع على الجوال. - تشغيل الأجهزة في الواقع: الإدارة عن بعد، والمطابقة، والاسترداد، والقرار في قصتنا. ## من يملك القرار في الدفع بحضور البطاقة؟ عندما يلمس العضو الجهاز ببطاقته تمر العملية بخمسة أطراف، والصورة التالية تبينها بترتيب حركة الطلب: ![خمس محطات من اليمين إلى اليسار: البطاقة أو الجوال Card أو wallet الشريحة تحسب رمزاً لمرة واحدة، ثم جهاز القبول POS أو SoftPOS يقرأ ويجمع البيانات ويرسل طلب التفويض، ثم المستحوذ Acquirer host بنك التاجر أو مزوده يدير الأجهزة ومفاتيحها، ثم الشبكة مدى أو Visa أو Mastercard توجه الطلب إلى البنك المصدر، ثم البنك المصدر Issuer يتحقق من الرمز ويقرر الموافقة، وتحتها أن الطلب يذهب ويعود في ثوان وجهاز القبول لا يملك القرار بل ينقل ما وقعته البطاقة](https://arabroot.io/content/images/2026/10/pos-softpos-01-parties.webp) جهاز القبول في المنتصف، والقرار عند المصدر في آخر السلسلة - **البطاقة أو الجوال:** البطاقة ذات الشريحة Chip، أو بطاقة مضافة إلى محفظة الجوال، وفيها برنامج صغير يحفظ مفتاحاً سرياً لا يخرج منها، ويحسب لكل عملية رمزاً يثبت أنها البطاقة الحقيقية وأنها وافقت على هذه العملية بالذات. - **جهاز القبول:** جهاز نقاط البيع Point of Sale، واختصاراً POS، أو جوال يعمل كجهاز قبول، يقرأ البطاقة ويجمع بيانات العملية ويرسل طلب التفويض، ويطبع الإيصال أو يعرضه. - **المستحوذ Acquirer:** البنك الذي يقبل العمليات نيابة عن التاجر، أو مزود الدفع الذي يعمل معه، ويدير الأجهزة: يسجلها، ويحمل مفاتيحها وإعداداتها، ويستقبل رسائلها. - **الشبكة:** مدى للبطاقات المحلية، وVisa وMastercard وغيرها للبطاقات الدولية، توجه الطلب إلى البنك الذي أصدر البطاقة. وتصف [صفحة مدى لدى البنك المركزي](https://www.sama.gov.sa/en-US/payment/Pages/mada.aspx?ref=arabroot.io) مدى بأنها من أنظمة المدفوعات الوطنية التي يملكها البنك المركزي، أطلقت في 1990، وتربط نقاط البيع والصرافات والتجارة الإلكترونية بنظام مركزي يوجه العمليات إلى البنك المصدر. - **البنك المصدر Issuer:** يملك حساب العضو، ويتحقق من رمز البطاقة، ويقرر الموافقة أو الرفض. ولاحظ نقطة هي مفتاح المقال كله: جهاز القبول لا يملك القرار، ولا يملك المفتاح الذي يثبت أن البطاقة حقيقية. فهو ينقل ما وقعته البطاقة إلى من يستطيع التحقق منه. وهذا ما يجعل سؤال مهندس الأمن قابلاً للإجابة: إذا كان المبلغ جزءاً مما وقعته البطاقة، فالجهاز المخترق الذي يغيره بعد التوقيع سيكشفه المصدر، كما سنرى بأعيننا في المختبر. وفي المملكة أصبح هذا المسار هو الطريقة الغالبة للدفع في المتاجر، ففي [كلمة محافظ البنك المركزي في مؤتمر Money20/20 الشرق الأوسط](https://www.sama.gov.sa/ar-sa/MediaCenter/News/Pages/15092026.aspx?ref=arabroot.io) بتاريخ 15 سبتمبر 2026 أن حصة المدفوعات الإلكترونية بلغت 85% من إجمالي عمليات الدفع في قطاع التجزئة بنهاية 2025، وينشر البنك المركزي بيانات عمليات نقاط البيع أسبوعياً، وقد بنينا عليها مختبراً في مقال [منظومة المدفوعات في السعودية](https://arabroot.io/articles/%D9%85%D9%86%D8%B8%D9%88%D9%85%D8%A9-%D8%A7%D9%84%D9%85%D8%AF%D9%81%D9%88%D8%B9%D8%A7%D8%AA-%D9%81%D9%8A-%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9-%D8%B3%D8%B1%D9%8A%D8%B9-%D9%88-sarie-%D9%88-%D9%85%D8%AF%D9%89-%D9%88-%D8%B3%D8%AF%D8%A7%D8%AF/). ## ثلاثة أشكال لجهاز القبول ما زال الناس يقولون «جهاز الشبكة» عن كل ما يقبل البطاقة في المتجر، ولكن خلف هذا الاسم ثلاثة أشكال مختلفة جداً في العتاد والأمان والتكلفة، والصورة التالية تقارنها: ![ثلاث لوحات: جهاز نقاط البيع Traditional POS جهاز مخصص بلوحة PIN يقرأ كل أنواع البطاقات ويحتاج شراءً أو استئجاراً وصيانة، والقارئ المتصل بالجوال mPOS قارئ صغير وجوال والأمان في القارئ وجهازان يحتاجان شحناً، والجوال وحده SoftPOS أو Tap on Phone يستخدم NFC في جوال عادي مع تطبيق وخادم مراقبة ومعيار PCI MPoC، وتحتها أنه كلما قل العتاد المخصص انتقل عبء الأمان من الجهاز إلى البرنامج والخادم الذي يراقبه](https://arabroot.io/content/images/2026/10/pos-softpos-02-types.webp) من العتاد المخصص إلى البرنامج: ثلاث طرق لنفس العملية ### جهاز نقاط البيع التقليدي الجهاز التقليدي عتاد مصمم لغرض واحد: قارئ للشريحة وللبطاقة اللاتلامسية وللشريط الممغنط، ولوحة أرقام لإدخال الرقم السري، وطابعة إيصالات، واتصال بالمستحوذ عبر شبكة الجوال أو الإنترنت. وأهم ما فيه ما لا يراه أحد: الجهاز مصمم ليقاوم العبث، فمفاتيحه محفوظة في ذاكرة محمية تمسح إذا فتح الجهاز، ولوحة الأرقام تشفر الرقم السري لحظة إدخاله داخل الجهاز نفسه، فلا يخرج الرقم مقروءاً أبداً. وهذا ما يجعله آمناً حتى لو وضع في مكان عام، ولكنه أيضاً ما يجعله مكلفاً وبطيئاً في التوزيع: يجب أن يصنع ويقيم ويحمل بالمفاتيح في بيئة آمنة ثم يشحن إلى التاجر، وإذا تعطل يستبدل لا يصلح في المتجر. وهذا هو جهاز النادي في قصتنا، بكل مشكلاته التشغيلية. ![جهاز نقاط بيع تقليدي بشاشة صغيرة ولوحة أرقام بأزرار ملونة، وبطاقة Visa مدخلة في فتحة الشريحة أسفل الجهاز](https://arabroot.io/content/images/2026/10/pos-softpos-07-photo-pos-terminal.webp) جهاز نقاط بيع تقليدي وفيه بطاقة مدخلة في قارئ الشريحة: الشاشة ولوحة الرقم السري والقارئ والطابعة في جسم واحد مصمم لهذا الغرض فقط. الصورة: Basile Morin، بترخيص [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/?ref=arabroot.io)، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Credit%5Fcard%5Fterminal%5Fin%5FLaos.jpg?ref=arabroot.io) (تم تصغيرها وتحويلها إلى WebP، والنسخة متاحة بالرخصة نفسها). ### القارئ المتصل بالجوال mPOS الشكل الثاني قارئ صغير يقرأ البطاقة ويتصل بجوال التاجر عبر Bluetooth أو كابل، والجوال يعرض المبلغ ويتصل بالإنترنت. والفكرة أن الجزء الحساس، أي قراءة البطاقة وتشفير بياناتها، يحدث داخل القارئ المحمي، والجوال مجرد ناقل لا يرى البيانات مقروءة. وهذا يجعله أرخص من الجهاز التقليدي وأسهل حملاً، ولكنه ما زال جهازين: قارئ يحتاج شحناً وتوزيعاً واستبدالاً، وجوال يحتاج تطبيقاً، وما زال قارئاً مخصصاً يجب أن يصل إلى المدرب الشخصي قبل أن يبيع أول حصة. ![يد تمسك جوالاً متصلاً به من الأعلى قارئ بطاقات صغير أبيض، وعلى الشاشة توقيع العميل بعد الدفع](https://arabroot.io/content/images/2026/10/pos-softpos-08-photo-mpos-reader.webp) قارئ mPOS صغير موصول بأعلى الجوال: القارئ يقرأ البطاقة ويحمي بياناتها، والجوال يعرض المبلغ ويأخذ التوقيع وينقل الرسالة. الصورة: EgAr، بترخيص [CC BY-SA 3.0](https://creativecommons.org/licenses/by-sa/3.0/?ref=arabroot.io)، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Mpos.jpg?ref=arabroot.io) (تم تحويلها إلى WebP، والنسخة متاحة بالرخصة نفسها). ### الجوال وحده SoftPOS الشكل الثالث يلغي العتاد المخصص كلياً: جوال عادي فيه شريحة NFC يقرأ البطاقة اللاتلامسية أو محفظة الجوال مباشرة، وتطبيق قبول يقوم بما يقوم به الجهاز التقليدي، ويسمى هذا SoftPOS أو Tap on Phone. وفي المملكة تذكر صفحة مدى لدى البنك المركزي خدمة تطبيق أجهزة نقاط البيع على أجهزة Android، وتقول إنها تمكن التجار من قبول المدفوعات من الشبكات العالمية أو بطاقات مدى مباشرة على جوالاتهم أو أجهزتهم الذكية دون حاجة إلى أجهزة نقاط بيع خاصة، مما يساعد على تقليل تكاليف الصيانة والتحديث. وفي [خبر البنك المركزي بتاريخ 17 سبتمبر 2026](https://www.sama.gov.sa/en-US/MediaCenter/News/Pages/news-1170.aspx?ref=arabroot.io) أن خدمة Tap to Pay على iPhone ستتاح قريباً في المملكة، وأنها ستمكن التجار عند إطلاقها من قبول المدفوعات مباشرة على أجهزة iPhone المتوافقة عبر تقنية الاتصال قريب المدى NFC، ببطاقات مدى والبطاقات اللاتلامسية الأخرى والمحافظ الرقمية، ويربط الخبر ذلك بخدمة نقاط البيع البرمجية SoftPOS التي قدمها البنك المركزي في 2021. وهنا يعود سؤال مهندس الأمن بكل قوته: الجهاز التقليدي آمن لأن عتاده مصمم ليحمي المفاتيح والرقم السري، أما الجوال فجهاز تجاري عادي Commercial Off-the-Shelf، واختصاراً COTS، عليه نظام تشغيل وتطبيقات من مصادر مختلفة، وقد يكون مخترقاً أو معدلاً. فكيف يقبل الدفع؟ والإجابة في جزأين: الأول أن البطاقة نفسها توقع العملية بمفتاح لا يعرفه الجوال، فلا يستطيع الجوال تزوير موافقة البطاقة ولا تغيير ما وقعته، والثاني أن حلول SoftPOS تعوض غياب العتاد الآمن ببرنامج محمي وخادم يراقب الجوال باستمرار، وهذا ما يقيمه معيار PCI MPoC الذي نشرحه لاحقاً. ولنبدأ بالجزء الأول، لأنه أساس كل شيء. ## ماذا يحدث في ثانيتين بعد اللمس؟ تقول صفحة مدى إن خدمة «أثير» تتيح إتمام الدفع على مسافة قصيرة بالبطاقات أو الأجهزة الذكية دون تلامس مع جهاز نقاط البيع، عبر تقنية الاتصال قريب المدى، وتذكر من مزايا مدى إتمام العمليات في أقل من 3 ثوان. وتصف [صفحة EMVCo للدفع اللاتلامسي](https://www.emvco.com/emv-technologies/contactless/?ref=arabroot.io) أن المستهلك يلوح ببطاقته أو جهازه أو يلمس به جهاز القبول لإتمام العملية، وأن رمز أمان يستخدم لمرة واحدة يولد لكل عملية لحماية العملية من الاحتيال، وأن مواصفات EMV للشريحة والدفع اللاتلامسي ونواة الدفع اللاتلامسي Contactless Kernel تحدد معاً كيف تتواصل الشريحة وجهاز القبول. والصورة التالية تبين الخطوات التي تحدث في تلك الثواني: ![خمس خطوات من اليمين إلى اليسار: اللمس Tap الجهاز يرسل المبلغ ورقماً غير متوقع UN، ثم الشريحة توقع ARQC رمز على المبلغ والعملة والتاريخ والعداد ATC، ثم الحقل 55 ISO 8583 field 55 بيانات الشريحة TLV داخل رسالة 0100، ثم المصدر يتحقق Verify ARQC يعيد حساب الرمز بمفتاحه ويقارن، ثم الرد 0110 مع ARPC موافقة أو رفض ورمز رد من المصدر، وتحتها أن أي تغيير في المبلغ بعد أن توقعه الشريحة يجعل الرمز لا يطابق والعداد يكشف إعادة نفس الرسالة](https://arabroot.io/content/images/2026/10/pos-softpos-03-tap.webp) البطاقة توقع، والجهاز ينقل، والمصدر يتحقق 1. **اختيار التطبيق:** عند اللمس يسأل جهاز القبول البطاقة عن تطبيقات الدفع التي تحملها، فالبطاقة قد تحمل مدى وشبكة دولية معاً، ويختار الجهاز التطبيق بحسب قواعد الشبكات وإعداداته. 2. **بيانات العملية:** يرسل الجهاز إلى البطاقة بيانات العملية: المبلغ، والعملة، ورمز الدولة، والتاريخ، ونوع العملية، ورقماً عشوائياً من أربعة بايتات يسمى الرقم غير المتوقع Unpredictable Number، ونتائج فحوص الجهاز. 3. **توقيع البطاقة:** تزيد البطاقة عدادها الداخلي Application Transaction Counter، واختصاراً ATC، ثم تحسب رمزاً من ثمانية بايتات يسمى رمز طلب التفويض Authorisation Request Cryptogram، واختصاراً ARQC، بمفتاح مشتق من مفتاح المصدر لا يخرج منها، على بيانات العملية والعداد. وهذا الرمز هو «رمز الأمان لمرة واحدة» الذي تذكره EMVCo. 4. **رسالة التفويض:** يضع الجهاز بيانات الشريحة ورمزها في رسالة تفويض بمعيار ISO 8583، في حقل خاص رقمه 55، ويرسلها إلى المستحوذ، الذي يرسلها عبر الشبكة إلى المصدر. 5. **تحقق المصدر:** المصدر يملك المفتاح الرئيسي، فيشتق مفتاح هذه البطاقة، ويعيد حساب الرمز على البيانات التي وصلته، فإذا طابق الرمز الذي حسبته البطاقة فالبيانات لم تتغير منذ وقعتها البطاقة. ثم يفحص العداد والرصيد والحدود ويقرر. 6. **الرد:** يرد المصدر برسالة فيها الموافقة أو الرفض، ومعها رمز رد Authorisation Response Cryptogram، واختصاراً ARPC، تستطيع البطاقة أن تتحقق منه في الدفع بالتلامس إذا أكملت الحوار، ليثبت أن الرد جاء من المصدر فعلاً. وفي هذه الخطوات ثلاثة عناصر تعمل معاً ضد ثلاثة أنواع من الهجوم. فالرمز ARQC يربط المبلغ والعملة والتاريخ بالبطاقة، فالجهاز الذي يغير المبلغ يكسر المطابقة، والرقم غير المتوقع يجعل الرمز مختلفاً في كل عملية حتى لو تكرر المبلغ، فلا يستطيع أحد أن يحسب رموزاً مسبقاً، والعداد ATC يتقدم في كل عملية، فالمصدر الذي يرى عداداً أقل من آخر عداد رآه لهذه البطاقة يعرف أن الرسالة قديمة أعيد إرسالها. وهذه الفكرة قديمة في عالم البطاقات، ولكنها هي ما يجعل الجوال العادي ممكناً كجهاز قبول، لأن الثقة في العملية تأتي من البطاقة والمصدر، لا من الجهاز. ### لماذا جاءت الشريحة بدلاً من الشريط؟ لكي ترى قيمة الرمز الذي تحسبه الشريحة، قارنه بما كان قبله. فالشريط الممغنط Magnetic Stripe على ظهر البطاقة يحمل بيانات ثابتة: رقم البطاقة وتاريخ انتهائها وبيانات تحقق لا تتغير من عملية إلى أخرى. والجهاز يقرأ هذه البيانات ويرسلها كما هي، فإذا نسخها أحد مرة واحدة، بجهاز مخفي داخل فتحة صراف أو بجهاز قبول معدل، استطاع أن يكتبها على بطاقة أخرى ويستخدمها كأنها الأصلية، لأن المصدر لا يرى فرقاً بين قراءة الشريط الأصلي وقراءة النسخة. وهذه هي الفكرة التي يقوم عليها نسخ البطاقات Skimming، وسوف نشرح في مقال مستقل كيف تكتشفه البنوك من جهة المدافع. أما الشريحة فلا تعطي الجهاز ما يكفي لنسخها، لأن الجزء الذي يثبت أصالتها، أي الرمز، يحسب داخلها بمفتاح لا يخرج منها، ويتغير في كل عملية بالرقم غير المتوقع والعداد. فمن ينسخ كل ما تقوله الشريحة في عملية واحدة يحصل على رمز صالح لتلك العملية فقط، بمبلغها وتاريخها وعدادها، ولا يستطيع أن يصنع منه رمزاً لعملية جديدة. ولهذا السبب بالذات تحاول عصابات النسخ دفع البطاقة إلى أن تعمل بالشريط بدلاً من الشريحة، مثل تعطيل قارئ الشريحة في الجهاز لكي يلجأ إلى الشريط، والمصدر الذي يرى عمليات شريط لبطاقة شريحة في جهاز يدعم الشريحة يرى إشارة تستحق التوقف عندها. وفي SoftPOS لا يوجد شريط أصلاً، فالجوال يقرأ البطاقة اللاتلامسية أو محفظة الجوال فقط، وهذه ميزة أمنية يغفلها من يقارن الأشكال الثلاثة بالسعر. ### من يثبت أن حامل البطاقة هو صاحبها؟ الرمز يثبت أن البطاقة حقيقية، ولا يثبت أن من يحملها صاحبها. ولهذا توجد طرق التحقق من حامل البطاقة Cardholder Verification Method: الرقم السري، أو التحقق على جهاز العميل نفسه عندما يدفع بجواله، ببصمته أو وجهه قبل أن يلمس الجهاز، أو عدم التحقق في المبالغ الصغيرة التي تحددها قواعد الشبكات والمصدر. والحدود التي تفرق بين هذه الحالات تضعها الشبكات والمصدرون وتتغير، فلن نذكر أرقاماً هنا، والمهم للمطور أن جهاز القبول يعرف من إعداداته متى يطلب الرقم السري، وأن العملية بالجوال المحمي ببصمة صاحبه تحمل علامة تقول إن التحقق حدث على الجوال. وهنا يأتي السؤال الثاني لمهندس الأمن: إذا طلب الجهاز الرقم السري، وكان الجهاز جوال الموظف، فأين يكتب العضو رقمه؟ وهذا ما يجيب عنه معيار MPoC كما سنرى. ## الحقل 55: بيانات الشريحة داخل رسالة التفويض شرحنا في مقال [رسائل البنوك](https://arabroot.io/articles/%D8%B1%D8%B3%D8%A7%D8%A6%D9%84-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-iso-8583-%D9%84%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%88-iso-20022-%D9%84%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84%D8%A7%D8%AA/) بنية رسالة ISO 8583: نوع الرسالة MTI، وخريطة الحقول Bitmap، والحقول المرقمة مثل رقم البطاقة في الحقل 2 والمبلغ في الحقل 4\. وفي الدفع بالشريحة يحمل حقل واحد هو الحقل 55 كل ما قالته الشريحة، بصيغة مختلفة عن بقية الرسالة اسمها TLV، أي وسم Tag، ثم طول Length، ثم قيمة Value. فكل عنصر يبدأ برقم من بايت أو بايتين يعرف معناه، مثل `9F02` للمبلغ و`9F26` للرمز، ثم بايت يقول كم طول القيمة، ثم القيمة نفسها. وهذه الصيغة تسمح للشبكات والمصدرين بإضافة عناصر جديدة دون تغيير بنية الرسالة، فالمستقبل الذي لا يعرف وسماً يقرأ طوله ويتخطاه. والصورة التالية تبين ما حمله الحقل 55 في رسالة المختبر: ![ثلاث لوحات: ما وقعته البطاقة Signed by the card فيها 9F02 المبلغ 000000030000 و5F2A العملة 0682 و9A التاريخ 261027 و9F37 الرقم غير المتوقع 19A47E1E، وحالة البطاقة Card state فيها 82 AIP 2000 و9F36 ATC 0001 و9F10 IAD 06010A03A00000 و95 TVR 0000000000، والرمز Cryptogram فيها 9F26 ARQC CBE10240121A2D76 و9F27 CID 80 و84 بايت كلها في الحقل 55، وتحتها أن كل وسم Tag بطوله وقيمته والمصدر يقرأها بنفس الترتيب ليعيد حساب الرمز](https://arabroot.io/content/images/2026/10/pos-softpos-04-field55.webp) 84 بايتاً تحمل المبلغ وحالة البطاقة ورمزها والجدول التالي يشرح الوسوم التي في رسالة المختبر، بقيمها كما خرجت في المخرج: | الوسم | الاسم | القيمة في المختبر | المعنى | | ----- | ------------------------------- | ----------------- | ------------------------------------------------------------------ | | 9F02 | Amount, Authorised | 000000030000 | 300.00 بصيغة BCD بخانتين عشريتين | | 9F03 | Amount, Other | 000000000000 | مبلغ إضافي مثل السحب النقدي مع الشراء، صفر هنا | | 9F1A | Terminal Country Code | 0682 | الرمز الرقمي للمملكة | | 95 | Terminal Verification Results | 0000000000 | نتائج فحوص الجهاز، أصفار تعني لم يظهر شيء | | 5F2A | Transaction Currency Code | 0682 | الرمز الرقمي للريال السعودي | | 9A | Transaction Date | 261027 | 27 أكتوبر 2026 بصيغة YYMMDD | | 9C | Transaction Type | 00 | شراء | | 9F37 | Unpredictable Number | 19A47E1E | الرقم العشوائي من الجهاز | | 82 | Application Interchange Profile | 2000 | ما تدعمه البطاقة، قيمة اختبار | | 9F36 | Application Transaction Counter | 0001 | عداد البطاقة | | 9F10 | Issuer Application Data | 06010A03A00000 | بيانات للمصدر منها رقم طريقة الحساب CVN 10 ونتائج فحوص البطاقة CVR | | 9F26 | Application Cryptogram | CBE10240121A2D76 | الرمز ARQC | | 9F27 | Cryptogram Information Data | 80 | نوع الرمز: طلب تفويض عبر الشبكة | ولاحظ أن المبلغ يظهر في الرسالة مرتين: مرة في الحقل 4 الذي يقرؤه كل نظام في الطريق، ومرة في الوسم `9F02` داخل الحقل 55 الذي وقعته البطاقة. والمصدر الحريص يقارن الاثنين، لأن الحقل 4 وحده لا يحميه شيء، وهذا ما تقيسه الحالة الرابعة في المختبر. ## المختبر: رسالة تفويض بحقل الشريحة ورمز حقيقي المختبر برنامج Python يمثل الأطراف الثلاثة التي تهمنا: البطاقة، وجهاز القبول، والمصدر. والبطاقة والمصدر يستخدمان مكتبة [pyemv](https://github.com/knovichikhin/pyemv?ref=arabroot.io) بالإصدار 1.5.0، التي تنفذ طرق حساب رمز الشريحة كما تحددها الشبكات، ومنها الطريقة التي تسميها Visa رقم 10 (CVN 10)، وتنفذ ترميز TLV بحسب قواعد BER-TLV في مواصفات EMV كما يذكر توثيقها. وجهاز القبول يبني رسالة 0100 بمكتبة [pyiso8583](https://pypi.org/project/pyiso8583/4.0.1/?ref=arabroot.io) بالإصدار 4.0.1 ومواصفتها الافتراضية، وهي نفس المكتبة التي استخدمناها في مقال رسائل البنوك. والمفتاح الرئيسي مفتاح اختبار منشور، ورقم البطاقة رقم الاختبار المعروف `4111111111111111`، ولا توجد في المختبر أي بيانات بطاقة حقيقية. والرقم غير المتوقع يولد من مولد ببذرة ثابتة حتى يعطي البرنامج نفس المخرج في كل تشغيل: ```python # pos_lab.py: one card-present (contactless) authorisation, end to end, with test keys and a test card number. # Card: computes an ARQC (Visa CVN 10 in pyemv) over the terminal's data. Terminal: packs the EMV data in # ISO 8583 field 55. Issuer: unpacks, recomputes the ARQC with its own copy of the key, answers with an ARPC. import random, sys import iso8583 from iso8583.specs import default as spec from pyemv import tlv from pyemv.cvn import VisaCVN10 RND = random.Random(2026) # fixed seed: the same unpredictable numbers on every run TEST_IMK = bytes.fromhex("0123456789ABCDEFFEDCBA9876543210") # public test key, never a real one PAN, PSN = "4111111111111111", "00" # well-known test card number class Card: def __init__(self): self.cvn, self.atc = VisaCVN10(TEST_IMK, TEST_IMK, TEST_IMK, PAN, PSN), 0 def generate_ac(self, t): self.atc += 1 # the counter moves on every transaction t["9F36"] = self.atc.to_bytes(2, "big") cvr = bytes.fromhex("03A00000") t["9F10"] = bytes.fromhex("06010A") + cvr # issuer application data: DKI, CVN 10, CVR t["9F26"] = self.cvn.generate_ac(t["9F02"], t["9F03"], t["9F1A"], t["95"], t["5F2A"], t["9A"], t["9C"], t["9F37"], t["82"], t["9F36"], cvr) t["9F27"] = b"\x80" # cryptogram type: ARQC (go online) return t def terminal_data(amount_halalas, date="261027"): return {"9F02": bytes.fromhex(f"{amount_halalas:012d}"), # amount in BCD, 2 decimals "9F03": bytes(6), "9F1A": bytes.fromhex("0682"), "95": bytes(5), "5F2A": bytes.fromhex("0682"), "9A": bytes.fromhex(date), "9C": b"\x00", "9F37": RND.randbytes(4), "82": bytes.fromhex("2000")} def request(t, amount_halalas, stan): msg = {"t": "0100", "2": PAN, "3": "000000", "4": f"{amount_halalas:012d}", "11": f"{stan:06d}", "22": "071", "23": "000", "41": "CLUB0001", "49": "682", "55": tlv.encode(t).hex().upper()} # binary field: pyiso8583 takes hex raw, _ = iso8583.encode(msg, spec) return raw class Issuer: def __init__(self): self.cvn, self.last_atc = VisaCVN10(TEST_IMK, TEST_IMK, TEST_IMK, PAN, PSN), 0 def authorise(self, raw): msg, _ = iso8583.decode(raw, spec) t = tlv.decode(bytes.fromhex(msg["55"])) atc = int.from_bytes(t["9F36"], "big") expected = self.cvn.generate_ac(t["9F02"], t["9F03"], t["9F1A"], t["95"], t["5F2A"], t["9A"], t["9C"], t["9F37"], t["82"], t["9F36"], t["9F10"][3:7]) if int(msg["4"]) != int(t["9F02"].hex()): rc, why = "05", "field 4 amount differs from the amount the card signed (9F02)" elif expected != t["9F26"]: rc, why = "05", "ARQC does not match: the signed data was changed" elif atc <= self.last_atc: rc, why = "05", f"ATC {atc} not above last seen {self.last_atc}: replay" else: rc, why = "00", "ARQC verified" self.last_atc = atc arpc = self.cvn.generate_arpc(t["9F26"], rc.encode()) # the card checks this answer came from its issuer resp = {"t": "0110", "2": msg["2"], "3": msg["3"], "4": msg["4"], "11": msg["11"], "39": rc, "41": msg["41"], "49": msg["49"], "55": tlv.encode({"91": arpc + rc.encode()}).hex().upper()} out, _ = iso8583.encode(resp, spec) return rc, why, msg, t, expected, out def show(label, rc, why, msg, t, expected, out): print(f"--- {label}") print(f"field 4 {msg['4']} 9F02 {t['9F02'].hex()} ATC {t['9F36'].hex()} UN {t['9F37'].hex()}") print(f"ARQC from card {t['9F26'].hex().upper()} recomputed {expected.hex().upper()}") print(f"response {rc}: {why} ({len(out)} bytes back)") if __name__ == "__main__": card, issuer = Card(), Issuer() t = card.generate_ac(terminal_data(30000)) # 300.00 SAR raw = request(t, 30000, 1) print("0100 request:", len(raw), "bytes; field 55:", len(tlv.encode(t)), "bytes") print("field 55 TLV:", tlv.encode(t).hex().upper()) decoded, _ = iso8583.decode(raw, spec) print("fields present:", sorted((k for k in decoded if k not in ("t", "p")), key=int)) show("1. normal tap", *issuer.authorise(raw)) t2 = card.generate_ac(terminal_data(30000)) # a compromised app changes the amount after the tap t2["9F02"] = bytes.fromhex(f"{300000:012d}") show("2. amount changed to 3,000.00 after the card signed", *issuer.authorise(request(t2, 300000, 2))) show("3. the first message sent again", *issuer.authorise(raw)) t4 = card.generate_ac(terminal_data(30000)) # a terminal bug: field 4 not equal to 9F02 show("4. field 4 says 30.00, the card signed 300.00", *issuer.authorise(request(t4, 3000, 4))) t5 = card.generate_ac(terminal_data(30000)) show("5. a new tap for the same 300.00", *issuer.authorise(request(t5, 30000, 5))) ``` وشغلناه داخل Container من الـ Docker Image الرسمية `python:3.13.17-slim`، مع تثبيت المكتبتين بإصدارات محددة، من مجلد المختبر في Git Bash على Windows: ```bash export MSYS_NO_PATHCONV=1 docker run --rm --name sfc-pos -v "$(pwd -W)":/lab -w /lab python:3.13.17-slim \ sh -c "pip install -q --root-user-action=ignore pyemv==1.5.0 pyiso8583==4.0.1 && python -W ignore::UserWarning pos_lab.py" ``` والمخرج سوف يكون كما يلي: ```text 0100 request: 158 bytes; field 55: 84 bytes field 55 TLV: 9F02060000000300009F03060000000000009F1A020682950500000000005F2A0206829A032610279C01009F370419A47E1E820220009F360200019F100706010A03A000009F2608CBE10240121A2D769F270180 fields present: ['2', '3', '4', '11', '22', '23', '41', '49', '55'] --- 1. normal tap field 4 000000030000 9F02 000000030000 ATC 0001 UN 19a47e1e ARQC from card CBE10240121A2D76 recomputed CBE10240121A2D76 response 00: ARQC verified (82 bytes back) --- 2. amount changed to 3,000.00 after the card signed field 4 000000300000 9F02 000000300000 ATC 0002 UN 70bcc951 ARQC from card 80C3E9AAD026DBB1 recomputed 1857B5FC48D3E217 response 05: ARQC does not match: the signed data was changed (82 bytes back) --- 3. the first message sent again field 4 000000030000 9F02 000000030000 ATC 0001 UN 19a47e1e ARQC from card CBE10240121A2D76 recomputed CBE10240121A2D76 response 05: ATC 1 not above last seen 1: replay (82 bytes back) --- 4. field 4 says 30.00, the card signed 300.00 field 4 000000003000 9F02 000000030000 ATC 0003 UN 5adfa480 ARQC from card 5D1B678B5431E284 recomputed 5D1B678B5431E284 response 05: field 4 amount differs from the amount the card signed (9F02) (82 bytes back) --- 5. a new tap for the same 300.00 field 4 000000030000 9F02 000000030000 ATC 0004 UN fc2f8bf3 ARQC from card B8B11CEE79BCE689 recomputed B8B11CEE79BCE689 response 00: ARQC verified (82 bytes back) ``` ### قراءة المخرج سطراً بسطر - **0100 request: 158 bytes; field 55: 84 bytes:** رسالة طلب التفويض كلها 158 بايتاً، أكثر من نصفها الحقل 55 بـ 84 بايتاً. وهذا يفسر لماذا تغير حجم رسائل البطاقات كثيراً عندما انتقلت الشبكات من الشريط الممغنط إلى الشريحة. - **field 55 TLV:** الحقل كما خرج بالست عشري، ويمكنك أن تقرأه بيدك: `9F02` ثم الطول `06` ثم ستة بايتات `000000030000`، ثم `9F03` بطول `06`، وهكذا حتى `9F27` بطول `01` وقيمة `80`. وهذا هو الجدول الذي شرحناه في القسم السابق. - **fields present:** الحقول في الرسالة: رقم البطاقة 2، ورمز المعالجة 3، والمبلغ 4، ورقم التتبع 11، وطريقة الإدخال 22 بقيمة `071`، ورقم تسلسل البطاقة 23، ومعرف الجهاز 41 بقيمة `CLUB0001`، والعملة 49، وبيانات الشريحة 55\. وقيمة طريقة الإدخال في الحقل 22 تحددها مواصفة كل مستحوذ وشبكة، والقيمة التي استخدمناها للتمثيل فقط. - **1\. normal tap:** البطاقة حسبت الرمز `CBE10240121A2D76`، والمصدر أعاد حسابه بمفتاحه على البيانات التي وصلته فخرج نفس الرمز، والمبلغ في الحقل 4 يساوي المبلغ الموقع، والعداد 1 أكبر من آخر عداد رآه المصدر (صفر)، فالرد `00`، أي موافقة، ومعه ARPC في رسالة رد من 82 بايتاً. ### ماذا لو غير الجهاز المبلغ بعد أن وقعت البطاقة؟ هذه الحالة الثانية هي سؤال مهندس الأمن نفسه: نفترض أن تطبيق القبول على الجوال مخترق، وأنه عرض للعضو 300 ريال، وأرسل إلى البطاقة 300 ريال فوقعتها، ثم غير المبلغ في الرسالة إلى 3,000 في الحقل 4 وفي الوسم `9F02` معاً قبل الإرسال. والمخرج يقول إن الرمز الذي حسبته البطاقة `80C3E9AAD026DBB1`، والرمز الذي حسبه المصدر على البيانات المعدلة `1857B5FC48D3E217`، فلا تطابق، والرد `05`، أي رفض. والسبب أن المصدر يحسب الرمز على المبلغ الذي وصله، والبطاقة حسبته على المبلغ الذي رأته، ولا يستطيع الجهاز أن يحسب رمزاً جديداً للمبلغ الجديد لأنه لا يملك مفتاح البطاقة. وهذا هو جوهر الإجابة: الجوال المخترق يستطيع أن يكذب على العضو في الشاشة، ولكنه لا يستطيع أن يجعل البطاقة توقع ما لم تره، ولا أن يمرر للمصدر غير ما وقعته البطاقة. ولكن لاحظ ما لا تحميه هذه الآلية: إذا أرسل التطبيق المخترق إلى البطاقة 3,000 من البداية وعرض للعضو 300، فستوقع البطاقة 3,000 ويوافق المصدر، لأن كل شيء متسق. والحماية من هذا لا تأتي من الرمز، وإنما من أن يرى العضو المبلغ الحقيقي في مكان لا يتحكم فيه التطبيق المخترق، مثل إشعار البنك على جواله أو شاشة محفظته عندما يدفع بالجوال، ومن أن يكون تطبيق القبول نفسه محمياً ومراقباً، وهذا ما يقيمه معيار MPoC. فالأمن هنا طبقات، والرمز طبقة واحدة منها. ### ماذا لو أعاد أحد إرسال رسالة قديمة؟ في الحالة الثالثة أعدنا إرسال الرسالة الأولى نفسها، بنفس الرمز الصحيح. والمصدر أعاد حساب الرمز فطابق، لأن الرسالة لم تتغير، ومع ذلك رفض بـ `05` لأن العداد 1 ليس أكبر من آخر عداد رآه لهذه البطاقة، وهو 1 من العملية الأولى. وهذه حماية من إعادة التشغيل Replay: من يسجل رسالة صحيحة في الطريق ويرسلها مرة أخرى لا يستطيع أن يكرر العملية. وفي المصدر الحقيقي يكون فحص العداد أكثر مرونة، لأن العمليات قد تصل بغير ترتيبها أو تفقد بعضها، فيقبل المصدر نافذة من العدادات ويراقب القفزات الكبيرة، ولكن الفكرة واحدة. ولاحظ أن هذه الحالة تختلف عن إعادة الإرسال المشروعة التي يقوم بها الجهاز عندما لا يصله رد، فتلك تحمل نفس رقم التتبع وتعالجها الأنظمة بمنطق التكرار والعكس Reversal الذي شرحناه في [مقال رسائل البنوك](https://arabroot.io/articles/%D8%B1%D8%B3%D8%A7%D8%A6%D9%84-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-iso-8583-%D9%84%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%88-iso-20022-%D9%84%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84%D8%A7%D8%AA/#timeouts)، أما المصدر في مختبرنا فيعامل كل رسالة بعداد قديم كإعادة مرفوضة، لأنه لا يملك طبقة التكرار هذه. ### ماذا لو اختلف الحقل 4 عن المبلغ الموقع؟ في الحالة الرابعة الرمز صحيح، والبطاقة وقعت 300 ريال، ولكن الحقل 4 في الرسالة يقول 30 ريالاً، كأن في برنامج الجهاز خطأ في تحويل المبلغ بين الوحدات. ورفض المصدر بـ `05` لأن المبلغين مختلفان. وقد يتساءل البعض: لماذا يرفض المصدر عملية رمزها صحيح؟ والإجابة أن الأنظمة في الطريق، مثل المستحوذ والشبكة والتسوية، تقرأ الحقل 4 لا الحقل 55، فإذا قبل المصدر عملية بمبلغين فقد يحصل التاجر مبلغاً ويخصم من العميل مبلغ آخر. وهذا الخطأ تحديداً ليس هجوماً، وإنما خلل تكامل يحدث فعلاً عندما يحول المطور المبلغ إلى هللات في مكان وينسى في مكان آخر، والمقارنة بين الحقلين في الاختبارات الآلية تكشفه قبل أن يصل إلى المصدر. والحالة الخامسة لمس جديد لنفس المبلغ بعد كل ما سبق: العداد 4، والرقم غير المتوقع جديد، والرمز جديد، والرد `00`. ولاحظ أن العداد قفز من 1 إلى 4، لأن البطاقة زادته في كل عملية حسبت فيها رمزاً، حتى العمليات التي رفضها المصدر، وهذا ما يراه المصدر الحقيقي كقفزة في العداد يتسامح معها في حدود. والصورة التالية تلخص الحالات الخمس: ![خمس بطاقات: لمس عادي 1. normal tap الرد 00 والرمز يطابق، ومبلغ معدل 2. من 300 إلى 3,000 الرد 05 والرمز لا يطابق، وإعادة الرسالة 3. replay الرد 05 والعداد لم يتقدم، وحقل 4 مختلف 4. field 4 مقابل 9F02 الرد 05 والمبلغان مختلفان، ولمس جديد 5. new tap الرد 00 وATC 0004، وتحتها أن خمس رسائل حقيقية في المختبر بمفتاح اختبار ورقم بطاقة اختبار والقرار في كل منها من المصدر](https://arabroot.io/content/images/2026/10/pos-softpos-06-lab.webp) ثلاثة أنواع من الخلل، وكلها يكشفها المصدر لا الجهاز ### مشكلتان ظهرتا أثناء المختبر المشكلة الأولى ظهرت في أول تشغيل: وضعنا بيانات الشريحة في الحقل 55 كبايتات كما يخرجها ترميز TLV، فرفضت pyiso8583 بناء الرسالة بالخطأ التالي: ```text iso8583.encoder.EncodeError: Failed to encode field, non-hex data: field 55 ``` والسبب أن الحقل 55 في المواصفة الافتراضية للمكتبة حقل ثنائي Binary، والمكتبة تأخذ قيم الحقول الثنائية كنص ست عشري وتحوله هي إلى بايتات عند البناء، وتعيده نصاً ست عشرياً عند القراءة. فالإصلاح أن نرسل `tlv.encode(t).hex().upper()`، وأن نحول القيمة عند القراءة بـ `bytes.fromhex`. والدرس العام أن الحقل الواحد له ثلاثة تمثيلات في أي نظام بطاقات: البايتات على الشبكة، والنص الست عشري في السجلات والمكتبات، والقيم المفسرة في الكود، وأغلب أخطاء التكامل تحدث عند الانتقال بينها. والمشكلة الثانية تحذيرات ظهرت مع كل عملية حساب: ```text /usr/local/lib/python3.13/site-packages/pyemv/tools.py:182: CryptographyDeprecationWarning: TripleDES has been moved to cryptography.hazmat.decrepit.ciphers.algorithms.TripleDES and will be removed from cryptography.hazmat.primitives.ciphers.algorithms in 48.0.0. _algorithms.TripleDES(key), _modes.ECB(), backend=_default_backend() ``` فمكتبة pyemv بإصدارها 1.5.0 صدرت في 2021، وتستخدم خوارزمية Triple DES من مكتبة cryptography بالطريقة القديمة، ومكتبة cryptography الحالية، وكانت في المختبر 50.0.2، تحذر من أن هذه الطريقة نقلت وأن مفاتيح Triple DES القصيرة ستلغى. والحسابات صحيحة، والمصدر طابق رموز البطاقة في المختبر، فأخفينا التحذيرات بالخيار `-W ignore::UserWarning` بعد أن قرأناها، ولكن التحذير يحمل معلومة مهمة: طريقة الحساب التي استخدمناها مبنية على Triple DES بمفاتيح من 16 بايتاً، وهي من الخوارزميات التي تحذر منها المكتبات الحديثة. وفي الإنتاج لا تحسب هذه الرموز في مكتبة Python أصلاً، وإنما داخل وحدة أمن العتاد HSM لدى المصدر والمستحوذ، حيث لا يخرج المفتاح الرئيسي أبداً، ولهذا موضوع مستقل في هذا القسم. ## SoftPOS من الداخل: الأمان دون عتاد آمن رأينا أن البطاقة والمصدر يحميان العملية من الجهاز الذي يغير ما وقعته البطاقة. ولكن الجهاز ما زال مسؤولاً عن أشياء لا يحميها الرمز: أن يعرض المبلغ الصحيح، وألا يسرب بيانات البطاقة التي يقرؤها، وأن يحمي الرقم السري إذا طلبه. وفي الجهاز التقليدي يقوم العتاد المحمي بذلك، أما في SoftPOS فالصورة التالية تبين كيف يتوزع العبء: ![أربع محطات من اليمين إلى اليسار: جوال الموظف COTS device جهاز عادي غير موثوق قد يكون مخترقاً، ثم تطبيق القبول Acceptance app يقرأ NFC ويحمي البيانات ويستقبل PIN على الشاشة، ثم المراقبة Attestation و monitoring يفحص حالة الجوال ويوقف القبول عند الشك، ثم خادم الدفع Payment back end يفك التشفير ويرسل للمستحوذ، وتحتها أن PCI MPoC يجمع قبول PIN والبطاقة اللاتلامسية على نفس الجوال ومختبرات معتمدة تقيم الحلول](https://arabroot.io/content/images/2026/10/pos-softpos-05-softpos.webp) الجوال لا يوثق به، فالحل يعوضه ببرنامج محمي وخادم يراقبه والمنطق الهندسي لهذا التصميم أن الجوال يعامل كبيئة لا يوثق بها: التطبيق يحمي مفاتيحه وبياناته بطرق برمجية تجعل استخراجها صعباً، ولا يحتفظ ببيانات البطاقة مقروءة، ويشفرها لخادم الدفع الذي يملك وحده مفتاح فكها، والخادم يفحص حالة الجوال والتطبيق قبل القبول وأثناءه، مثل أن نظام التشغيل غير معدل وأن التطبيق هو النسخة الأصلية وأن الجوال لم يتصل به ما يشير إلى العبث، ويوقف القبول على الجوال المشكوك فيه. والرقم السري يدخله العضو على شاشة الجوال نفسه، فيما يسمى إدخال الرقم السري على الشاشة PIN on Glass، بلوحة أرقام يحميها التطبيق من التطبيقات الأخرى التي تحاول قراءة الشاشة، ثم يشفر الرقم مباشرة. وهذا كله برنامج، والبرنامج يمكن أن يخطئ، ولذلك يحتاج معياراً وتقييماً مستقلاً. ### معيار PCI MPoC تصف [صفحة معيار PCI MPoC](https://www.pcisecuritystandards.org/standards/mobile-payments-on-cots-mpoc/?ref=arabroot.io) لدى مجلس معايير أمن صناعة بطاقات الدفع PCI SSC أن المعيار يبني على معيارين سابقين: معيار إدخال الرقم السري برمجياً على الأجهزة التجارية Software-based PIN Entry on COTS، واختصاراً SPoC، ومعيار الدفع اللاتلامسي على الأجهزة التجارية Contactless Payments on COTS، واختصاراً CPoC، وأن كل واحد منهما عالج وحده متطلبات أمن الحلول التي تسمح للتجار بقبول الرقم السري أو الدفع اللاتلامسي على جوال أو جهاز تجاري. وتقول الصفحة إن MPoC معيار مرن معياري Modular يقوم على الأهداف، يدعم قنوات قبول وطرق تحقق مختلفة، وإنه يجمع كثيراً من جوانب المعيارين السابقين أساساً بأن يشمل إدخال الرقم السري وبيانات البطاقة اللاتلامسية على نفس الجهاز. وتذكر الصفحة أن مختبرات معترفاً بها من المجلس تقيم حلول MPoC مقابل متطلبات المعيار، وأن المجلس يشجع التجار ومستحوذيهم على اختيار حل مدرج في قائمة المجلس. وفي [نشرة المجلس بتاريخ 1 مايو 2026](https://www.pcisecuritystandards.org/wp-content/uploads/2026/05/PCI%5FSPoC%5Fand%5FPCI%5FCPoC%5FSunset%5FBulletin.pdf?ref=arabroot.io) أعلن بدء فترة إيقاف تدريجي Sunset لمعياري SPoC وCPoC، من 1 مايو 2026 حتى 31 أكتوبر 2026، وخلالها تقبل طلبات التقييم الجديدة بنفس الإجراءات، وبعد نهايتها لا تقبل طلبات جديدة بالمعيارين، أما الحلول المدرجة حالياً فتبقى صالحة حتى انتهاء مدة إدراجها المعتادة. وتنصح النشرة الجهات التي تطور حلولاً بأن تخطط بحسب هذا الجدول، وأن تنظر في MPoC حيث يناسب. وما يعنيه هذا للشركة الناشئة أن السؤال الصحيح لأي مزود SoftPOS ليس «هل أنتم معتمدون؟» فقط، وإنما «بأي معيار، وما تاريخ انتهاء إدراجكم، وما خطتكم للانتقال إلى MPoC إذا كنتم على المعيارين القديمين؟». وقد يتساءل البعض: هل تحتاج الشركة الناشئة أن تحصل هي على تقييم MPoC؟ والإجابة لا في الغالب، فالتقييم لحل القبول نفسه، أي للمزود الذي يطور التطبيق والخادم، والتاجر يستخدم حلاً مدرجاً عبر مستحوذه. ولكن الشركة تبقى مسؤولة عن نطاقها في معيار PCI DSS، وعن أن تستخدم التطبيق كما يشترط مزوده، فلا تثبته على جوالات معدلة، ولا تضع بجانبه تطبيقات تطلب صلاحيات قراءة الشاشة، ولا تتجاهل رسائله عندما يوقف القبول على جوال. وتفاصيل نطاق PCI DSS للتاجر شرحناها في مقال [أمن بيانات البطاقات PCI DSS والترميز](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-pci-dss-%D9%88%D8%A7%D9%84%D8%AA%D8%B1%D9%85%D9%8A%D8%B2-tokenization/). ### وفي الأجهزة التقليدية: التشفير من نقطة إلى نقطة للأجهزة التقليدية معيار آخر يخفف عن التاجر، وهو التشفير من نقطة إلى نقطة Point-to-Point Encryption، واختصاراً P2PE. وتصف [صفحته لدى المجلس](https://www.pcisecuritystandards.org/standards/point-to-point-encryption/?ref=arabroot.io) أن حل P2PE يحمي بيانات الحساب بالتشفير من النقطة التي يقبل فيها التاجر البطاقة إلى نقطة فك التشفير الآمنة، فتبقى البيانات غير مقروءة حتى تصل إلى بيئة فك التشفير، وتقل قيمتها إذا سرقت، وأن التجار الذين يستخدمون حلول P2PE المدرجة لدى المجلس تنطبق عليهم متطلبات أقل من PCI DSS. والفكرة نفسها التي رأيناها في SoftPOS: التاجر لا يرى بيانات البطاقة مقروءة، فلا يحتاج أن يحميها بنفسه. ## تشغيل الأجهزة في الواقع الدفع نفسه ثانيتان، أما تشغيل عشرات الأجهزة في عدة أندية فعمل يومي يغفله من يقارن الأشكال الثلاثة بسعر الجهاز فقط. وهذه الجوانب التي يحتاج فريق الشركة الناشئة أن يسأل عنها: - **إدارة الأجهزة عن بعد Terminal Management:** المستحوذ أو مزوده يدير إعدادات كل جهاز وبرنامجه وتحديثاته من خادم مركزي، فيعرف أي جهاز في أي نادي، وأي إصدار عليه، ومتى اتصل آخر مرة. وفي SoftPOS يصبح «الجهاز» تطبيقاً على جوال، فيحتاج الفريق أن يعرف أي موظف على أي جوال يقبل باسم أي نادي. - **معرف الجهاز والتاجر:** كل جهاز له معرف في الحقل 41 وكل تاجر له معرف في الحقل 42، وهذان المعرفان هما ما يظهر في ملف التسوية. فإذا كان النادي الواحد يستخدم ثلاثة جوالات، فالربط بين معرف كل جوال والنادي والموظف شرط لكي تطابق الشركة مبيعاتها، كما شرحنا في [المطابقة](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B7%D8%A7%D8%A8%D9%82%D8%A9-reconciliation-%D9%83%D8%B4%D9%81-%D8%A7%D9%84%D8%A8%D9%86%D9%83-%D9%85%D9%82%D8%A7%D8%A8%D9%84-%D9%86%D8%B8%D8%A7%D9%85%D9%83/). - **إغلاق اليوم والتسوية:** الأجهزة تجمع عملياتها في دفعات وتغلقها في نهاية اليوم أو تلقائياً، والمستحوذ يسوي للتاجر بحسب العقد. والفرق بين ما سجله الجهاز وما وصل في التسوية يجب أن يكون صفراً، وأي عملية في الجهاز لم تظهر في التسوية تحتاج متابعة. - **الاسترداد عند الجهاز:** العضو الذي يلغي حصة اشتراها في الاستقبال يسترد عادة على نفس البطاقة، وبعض الحلول تطلب أن تلمس البطاقة الجهاز مرة أخرى. والاسترداد صلاحية حساسة، فيجب أن يحتاج موافقة مشرف أو رمزاً خاصاً، لأن الموظف الذي يستطيع أن يسترد لأي بطاقة يستطيع أن يسترد لبطاقته. - **انقطاع الاتصال:** أغلب العمليات تحتاج اتصالاً بالمصدر، والجهاز الذي لا يتصل لا يقبل. فاعرف ماذا يفعل حل القبول عند انقطاع الإنترنت في النادي، ولا تفترض أنه يحفظ العمليات ويرسلها لاحقاً، فهذا قرار تحدده قواعد الشبكات والمستحوذ. - **الإيصال:** الجهاز التقليدي يطبع، والجوال يعرض أو يرسل الإيصال برسالة أو بريد، وهذا يعني أن الحل يحتاج رقم جوال العضو أو بريده، وهي بيانات شخصية تحمى. ### الاسترداد والإلغاء: مكان الاحتيال الداخلي أكثر احتيال يتكرر عند أجهزة القبول ليس من العملاء، وإنما من داخل المتجر: موظف يسجل استرداداً لبطاقته بعملية لم تحدث، أو يلغي عملية بعد أن يأخذ ثمنها نقداً. والجهاز التقليدي والجوال سواء في ذلك، والحماية إدارية وتقنية معاً: صلاحية الاسترداد لا يملكها كل موظف، وكل استرداد مرتبط بعملية أصلية بمعرفها، ولا يتجاوز مبلغها، ويظهر في تقرير يومي يراجعه مسؤول. والنظام الذي يسمح باسترداد مستقل غير مرتبط بعملية أصلية يفتح باباً لا يغلقه إلا التدقيق المتأخر. وقد شرحنا في مقال [كشف الاحتيال](https://arabroot.io/articles/%D9%83%D8%B4%D9%81-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D9%84-fraud-detection-%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%85-%D8%AA%D8%B9%D9%84%D9%85-%D8%A7%D9%84%D8%A9/) كيف تبنى قواعد المراقبة، وهذه قاعدة تستحق أن تكون الأولى في أي نادي: نسبة الاستردادات إلى المبيعات لكل جهاز ولكل موظف. ## القرار في قصتنا: أي جهاز لأي مكان؟ عاد فريق الشركة الناشئة بعد كل ذلك إلى المشكلة الأصلية، ولم يكن القرار «SoftPOS لكل شيء»، وإنما توزيعاً بحسب المكان: | المكان | الشكل المناسب | السبب | | --------------------------------- | ------------------------------------------- | ----------------------------------------------------------------------- | | استقبال النادي الكبير بحركة عالية | جهاز نقاط بيع تقليدي، وجوال SoftPOS احتياطي | يقبل كل البطاقات بما فيها التي لا تدعم اللمس، ويطبع، والجوال يغطي العطل | | النادي الجديد قبل وصول الجهاز | SoftPOS على جوال النادي | يبدأ القبول في يوم التسجيل دون انتظار شحن جهاز | | المدرب الشخصي في الصالة | SoftPOS على جوال يملكه النادي | يقبل حيث يبيع، دون جهاز يحمله | | الفعاليات خارج النادي | SoftPOS أو mPOS | حمل خفيف، مع خطة للاتصال بالإنترنت | ولاحظ في الجدول أن الجوال في الصفين الثالث والرابع جوال يملكه النادي ويديره، لا جوال المدرب الشخصي. والسبب أن حل القبول يحتاج جوالاً تعرف حالته وتستطيع إدارته وسحبه، وأن مبيعات النادي يجب أن تمر بجهاز مسجل باسم النادي في عقد المستحوذ، لا بجهاز شخص قد يغادر غداً. والسؤال الأول للمستحوذ في كل الحالات: هل يدعم SoftPOS لبطاقات مدى والبطاقات الدولية معاً على الجوالات التي سيستخدمها النادي، وبأي حل مدرج، وماذا يحدث عندما يتاح Tap to Pay على iPhone الذي أعلنه البنك المركزي. ## أخطاء شائعة | الخطأ | لماذا يضر | البديل | | ----------------------------------------------- | ------------------------------------------- | ------------------------------------------------ | | الظن أن أمان العملية في الجهاز وحده | تصميم يثق بالجهاز ويغفل دور البطاقة والمصدر | فهم الرمز والعداد، وطبقات أمان التطبيق فوقهما | | تثبيت تطبيق القبول على جوالات شخصية أو معدلة | جهاز لا تعرف حالته، والحل قد يوقف القبول | جوالات يملكها النادي ويديرها | | الحقل 4 بوحدة والمبلغ الموقع بوحدة أخرى | رفض أو مبلغان مختلفان في الطريق | المبالغ بالهللة في كل مكان واختبار يقارن الحقلين | | خلط البايتات والنص الست عشري في الحقول الثنائية | رسائل لا تبنى أو تقرأ خطأ | تمثيل واحد لكل طبقة وتحويل في مكان واحد | | استرداد غير مرتبط بعملية أصلية | باب للاحتيال الداخلي | استرداد بمعرف العملية وصلاحية مشرف وتقرير يومي | | عدم ربط معرف كل جهاز بالنادي والموظف | تسوية لا تطابق المبيعات | سجل للأجهزة بمعرفاتها في نظام الشركة | | اختيار مزود SoftPOS دون سؤال عن معياره | حل على معيار انتهت فترة قبوله دون خطة | حل مدرج، وتاريخ إدراجه، وخطته لـ MPoC | | استخدام بطاقة حقيقية في الاختبار | بيانات حقيقية في بيئة اختبار | بطاقات ومفاتيح الاختبار من المستحوذ أو المزود | ## قائمة تحقق قبل تشغيل القبول بحضور البطاقة - أعرف أي شكل قبول لكل مكان، ولماذا، وما البديل عند عطله. - حل SoftPOS مدرج لدى PCI SSC بمعيار حالي، وأعرف تاريخ انتهاء إدراجه، والمستحوذ يدعمه لمدى والبطاقات الدولية. - الجوالات التي تقبل الدفع يملكها النادي ويديرها، دون تعديل على نظام التشغيل، ودون تطبيقات تقرأ الشاشة. - لكل جهاز وجوال معرف في الحقل 41 مسجل في نظام الشركة بالنادي والموظف، والتسوية تطابق بهذه المعرفات يومياً. - الاسترداد مرتبط بعملية أصلية، ويحتاج صلاحية خاصة، ويظهر في تقرير يومي بنسبته إلى المبيعات لكل جهاز وموظف. - أعرف سلوك الحل عند انقطاع الاتصال، والفريق يعرف ماذا يفعل عندها. - إذا كان فريقنا يبني أو يختبر رسائل التفويض: المبالغ بوحدة واحدة، والحقل 4 يطابق `9F02` في الاختبارات، والتحويل بين البايتات والنص في مكان واحد، وبطاقات ومفاتيح اختبار فقط. - الإيصالات الرقمية تحمي رقم جوال العضو أو بريده، ولا تحمل بيانات البطاقة إلا ما يسمح به المعيار. ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - جهاز القبول لا يملك القرار، فهو ينقل ما وقعته البطاقة إلى المصدر، والبطاقة توقع كل عملية برمز لمرة واحدة ARQC بمفتاح لا يخرج منها. - الرمز يربط المبلغ والعملة والتاريخ بالبطاقة، والرقم غير المتوقع يجعل كل رمز مختلفاً، والعداد ATC يكشف إعادة الرسالة. - بيانات الشريحة تسافر في الحقل 55 من رسالة ISO 8583 بصيغة TLV، والمبلغ يظهر مرتين: في الحقل 4 وفي الوسم 9F02 الموقع. - في المختبر قبل المصدر اللمس العادي، ورفض المبلغ المعدل بعد التوقيع، والرسالة المعادة، والرسالة التي يختلف حقلها 4 عن المبلغ الموقع، وظهرت لنا مشكلة تمثيل الحقل الثنائي وتحذيرات Triple DES في مكتبة قديمة. - SoftPOS يقبل الدفع على جوال عادي بتعويض غياب العتاد الآمن ببرنامج محمي وخادم يراقب الجوال، ومعيار PCI MPoC يجمع الرقم السري والدفع اللاتلامسي على نفس الجوال، وفترة الإيقاف التدريجي لمعياري SPoC وCPoC تنتهي في 31 أكتوبر 2026. - في المملكة يتيح البنك المركزي خدمة SoftPOS منذ 2021 على Android، وأعلن في سبتمبر 2026 قرب إتاحة Tap to Pay على iPhone. - التشغيل اليومي، من إدارة الأجهزة إلى المطابقة والاسترداد، يحدد نجاح الحل أكثر من شكل الجهاز. وفي مقالات قادمة بإذن الله في هذا القسم سوف نشرح الصراف الآلي من الداخل، ووحدات أمن العتاد HSM وإدارة المفاتيح التي تحسب فيها هذه الرموز في الإنتاج، وأمن الصرافات والبطاقات وكيف يكتشف النسخ Skimming. وبقية مقالات قسم التقنية المالية والمدفوعات: [![](https://arabroot.io/content/images/2026/10/card-payment-flow-cover-cover.webp)دليلكيف يعمل الدفع بالبطاقة؟ التفويض Authorization والتسويةمن ضغطة «ادفع» إلى آخر اعتراض: التفويض و3D Secure والتحصيل والتسوية والاسترداد والاعتراض، مع مختبر لأحداث مزود الدفع ومطابقتها.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B9%D9%85%D9%84-%D8%B9%D9%85%D9%84%D9%8A%D8%A9-%D8%A7%D9%84%D8%AF%D9%81%D8%B9-%D8%A8%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A9-%D8%A7%D9%84%D8%AA%D9%81%D9%88%D9%8A%D8%B6-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%A7%D8%B9%D8%AA%D8%B1%D8%A7%D8%B6/)[![](https://arabroot.io/content/images/2026/10/iso8583-iso20022-cover-cover.webp)دليلرسائل البنوك: ISO 8583 للبطاقات وISO 20022 للتحويلاتنفكك رسالة تفويض بطاقة بايتاً بايتاً، ونبني أمر تحويل بأسماء عربية ونتحقق منه بالمخطط الرسمي، ونرى ما يتعطل في كل معيار.](https://arabroot.io/articles/%D8%B1%D8%B3%D8%A7%D8%A6%D9%84-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-iso-8583-%D9%84%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%88-iso-20022-%D9%84%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/saudi-payments-cover-cover.webp)دليلمنظومة المدفوعات في السعودية: سريع وSARIE ومدى وسدادالأنظمة الوطنية للمدفوعات في المملكة كما تصفها مصادر البنك المركزي، وما يعنيه كل نظام للمطور، مع تحليل تقارير نقاط البيع الأسبوعية.](https://arabroot.io/articles/%D9%85%D9%86%D8%B8%D9%88%D9%85%D8%A9-%D8%A7%D9%84%D9%85%D8%AF%D9%81%D9%88%D8%B9%D8%A7%D8%AA-%D9%81%D9%8A-%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9-%D8%B3%D8%B1%D9%8A%D8%B9-%D9%88-sarie-%D9%88-%D9%85%D8%AF%D9%89-%D9%88-%D8%B3%D8%AF%D8%A7%D8%AF/)[![](https://arabroot.io/content/images/2026/10/pci-tokenization-cover-cover.webp)دليلأمن بيانات البطاقات PCI DSS والترميز Tokenizationنطاق PCI DSS v4.0.1 وما يمنع حفظه من بيانات البطاقة، وكيف يعمل الترميز، مع مختبر لفحص السجلات وخطر التجزئة دون مفتاح.](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-pci-dss-%D9%88%D8%A7%D9%84%D8%AA%D8%B1%D9%85%D9%8A%D8%B2-tokenization/)[![](https://arabroot.io/content/images/2026/10/fraud-detection-cover-cover.webp)دليلكشف الاحتيال Fraud Detection: قواعد أم تعلم آلة؟قارنا القواعد بنموذجين لتعلم الآلة على بيانات دفع مولدة بنفس سعة المراجعة، ورأينا من يمسك الأنماط المعروفة ومن يتأخر عن النمط الجديد.](https://arabroot.io/articles/%D9%83%D8%B4%D9%81-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D9%84-fraud-detection-%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%85-%D8%AA%D8%B9%D9%84%D9%85-%D8%A7%D9%84%D8%A9/)[![](https://arabroot.io/content/images/2026/10/card-skimming-defense-cover-cover.webp)دليلأمن الصرافات والبطاقات: كيف يكتشف النسخ Skimming؟كيف تكتشف البنوك والتجار نسخ البطاقات في الصرافات ونقاط البيع وتمنعه، من فحص الأجهزة إلى تحليل النقطة المشتركة، مع مختبر يجد الجهاز المخترق.](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B5%D8%B1%D8%A7%D9%81%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%83%D9%8A%D9%81-%D8%AA%D9%83%D8%AA%D8%B4%D9%81-%D8%A7%D9%84%D9%86%D8%B3%D8%AE-skimming/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال، وتشغيل مختبر رسالة التفويض على Python 3.13.17 داخل Docker مع pyemv 1.5.0 وpyiso8583 4.0.1 بمفتاح اختبار ورقم بطاقة اختبار، والتحقق من صفحة مدى وخبر Tap to Pay لدى البنك المركزي وصفحات PCI MPoC وCPoC وP2PE ونشرة الإيقاف التدريجي وصفحة EMVCo بتاريخ 27 أكتوبر 2026.