Насколько сложно создать собственное приложение Tap to Pay? (Мы попробовали)

Сложнее, чем обещают рекламные буклеты SDK, и основные трудности связаны вовсе не с кодом. Мы внедрили функцию Tap to Pay в приложении Final POS, так что этот ответ основан на реальном опыте, а не на чтении документации. Если вы хотите создать собственное приложение для приема бесконтактных платежей, приготовьтесь к тому, что небольшая программная часть будет упакована в гораздо более длительный процесс получения разрешений: партнерство с платежным процессором, ручное одобрение права (entitlement) от Apple или лабораторная оценка на Android, а также проверка приложения — и все это еще до первого реального платежа в одно касание.

Небольшая оговорка: правила платформ и индустрии платежных карт часто меняются. Все изложенное ниже актуально на момент публикации, поэтому относитесь к деталям как к моментальному снимку.

Что на самом деле делает приложение для приема бесконтактных платежей?

Функция бесконтактной оплаты превращает сам телефон в картридер. Никаких терминалов и переходников: покупатель прикладывает бесконтактную карту или мобильный кошелек (например, Apple Pay или Google Pay) прямо к устройству продавца, и платеж проходит через NFC-чип телефона (радиосвязь ближнего действия, используемая для бесконтактных транзакций). Если терминология кажется запутанной, мы подробно разобрали разницу между мобильными бесконтактными платежами и функцией Tap to Pay на мобильных устройствах.

Но здесь кроется ловушка. Считывание обычной NFC-метки — это действительно проект на выходные; энтузиасты делают это постоянно. Считывание платежной карты — совсем другой уровень. Карты работают по протоколу EMV (чиповый протокол карточной индустрии), данные карты должны оставаться зашифрованными на всем пути следования, и только сертифицированное программное обеспечение имеет право работать с ними.

Почему нельзя просто считывать карту самостоятельно?

Потому что каждый уровень этой цепочки требует разрешения, прежде чем ваш код будет допущен к работе в реальных условиях.

• Apple не предоставляет приложениям прямой доступ к платежному NFC. Вы обязаны использовать фреймворк ProximityReader, доступ к которому возможен только при наличии разрешения Tap to Pay on iPhone (специальное право доступа, которое Apple предоставляет в индивидуальном порядке). Apple также требует интеграции с поддерживаемым поставщиком платежных услуг, или PSP (компанией, которая непосредственно переводит деньги). PSP предоставляет сертифицированные конфигурации ридера, загружаемые на устройство продавца, и берет на себя бремя сертификации.

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

• Помимо обеих платформ, вам понадобятся эквайринговые отношения: процессор, готовый проводить расчеты для ваших продавцов с соблюдением всех правил карточных сетей.

Ничего из этого нельзя решить просто написанием более качественного кода. Это бумажная работа, контракты и очереди на проверку.

Как выглядит путь согласования на iPhone?

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

Прочитайте этот список еще раз с позиции основателя бизнеса или продавца, а не разработчика. Ни один из этих шагов не звучит как «написать функцию». Сама функция — это простая часть; разрешение — вот настоящий барьер.

Куда уходят силы после того, как оплата касанием заработает?

Одобренное касание дает вам платеж, но не точку продаж. Как только деньги начинают двигаться, все вокруг этого касания должно работать безупречно: корзина, к которой привязан платеж, налоги в чеке, процедура возврата и сверяемая отчетность (каждый доллар должен ежедневно сопоставляться с продажей). Мы обнаружили этот же пробел, когда изучали вопрос о том, можно ли создать POS с помощью Lovable или Replit: генерация интерфейса происходит быстро, а вот коммерческий уровень под ним — это то, на что уходят месяцы работы.

Функция бесконтактной оплаты также имеет свои операционные особенности. В нашей реализации продажа должна быть оформлена на том же устройстве, которое принимает оплату касанием, и это работает только в нативном приложении, но никогда в браузере. Подобные ограничения не описывают в рекламных буклетах. Вы обнаруживаете их, ищете технические решения в обход, а затем пишете справочную статью. А когда телефона на прилавке становится недостаточно, вы в любом случае переходите к серьезным решениям по выбору оборудования.

Итак, насколько сложно создать собственное приложение для бесконтактной оплаты?

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

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