تحصيل المدفوعات على آيفون الموظف: هل خدمة Tap to Pay جاهزة لطريقة عمل فريقكم؟

قبل تكليف المطور بتطبيق يقبل بطاقة العميل اللاتلامسية على آيفون الموظف، حددوا إعداد التاجر والأجهزة المؤهلة وطريقة الدفع البديلة. عبارة «الهاتف يدعم NFC» لا تكفي لوصف المطلوب. هذه ميزة لتحصيل دفعة بحضور العميل وتحتاج إلى ربط خاص بمزود الدفع، وليست قراءة ملصق معدات أو صفحة الدفع الإلكتروني التي يستخدمها العميل.

يستند المثال هنا إلى وثائق إعداد Tap to Pay لدى Stripe ودليل توصيل القارئ على آيفون. تخص المتطلبات هذا الربط، ولا تنطبق تلقائيا على كل مزود أو بلد. تحققوا من أهلية البلد والجهاز ونظام التشغيل والحساب قبل الاتفاق على الإطلاق. لا يقدم المقال وعدا بالموافقة أو برسوم معالجة معينة أو بقبول كل البطاقات.

هل تحتاجون فعلا إلى تطبيق دفع مخصص؟

تصف Stripe قبول المدفوعات اللاتلامسية بحضور العميل مباشرة داخل تطبيق iOS باستخدام حزمة Terminal SDK. وتشير أيضا إلى خيار لا يحتاج إلى تطوير مخصص عبر تطبيق لوحة Stripe على الهاتف. لذلك ابدؤوا بتحديد ما إذا كان التحصيل يجب أن يرتبط بمهامكم وطلباتكم، أم أن أداة موجودة تغطي الحاجة الفعلية.

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

جهزوا النشاط قبل أن يقدم العميل بطاقته

يوضح دليل الربط لدى Stripe أن قارئ Tap to Pay يرتبط بموقع Terminal عند الاتصال، بدلا من تسجيله مسبقا مثل بعض القراء الآخرين. ويظهر عادة اسم العرض الخاص بالموقع على شاشة الدفع، ما لم يُحدد اسم نشاط صراحة عند الاتصال.

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

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

الهاتف المتوافق ليس جلسة تحصيل جاهزة

تذكر Stripe أن متطلبات الأجهزة والحد الأدنى لإصدار الحزمة البرمجية قابلة للتغيير، وأن إصدارات iOS التجريبية غير مدعومة. احتفظوا بقائمة الأجهزة والبرامج التي جرى التحقق منها ضمن نطاق المشروع، بدلا من وعد مفتوح بدعم جميع هواتف الموظفين إلى الأبد.

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

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

اجعلوا البديل جزءا من عملية البيع

لا يغطي الدفع اللاتلامسي كل طرق التحقق من حامل البطاقة. تشرح Stripe أن بعض متطلبات الجهة المصدرة أو البلد تستلزم إدخال البطاقة فعليا في جهاز، وهو ما لا تدعمه Tap to Pay على آيفون. وتشمل أمثلتها حالات رمز PIN غير المتصل في المملكة المتحدة وكندا وفنلندا، مع شروط تعتمد على المنطقة والجهة المصدرة. لا تحولوا هذه الأمثلة إلى ادعاء بأن كل بطاقة صادرة من تلك البلدان ستفشل.

اتفقوا على بديل مناسب، مثل قارئ منفصل مدعوم أو وسيلة تحصيل أخرى معتمدة. وضحوا للموظفين متى يقدمونه وكيف يتحققون من المحاولة الأولى. اهتزاز الهاتف عند تقريب البطاقة ليس إيصالا ولا أساسا كافيا لوضع الطلب في حالة «مدفوع».

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