ما مدى صعوبة بناء تطبيق Tap to Pay الخاص بك؟ (لقد جربنا ذلك)

الأمر أصعب مما توحي به كتيبات أدوات تطوير البرمجيات (SDK)، والصعوبة لا تكمن في الغالب في الكود البرمجي. لقد أطلقنا ميزة Tap to Pay في تطبيق Final POS، لذا تأتي هذه الإجابة من واقع التجربة الفعلية، وليس من قراءة الوثائق والمستندات. إذا كنت تريد بناء تطبيق tap to pay الخاص بك، فخطط لمشروع برمجيات قصير محاط بمشروع تصاريح أطول بكثير: شراكة مع معالج مدفوعات، وتصريح يدوي من Apple أو تقييم معملي على Android، ومراجعة للتطبيق، كل ذلك قبل أول عملية دفع فعلية بالنقر.

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

ما الذي يفعله تطبيق tap to pay فعلياً؟

تحول ميزة tap to pay الهاتف نفسه إلى قارئ بطاقات. فلا حاجة لجهاز دفع أو ملحق إضافي: ينقر العميل ببطاقة لا تلامسية أو بمحفظة الهاتف مثل Apple Pay أو Google Pay مباشرة على جهاز التاجر، وتتم عملية الدفع عبر شريحة NFC بالهاتف (الراديو قصير المدى المستخدم للمدفوعات اللاسلكية). وإذا كانت المصطلحات تبدو متداخلة، فقد قمنا بتوضيح الفرق بين مدفوعات النقر عبر الهاتف وميزة Tap to Pay على الهاتف المحمول.

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

لماذا لا يمكنك قراءة البطاقة بنفسك ببساطة؟

لأن كل طبقة من طبقات النظام تتطلب إذنًا وتصريحاً قبل السماح بتشغيل الكود الخاص بك بشكل عام.

• لا تمنح Apple التطبيقات وصولاً مباشراً إلى شريحة NFC الخاصة بالمدفوعات. يجب عليك استخدام إطار عمل ProximityReader الخاص بها، والذي يقع خلف تصريح Tap to Pay on iPhone (إذن خاص تمنحه Apple لكل حالة على حدة). وتتطلب Apple أيضاً دمج تطبيقك مع موفر خدمة دفع مدعوم، أو PSP (الشركة التي تنقل الأموال فعلياً). ويقوم موفر خدمة الدفع بتوفير إعدادات القارئ المعتمدة المحملة على جهاز التاجر ويتحمل عبء الاعتماد والشهادات.

• يمنح Android المطورين وصولاً أكثر انفتاحاً إلى شريحة NFC، ولكن تطبيق قبول المدفوعات لا يزال يتعين تقييمه من قبل مختبر مستقل معترف به من قبل مجلس معايير أمن صناعة بطاقات الدفع (PCI) وفقاً لمعيار PCI MPoC (قواعد أمان قطاع البطاقات للهواتف التي تعمل كأجهزة دفع).

• وتحت كلا المنصتين، تحتاج إلى علاقة تحصيل مالي: معالج مدفوعات مستعد لتسوية الأموال لتجارك، مع الالتزام بقواعد شبكات البطاقات.

لا يمكن حل أي من هذا بكتابة كود برمجى أفضل. بل هي معاملات ورقية، وعقود، وقوائم انتظار للمراجعة.

كيف يبدو مسار الموافقة على iPhone؟

وفقاً لمتطلبات Apple المنشورة، يسير المسار على النحو التالي: امتلاك حساب مطور Apple على مستوى المؤسسة (يقدم صاحب الحساب الطلب شخصياً)، والشراكة مع موفر خدمة دفع (PSP) مدعوم في مناطقك، وطلب التصريح، ودمج واجهة برمجة تطبيقات ProximityReader أو أدوات تطوير البرمجيات (SDK) الخاصة بموفر خدمة الدفع، واتباع إرشادات تصميم Apple لشاشة الدفع، وتقديم التطبيق للمراجعة. وتشير وثائق Apple أيضاً إلى أن الميزة تعمل فقط في البلدان والمناطق المدعومة، لذا فإن التوفر نفسه يتم تحديده لك، سوقاً تلو الآخر.

اقرأ تلك القائمة مرة أخرى كصاحب عمل أو تاجر وليس كمطور. لا توجد خطوة واحدة فيها تقول "اكتب الميزة البرمجية". فالميزة هي الجزء السهل؛ أما التصريح فهو العقبة الحقيقية.

أين يذهب العمل بعد أن تنجح عملية النقر؟

تمنحك عملية النقر المعتمدة دفعة مالية، وليس نظام نقطة بيع متكامل. فبمجرد تحرك الأموال، يجب أن يكون كل شيء حول عملية النقر صحيحاً: السلة التي تتم تسويتها مقابلها، والضرائب على الإيصال، ومسار الاسترداد، والتقارير التي تطابق الأرقام (كل دولار يطابق عملية بيع، كل يوم). ووجدنا الفجوة نفسها عندما بحثنا في ما إذا كان بإمكانك بناء POS باستخدام Lovable أو Replit: فتوليد الواجهة سريع، ولكن طبقة التجارة تحتها هي ما يستهلك الوقت والجهد.

تأتي ميزة tap to pay أيضاً مع تحدياتها التشغيلية الخاصة. ففي تطبيقنا، يجب تسجيل عملية البيع على الجهاز نفسه الذي يقبل النقر، وهي تعمل فقط في التطبيق الأصلي (native app)، وليس في المتصفح أبداً. قيود مثل هذه لا تظهر في أي بروشور تسويقي. بل تكتشفها، وتصمم حلولاً هندسية لها، ثم تكتب مقال المساعدة الخاص بها. وعندما لا يعود الهاتف على الطاولة كافياً، فإنك تدخل في قرارات الأجهزة الفعلية على أي حال.

إذن، ما مدى صعوبة بناء تطبيق tap to pay الخاص بك؟

صعب بطريقة معينة: فالبرمجة هي الجزء الأصغر، بينما تشكل الشراكة مع معالج المدفوعات، وتصريح Apple، واعتماد المختبر على Android، ومراجعة التطبيق الجزء الأكبر، ولا يستجيب أي منها للمجهود الهندسي وحده. بالنسبة لنا كان الأمر يستحق العناء، لأن منصة POS توزع هذه التكلفة على كل تاجر يستخدمها. وأصبحت ميزة tap to pay الآن زر دفع يقوم تجارنا بتفعيله، وقبول مدفوعات Tap to Pay هو روتين بسيط من خمس خطوات على الطاولة. وإذا كانت المدفوعات هي منتجك الأساسي، فإن هذا التحدي هو ضريبة الدخول. أما إذا كانت المدفوعات هي مجرد وسيلة لتحصيل أموالك، فإن بناء تطبيق tap to pay الخاص بك ليس له أي جدوى مالية؛ فالنسخة الجاهزة موجودة بالفعل داخل تطبيقات POS، والرسوم هي المكان الذي تكمن فيه المقارنة الحقيقية.

القاعدة الذهبية: إذا كانت الميزة تحتاج إلى إذن من جهة أخرى لتكون موجودة، فلن يختصرها أي قدر من الأكواد الذكية.