Наскільки складно створити власний додаток для безконтактної оплати Tap to Pay? (Ми спробували)

Складніше, ніж обіцяють рекламні буклети SDK, і основні труднощі полягають зовсім не в коді. Ми запустили Tap to Pay у додатку Final POS, тому ця відповідь ґрунтується на реальному досвіді, а не на читанні документації. Якщо ви хочете створити власний додаток для безконтактної оплати, готуйтеся до короткого проекту розробки ПЗ, загорнутого в набагато триваліший проект отримання дозволів: партнерство з платіжним провайдером, ручне надання дозволу від 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 entitlement (спеціальний дозвіл, який Apple надає індивідуально для кожного випадку). Apple також вимагає інтеграції з підтримуваним постачальником платіжних послуг, або PSP (компанією, яка безпосередньо переказує гроші). PSP надає сертифіковані конфігурації зчитувача, які завантажуються на пристрій продавця, і бере на себе основний тягар сертифікації.

• Android надає розробникам більш відкритий доступ до NFC, але додаток для прийому платежів все одно має пройти оцінку в незалежній лабораторії, визнаній PCI, на відповідність стандарту PCI MPoC (правила безпеки карткової індустрії для телефонів, що виступають у ролі платіжних терміналів).

• Окрім обох платформ, вам потрібні партнерські відносини з еквайєром: процесинговим центром, готовим проводити розрахунки для ваших продавців з дотриманням усіх правил карткових мереж.

Нічого з цього не можна вирішити просто написанням кращого коду. Це паперова робота, контракти та черги на перевірку.

Як виглядає шлях отримання дозволу на iPhone?

Відповідно до опублікованих вимог Apple, цей шлях виглядає так: мати обліковий запис розробника Apple на рівні організації (власник облікового запису особисто подає запит), укласти партнерство з підтримуваним PSP у ваших регіонах, надіслати запит на отримання дозволу, інтегрувати ProximityReader API або SDK вашого PSP, дотримуватися інструкцій Apple щодо дизайну екрана оплати та надіслати додаток на перевірку. В документації Apple також зазначено, що ця функція працює лише в підтримуваних країнах та регіонах, тому сама доступність визначається для вас ринок за ринком.

Перечитайте цей список ще раз як засновник бізнесу чи продавець, а не як розробник. Жоден крок у ньому не звучить як «написати функцію». Функція — це найпростіша частина; дозвіл — ось справжня перешкода.

Куди спрямовується робота після того, як безконтактна оплата запрацює?

Схвалена безконтактна оплата дає вам платіж, але не POS-систему. Щойно гроші починають рухатися, все навколо платежу має працювати бездоганно: кошик, за яким проводяться розрахунки, податки в чеку, шлях повернення коштів та звітність, що узгоджується (кожен долар прив'язаний до продажу, щодня). Ми виявили таку ж прогалину, коли досліджували, чи можна побудувати POS за допомогою Lovable або Replit: створення інтерфейсу відбувається швидко, а комерційний рівень під ним — це те, що забирає найбільше часу.

Tap to Pay також має свої операційні особливості. У нашій реалізації продаж має бути оформлений на тому самому пристрої, який приймає безконтактну оплату, і це працює лише в нативному додатку, ніколи в браузері. Подібні обмеження не описують у рекламних буклетах. Ви виявляєте їх, шукаєте інженерні рішення, а потім пишете статтю довідки. А коли телефону на прилавку стає замало, ви все одно переходите до реальних рішень щодо обладнання.

Отже, наскільки складно створити власний додаток Tap to Pay?

Складно в особливий спосіб: написання коду — це найменша частина роботи, тоді як партнерство з процесинговим центром, отримання дозволу від Apple, лабораторна сертифікація на Android та перевірка додатка складають основну частину, і на жоден із цих процесів не можна вплинути просто інженерними зусиллями. Для нас це мало сенс, оскільки POS-платформа розподіляє ці витрати між усіма продавцями, які її використовують. Тепер Tap to Pay — це просто кнопка оформлення замовлення, яку вмикають наші продавці, а прийом платежу через Tap to Pay — це проста процедура з п'яти кроків за прилавком. Якщо платежі — це ваш продукт, то цей складний шлях є платою за вхід. Якщо платежі — це просто спосіб отримати гроші за товар, створення власного додатка Tap to Pay не має фінансового сенсу; готова версія вже існує всередині POS-додатків, а комісії — це те, де криється справжнє порівняння.

Золоте правило: якщо для існування функції потрібен чийсь дозвіл, жоден обсяг геніального коду не скоротить цей шлях.