Разбираем механики платежей самых популярных электронных кошельков
В этой статье:
- Apple Pay и Google Pay заменяют SMS-код на 3DS биометрией и криптограммой устройства — банк присваивает такой транзакции полную аутентификацию (ECI 05/02), как при обычном 3D Secure.
- Второй и последующие платежи в подписке проходят как MIT без биометрии.
Привычки покупателей в онлайне изменились навсегда еще до прихода ИИ, в частности с появлением электронных кошельков от гигантов Apple и Google. Если раньше стандартный чекаут ассоциировался с вводом шестнадцати цифр карты, срока действия и CVV, за которым следовало ожидание SMS от банка, то сегодня все ждут оплаты в один клик. Приложить палец или сканировать лицо стало базовым стандартом удобства — как на веб-сайтах, так и в мобильных приложениях.
Для продавца в этом есть много плюсов: покупатели не отваливаются на этапе ввода данных, конверсия платежной формы повышается, а сам процесс выглядит современно и технологично. Однако, за внешней легкостью и бесшовностью скрывается сложная механика взаимодействия между смартфонами, банками и платежными системами, которая зависит от того, где именно происходит оплата.
Сегодня подробно разберем, чем отличаются платежи на вашем сайте и в мобильном приложении, а также разовые покупки и подписки. Понимание этих нюансов поможет вам грамотно управлять рисками и понимать техническое за кулисье платежных методов.
Что происходит «под капотом» Apple Pay и Google Pay?
Кроме удобства и скорости, электронные кошельки обеспечивают также и высокий уровень безопасности платежей. Чтобы понять, как защищены транзакции через цифровые кошельки, стоит сравнить их с классическим 3D Secure. В традиционном эквайринге 3DS — это проверка личности плательщика банком, выпустившим карту (эмитентом), где он перенаправляет пользователя на специальную страницу и просит ввести код из SMS или подтвердить операцию в банковском приложении. Если код введен верно, происходит так называемый Liability Shift (важный для мерчанта перенос ответственности): если выяснится, что карту украли мошенники, финансовые убытки возмещает банк, а не мерчант. На базе этого понятия строятся многие взаимодействия, и мы сегодня будем неоднократно на этом останавливаться.
Известно, что Apple Pay и Google Pay вообще не показывают пользователю привычных окон 3DS с SMS-кодами, при этом банк-эмитент почти всегда считает такую транзакцию полностью аутентифицированной. Как так получается?
Суть в связке трех технологий: токенизации, биометрии на самом устройстве и одноразовых криптограмм. Когда клиент добавляет карту в Apple Wallet или Google Wallet, настоящий номер карты (FPAN) не хранится ни на телефоне, ни на серверах IT-гигантов. Вместо этого международные платежные системы (Visa, Mastercard) создают для этого конкретного смартфона уникальный цифровой токен — «DPAN».
Момент оплаты выглядит следующим образом:
- Покупатель нажимает кнопку Apple Pay или Google Pay и сканирует лицо или палец;
- Чип безопасности смартфона проводит локальную биометрическую проверку;
- На основе токена карты и данных конкретной покупки чип генерирует уникальную «одноразовую криптограмму», которая действует только для этого списания;
- Платежный шлюз отправляет токен и криптограмму в банк.
Получив этот пакет данных, банк-эмитент понимает, что покупка совершена с конкретного доверенного устройства, а его владелец только что прошел биометрию. Для банка это сигнал высшей надежности, именно поэтому он присваивает транзакции статус полной аутентификации (ECI 05 для Visa или ECI 02 для Mastercard). Для бизнеса это означает, что платеж защищен от мошеннических чарджбэков точно так же, как если бы клиент ввел SMS-код, так как этот путь фактически является аналогом привычного 3DS.
Однако, эта картина выглядит по-разному в зависимости от того, где именно вы продаете товары или услуги: на сайте или через официальные магазины.
Сценарий 1. Платежи на вашем сайте (через эквайринг)
Когда вы принимаете платежи на собственном сайте через любой платежный шлюз (например, Stripe, Adyen и др.), именно ваша компания является официальным продавцом и вы сами отвечаете перед эквайером за уровень фрода и разбираетесь с диспутами. Это важно понимать, поскольку в случае с магазинами кошельков ситуация несколько иная. Рассмотрим две главные модели платежей на примерах.
Для разовых продаж (электроника, одежда, разовые услуги) Apple Pay и Google Pay работают практически всегда безупречно. Оба кошелька идут по схожему сценарию, генерируя токены и биометрическую криптограмму. С Apple Pay в браузере (Safari) клиент платит за секунду, а вы получаете полную защиту от фрод-чарджбэков за счет биометрии. Стоит учитывать что по Visa полноценный глобальный liability shift для Apple Pay гарантирован на устройствах с iOS 16.2 и новее. На более старых версиях iOS защита по Visa-транзакциям безусловно действует только для карт, выпущенных европейскими банками — за пределами Европы на старых iOS это работает не всегда.
Google Pay в родном браузере Chrome имеет два флоу работы: если карта привязана к приложению Google Wallet на смартфоне, передается криптограмма и защита работает; если же карта просто сохранена в профиле браузера Chrome, Google Pay автоматически запустит стандартный 3DS Challenge с SMS-кодом прямо внутри формы. Конверсия может быть несколько ниже, но защита от фрода все равно наступает и остается за мерчантом. Практически оба кошелька повторяют ранее придуманную технологию двухфакторки своим способом.
Особенность подписочных платежей больше психологическая, чем техническая. Мерчанты часто полагают, что, если первый платеж проходит, как описано выше, с полной аутентификацией и является подтвержденным на все 100%, то последующие защищены той же самой биометрической сессией. Однако, здесь логика также идентична карточным подпискам и 2FA происходит только при первой инициирующей транзакции. При первом платеже (CIT) пользователь находится на сайте и лично подтверждает списание своим лицом или отпечатком, за счет чего создается первая транзакция с генерацией биометрической криптограммы. Клиент доволен мгновенной оплатой, а вы защищены от фрода с lliability shift. Но вот на второй и последующие месяцы, когда платеж уже переходит в статус MIT и покупателя в этот момент нет на сайте — он спит или занимается своими делами, деньги списываются автоматически в фоновом режиме. Apple Pay и Google Pay физически не могут передать биометрическую криптограмму для списания без присутствия пользователя и эквайринг шлюз просто берет сохраненную карту и отправляет обычное автосписание со ссылкой на ID первой успешной транзакции. Но поскольку биометрии в этот момент не было, платеж идет абсолютно вне протокола 3DS. В итоге, все платежи совершаются без второго слоя подтверждения, как и свойственно подпискам по картам, в том числе. Это не недостаток системы, но важный момент, который стоит учитывать.
Сценарий 2. Покупки внутри приложений (App Store и Google Play)
Если вы продаете цифровой контент или подписки внутри мобильного приложения для iOS или Android, вы обязаны использовать встроенные биллинги сторов — Apple StoreKit и Google Play Billing. В этой модели меняется сам фундамент процесса: официальным продавцом (Merchant of Record) перед банками выступаете не вы, а сама компания Apple или Google.
Внутри App Store и Google Play разница между разовой покупкой и рекуррентной подпиской практически никак не видна. Apple и Google берут на себя полную ответственность за потенциальный фрод, поскольку пользователи привязывают карты к своим аккаунтам Apple ID или Google Account, а все покупки подтверждаются паролем или биометрией экосистемы. Сторы отвечают перед банками за легитимность списаний и, если вдруг карту украли или клиент заявляет о мошенничестве на второй или десятый месяц подписки, банк открывает спор против Apple или Google, а не против мерчанта. У вас вообще нет понятия «чарджбэк-профиль эквайринга», вы не рискуете штрафами от платежных систем и не тратите время на составление апелляций.
Если говорить о подписках, списания постоянно контролируют сами сторы. У них построены прямые интеграции с банками и собственные механизмы работы с задолженностями. Например, в случае, когда клиент требует возврат за подписку, он запрашивает его через поддержку Apple или Google. Если они одобряют возврат, эта сумма просто вычитается из итоговой ежемесячной выплаты мерчанта. Тем не менее, все эти услуги не бесплатны — за полную защиту от фрода, эквайринг и обработку платежей сторы берут комиссию 15% – 30% за каждую транзакцию. Для сравнения, в собственном веб-эквайринге комиссия обычно составляет 1.5% – 3.5%.
В итоге, мы видим, что Apple и Google построили инфраструктуры поверх уже существующих карточных механизмов и удачно монетизируют удобство интерфейса и недостатки традиционных финансов. Можно сказать, что суть та же, однако итоговый вид для клиента совершенно другой. Токенизация доказала свою эффективность и пришла к самим сетям; например, Mastercard планирует переводить большинство транзакций на токены уже к 2030 году. При этом делает это уже не с точки зрения дизайна чекаута, а для безопасности: если сырые карточные данные не вводятся на чекауте, их тяжелее похитить и уровень сохранности этой информации возрастает на максимум. За достаточно короткий срок платежная индустрия прошла большой путь: от наличных до продвинутых технологий и Monoup раскрывает все детали, чтобы помочь вам выстраивать платежную стратегию, сохраняя баланс между высокой конверсией, комиссионными издержками и защитой своего бизнеса.
