Tap to Pay على iPhone في السعودية: صمّم حدود الدفع

يهم إعلان Tap to Pay على iPhone في السعودية لأنه قد يحوّل جهاز iPhone متوافقًا إلى وسيلة لقبول الدفع اللاتلامسي بحضور العميل، لكنه لا يحوّل تطبيق التجارة إلى معالج مدفوعات. تحافظ المعمارية الآمنة على خمسة حدود واضحة: ينشئ تطبيق التاجر نية دفع تجارية، وتتولى طبقة القارئ من Apple عملية اللمس، ويعالج مزود خدمة الدفع PSP والمستحوذ المعتمدان المعاملة، ويمتلك Backend الحالة والمطابقة، ولا ينقل نظام التجارة الطلب إلى «مدفوع» إلا بدليل دفع متحقق.

هذا شرح عملي وليس خبر إطلاق. في 17 سبتمبر 2026، أعلن البنك المركزي السعودي أن Tap to Pay على iPhone سيتاح «قريبًا» في السعودية، مع توقع قبول بطاقات مدى والبطاقات اللاتلامسية الأخرى والمحافظ الرقمية على أجهزة iPhone المتوافقة. لم يحدد الإعلان تاريخ تشغيل نهائيًا أو قائمة PSP مكتملة أو عقد تكامل. لذلك يجب تأكيد التوفر الحالي والمزود والمنطقة قبل الالتزام بنشر الخدمة للتجار.

الإجابة أولًا

ابنِ Tap to Pay كقناة داخل آلة حالات دفع يملكها الخادم:

1. أنشئ نية دفع ثابتة من إجمالي الطلب المرجعي؛
2. اربط كل محاولة منطقية بالتاجر والفرع والموظف والجهاز وPSP؛
3. دع إعداد PSP المعتمد وتدفق ProximityReader من Apple يجمعان اللمسة اللاتلامسية؛
4. أرسل نتيجة المزود إلى Backend، لكن عامل انقطاع المهلة كحالة غير معروفة لا كفشل؛
5. تحقق من النتيجة النهائية عبر Webhook موقّع أو قراءة موثقة من المزود؛
6. انقل الطلب إلى «مدفوع» فقط من دليل متحقق؛
7. طابق التفويض والتحصيل والتسوية والاسترداد وChargeback بصورة مستقلة.

شاشة iPhone سطح لقبول الدفع، وليست مصدر الحقيقة للمال أو حالة الطلب.

ما تثبته المصادر الرسمية

يقول إعلان SAMA في 17 سبتمبر إن أجهزة iPhone المتوافقة ستقبل بطاقات مدى والبطاقات اللاتلامسية الأخرى والمحافظ الرقمية عبر NFC. ويضع القدرة ضمن بنية المدفوعات السعودية، ويذكر أن SAMA أدخلت خدمة SoftPOS في 2021.

تشرح صفحة مدى خدمة «مدى أثير» بوصفها دفعًا لاتلامسيًا عبر NFC، وتوثق خدمة POS هاتفية قائمة على أجهزة Android. هذه خلفية لتطور SoftPOS في السعودية، وليست دليلًا على أن كل تكامل أو عقد Android ينتقل تلقائيًا إلى منتج Apple.

تقول صفحة Apple للمطورين إن المطور يحتاج إلى PSP مدعوم في المنطقة المستهدفة، وطلب Entitlement الخاص بـTap to Pay على iPhone، ودمج ProximityReader أو API المزود، واتباع Human Interface Guidelines، ثم إرسال التطبيق للمراجعة. وتوضح وثائق ProximityReader أن PSP يوفر تدفق Terminal المعتمد ويعالج المعاملة المالية.

تقول Apple إن معاملات Tap to Pay مشفرة وتُعالج عبر Secure Element، وإن Apple لا تعرف ما الذي اشتراه العميل أو من هو المشتري. هذا ادعاء أمني موثق من المورد، ولا يغني عن مراجعة معمارية PSP وBackend والسجلات والصلاحيات وضوابط التسوية.

يغطي معيار Mobile Payments on COTS من PCI SSC قبول الدفع الآمن على أجهزة تجارية جاهزة، ويبني على CPoC وSPoC. ينبغي أن تحصل الفرق على دليل الامتثال والشهادات المطبق من PSP؛ ولا تصف تدفق NFC مخصصًا وغير معتمد بأنه مكافئ.

تميّز قواعد SAMA لمقدمي الربط والدعم التقني للمدفوعات بين الربط التقني وبين أنشطة منظمة مثل التعاقد مع التجار والتحقق منهم ومسؤوليات KYC/AML. يعتمد التصنيف القانوني الدقيق على الخدمة والعقد. هذا تصميم هندسي لا استشارة قانونية.

افصل حدود الملكية الخمسة

قد يجمع SDK المزود خطوات تقنية عدة، لكن الحدود المفاهيمية تظل مهمة عند الفشل والتدقيق. إذا أعاد SDK «نجاحًا» ولم يسجل Backend مرجعًا متحققًا من المزود، فلا تكون عملية البيع مكتملة بأمان.

استخدم آلة حالات لا Boolean واحدًا

يمكن أن يستخدم النموذج الداخلي العام الحالات التالية:

• created: قبل Backend المبلغ والعملة.
• reader_ready: الجهاز وجلسة PSP جاهزان.
• presented: قُدمت بطاقة أو محفظة.
• processing: لم يعد PSP بنتيجة نهائية.
• authorized أو declined أو unknown: النتيجة الفورية.
• captured: حُصل المبلغ إذا كان المزود يفصل التحصيل عن التفويض.
• settled: ضم PSP أو المستحوذ المعاملة إلى التسوية.
• partially_refunded أو refunded: غيّر استرداد متحقق صافي القيمة.
• disputed: دخل نزاع أو Chargeback لاحق إلى الدورة المالية.

لا تفرض فصل التفويض والتحصيل على PSP لا يعرضهما منفصلين. خزّن الحالة الأصلية للمزود والحالة الموحدة وإصدار خريطة التحويل. الخريطة عقد أعمال ذي إصدار وليست Switch مخفية في تطبيق الهاتف.

أنشئ نية دفع دائمة

يحسب Backend المبلغ النهائي بوحدات العملة الصغرى الصحيحة، لا Floating point. أدخل الضريبة والخصم والإكرامية والتقريب قبل بدء جلسة القارئ.

سجل داخلي أدنى:

{
  "payment_intent_id": "pay_01J...",
  "order_id": "ord_98142",
  "merchant_id": "m_204",
  "store_id": "store_riyadh_07",
  "amount_minor": 18750,
  "currency": "SAR",
  "channel": "tap_to_pay_iphone",
  "provider": "approved_psp",
  "status": "created",
  "policy_version": "in_person_payments_v3"
}

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

Idempotency للمحاولات وإعادة التنفيذ

افصل نية الدفع المنطقية عن كل محاولة. يمكن أن تقود بطاقة مرفوضة إلى محاولة أخرى. أما Timeout فيجب أن يقود أولًا إلى استعادة الحالة، لا إلى خصم جديد تلقائي.

خزّن:

• payment_intent_id للالتزام التجاري؛
• attempt_id لمعاملة PSP واحدة؛
• مفتاح Idempotency ثابتًا لإعادة المحاولة نفسها بأمان؛
• مرجع معاملة المزود عند وصوله؛
• معرّفات الجهاز والموظف وإعداد PSP؛
• أوقات الطلب والاستجابة؛
• آخر حالة متحققة من المزود ومصدرها.

إذا انقطع الاتصال بعد اللمسة، اعرض «جارٍ التحقق من الدفع» بدل «فشل». يستعلم التطبيق من Backend. ويقرأ Backend حالة المزود أو ينتظر حدثًا موثقًا. لا تنشئ محاولة جديدة إلا بعد أن تصبح السابقة نهائية أو يحل موظف مخول الغموض.

Webhooks وتأكيد القراءة

عامل Webhooks كمشاهدات موثقة لا أوامر تُصدّق عميانيًا:

1. تحقق من توقيع المزود والوقت؛
2. خزّن الحدث الخام في Inbox دائم قبل المعالجة؛
3. أزل التكرار بمعرف الحدث لدى المزود؛
4. عالج بصورة Idempotent داخل Transaction؛
5. قارن التاجر والمبلغ والعملة والمراجع مع النية المحلية؛
6. للحالات الحساسة أو الغامضة، اقرأ الحالة الحالية من المزود؛
7. أضف قيدًا إلى Ledger ثم حدّث إسقاط الطلب.

قد يصل Webhook مرتين أو بترتيب مختلف أو بعد إغلاق التطبيق. تقارن مهمة مطابقة دورية المحاولات غير النهائية وبيانات التسوية اليومية مع Ledger. عملية الهاتف ليست آلية التعافي.

الإنترنت، والوضع المحدود، والنتائج المجهولة

تقول وثيقة أمن المنصة من Apple إن Tap to Pay يمكن إعداده لوضع Store and Forward في حالات الاتصال المحدود. يعتمد التوفر وقواعد المخاطر على PSP والإعداد. لا تنشئ بنفسك علامة «مقبول دون اتصال».

استخدم جدول القرار:

«مقبول للإرسال» لا يساوي أموالًا مسوّاة. يجب أن تعكس نصوص المنتج وسياسة التنفيذ وتدريب الموظفين هذا الفرق.

ضوابط الجهاز والتاجر والموظف

Tap to Pay قناة دفع بحضور العميل، ولذلك للهوية طبقات:

• سجّل التاجر عبر مسار PSP المعتمد؛
• اربط جلسة التطبيق بالتاجر والفرع الصحيحين؛
• صادق الموظف وافصل صلاحيات البيع والاسترداد والإلغاء؛
• سجل طراز الجهاز وإصدار النظام والتطبيق ومرجع إعداد PSP؛
• طبق الحد الأدنى للإصدارات من Apple وPSP؛
• أنهِ جلسات القارئ سريعًا وألغِ الأجهزة المفقودة أو المتقاعدة؛
• استخدم إدارة الأجهزة المؤسسية عند ملاءمتها مع إبقاء ضوابط سلامة PSP.

قد يتطلب أول استخدام قبول شروط Tap to Pay. توثق Apple خيارات لقبول المدير في سيناريوهات مؤسسية مدعومة. لا تؤتمت القبول بانتحال التاجر أو تجاوز التسجيل المعتمد.

الإيصالات والطلبات والتنفيذ

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

افصل ثلاثة Ledgers:

1. Ledger الدفع: مراجع المزود والحالات وصافي المبلغ والرسوم والاسترداد والتسوية.
2. Ledger الطلب: المنتجات والضريبة والخصم والتنفيذ والإلغاء.
3. Ledger المخزون: الحجز والإفراج وحركة المخزون الفعلية.

عندما يصبح الدفع متحققًا، أصدر حدثًا داخليًا payment.confirmed. يستهلك موصل Salla أو Zid أو ERP الحدث بصورة Idempotent وينقل الطلب وفق عقده. إذا فشل تحديث المنصة، لا تعكس دفعًا صحيحًا تلقائيًا؛ ضع المطابقة في Queue وأظهر الاستثناء للعمليات.

الاسترداد والإلغاء

يبدأ الاسترداد من أمر Backend مخول يحتوي:

• مرجع المعاملة الأصلية؛
• المبلغ بوحدات صغيرة؛
• السبب والموظف؛
• مفتاح Idempotency؛
• الرصيد القابل للاسترداد؛
• استجابة المزود والتحقق اللاحق.

عالج الاسترداد الجزئي والأوامر المكررة والنتائج المجهولة. اقرأ الحالة من المزود قبل تكرار استرداد غامض. إلغاء الطلب ليس دليل استرداد، وطلب الاسترداد ليس دليل وصول المال إلى العميل.

الدفع والولاء عقدان مختلفان

توثق Apple أن Tap to Pay يمكنه أيضًا قراءة Loyalty passes المؤهلة بصورة مستقلة أو بجانب الدفع. افصل هوية الولاء عن تفويض الدفع:

• لا تستخدم معرف بطاقة الولاء كاعتماد دفع؛
• أضف النقاط بعد دفع متحقق فقط؛
• اعكس النقاط بقيد Ledger بعد استرداد متحقق؛
• احصل على موافقة واضحة قبل ربط ملف العميل بمعاملة حضورية؛
• اسمح بالدفع من دون فرض التسجيل.

هكذا لا تتحول اللمسة السهلة إلى التقاط هوية أو تسويق غير معلن.

اختبارات الفشل والأمان

قبل النشر، اختبر على الأقل:

اختبر Sandbox ومسار الاعتماد الإنتاجي كما يوثق PSP. لا يثبت Simulator أهلية الجهاز أو اللمسة أو إعداد التاجر أو التسوية.

أفضل الممارسات

• اجعل PSP/المستحوذ مرجع الحالة المالية.
• أبقِ حساب المبلغ وانتقال «مدفوع» في Backend.
• مثّل النتائج المجهولة صراحة.
• استخدم Inbox/Outbox دائمة لأحداث المزود وتحديثات المنصة.
• طابق المحاولات غير النهائية والتسوية يوميًا.
• ثبّت خرائط الحالات وعقود المزود بإصدارات.
• افصل صلاحيات البيع والاسترداد والإدارة.
• صمّم رسائل عربية وإنجليزية لكل حالة نهائية وغامضة.
• قِس زمن التفويض، ووقت استعادة Unknown، ونسبة الأحداث المكررة، وتراكم المطابقة.

أنماط خاطئة وحدود

تجنب اعتبار الطلب مدفوعًا من Callback في SDK وحده؛ أو توليد Idempotency key جديد لكل Retry؛ أو اعتبار Timeout رفضًا؛ أو تخزين بيانات البطاقة في Logs؛ أو السماح للهاتف بحساب الخصومات؛ أو ربط نجاح الدفع مباشرة باستدعاء واحد إلى Salla أو Zid؛ أو افتراض أن «لا جهاز إضافيًا» تعني غياب PSP أو المستحوذ أو الشهادات أو الامتثال.

يؤكد إعلان SAMA الاتجاه ودعم البطاقات والمحافظ المتوقع، لا تاريخ إنتاج موحدًا. وتصف وثائق Apple العالمية قدرة المنصة، ولا تضمن دعم PSP سعودي أو جهاز أو إصدار iOS أو فئة تاجر بعينها. تبقى عقود المزود ومتطلبات مدى والتزامات SAMA هي المرجع للنشر الحقيقي.

قائمة تنفيذية

• [ ] تأكد التوفر السعودي الحالي وPSP المدعوم.
• [ ] اتُفق على Entitlement وApp Review وشهادات PSP.
• [ ] رُبطت هوية التاجر والفرع والموظف والجهاز.
• [ ] تستخدم المبالغ وحدات صغيرة صحيحة ومرجعية الخادم.
• [ ] لنيات ومحاولات الدفع Idempotency ثابتة.
• [ ] تُستعاد Unknown قبل إنشاء محاولة جديدة.
• [ ] تدخل Webhooks الموقعة إلى Inbox دائم بلا تكرار.
• [ ] نُفذت قراءة المزود ومطابقة التسوية.
• [ ] بقيت Ledgers الطلب والدفع والمخزون منفصلة.
• [ ] الاسترداد Idempotent ومتحقق.
• [ ] لا تحتوي Logs بيانات دفع حساسة.
• [ ] اختُبرت الإيصالات وحالات الفشل بالعربية والإنجليزية.

لأنماط تجارة قريبة، راجع مجموعات عملاء سلة كسياسة Checkout، وWebhooks سلة المشروطة مع المطابقة، وآلة حالات طلبات سلة وزد. تجمع بوابة هندسة التجارة الإلكترونية أدلة الدفع والطلبات والمخزون والتكاملات.

المراجع

1. البنك المركزي السعودي: Tap to Pay on iPhone Launching Soon in Saudi Arabia
2. SAMA: خدمات مدى والقبول اللاتلامسي عبر NFC
3. SAMA Rulebook: قواعد التعامل مع مقدمي الربط والدعم التقني للمدفوعات
4. Apple Developer: Tap to Pay on iPhone
5. Apple Developer: ProximityReader
6. Apple Developer: إضافة دعم Tap to Pay on iPhone إلى التطبيق
7. Apple Platform Security: أمن Tap to Pay on iPhone
8. PCI SSC: Mobile Payments on COTS
9. Havarhen، صورة «iZettle chip and PIN payment terminal»، ترخيص CC BY-SA 3.0، Wikimedia Commons

إعداد: Noor Yasser

إعداد: Noor Yasser