8 вещей, которые мы узнали, внедрив платежи в Android-приложение DoorDash

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

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

Инфраструктура компаний-эмитентов кредитных карт и производителей мобильных операционных систем поддерживает бесшовные транзакции, но мобильные инженеры также должны внести свой вклад. DoorDash обработал более 2 миллиардов заказов, поэтому факторы, которые мы здесь рассматриваем, могут быть полезны другим компаниям, запускающим свои собственные мобильные платежи.

Как обычно реализуются мобильные платежи

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

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

Помимо необходимости в сложном потоке данных между внутренней и внешней системами, мобильные платежи сложны по следующим причинам:

• Несколько способов оплаты (Paypal, Google Pay, Stripe и т. д.):
  • Способы оплаты могут быть цифровым кошельком на устройстве, например Google Pay, или внешним платежным шлюзом, например Stripe или PayPal. Мы хотим предложить пользователю как можно больше вариантов, но включить все доступные способы оплаты сложно.
  • Каждый способ оплаты требует своей сложной интеграции в приложение.
  • Каждый способ оплаты требует индивидуальной стратегии тестирования.
• Пользовательский опыт:
  • Мобильные платежи должны быть максимально простыми, чтобы обеспечить быструю оплату.
  • Пользовательский интерфейс должен работать не только со всеми способами оплаты, но и с новыми и существующими пользователями. Умножьте количество способов оплаты на новые и существующие потоки пользователей, и мы получим сложную матрицу потоков для реализации и тестирования.
• Быстродействие:
  • Приложение должно оставаться работоспособным, поддерживая все способы оплаты.
  • Нам нужно убедиться, что в приложении есть вся необходимая информация, чтобы начать обработку платежей как можно быстрее, при этом сохраняя актуальность информации на наших серверах.
• Тестирование:
  • Тестирование не может быть второстепенным. Нам нужно спроектировать серверную часть и приложение таким образом, чтобы каждый способ оплаты и поток могли быть изолированы и протестированы перед выпуском.
• Мошенничество:
  • Меры по борьбе с мошенничеством должны быть реализованы в любом приложении, которое включает компонент мобильных платежей.
• Место расположения:
  • Нам необходимо учитывать регион пользователя перед обработкой его платежа, чтобы соответствовать законам и правилам каждой страны.

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

Чему мы научились, внедрив платежи в наше приложение для Android

Рис. 2. Типичный экран, на котором пользователи добавляют предпочитаемый способ оплаты

Планируйте и проектируйте будущие способы оплаты

Наши первые версии пользовательского приложения DoorDash для Android поддерживали только кредитные карты и Google Pay, поэтому вся структура базы данных и модели хранились как «Карты». Эта архитектура привела к тому, что разработчики попытались объединить результат запроса карт в базу данных вместе с другими способами оплаты, такими как Google Pay, прежде чем отправлять согласованный результат в модель представления или презентор. В то время мы также экспериментировали с PayPal, и нам пришлось измениться, чтобы приспособиться к этому.

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

Например, логика поиска текущего способа оплаты дублировалась на уровне менеджера или выше, в то время как она единый источник достоверности мог быть на уровне репозитория или базы данных. Чтобы добавить сложности, позже была введена концепция кредитов, которую мы изначально не планировали использовать на уровнях репозитория или базы данных. Это привело к пересчету информации о ценах в нескольких объектах уровня предметной области или моделях представлений, чего можно было бы избежать, если бы мы лучше спланировали архитектуру и перенесли логику на более низкие уровни инфраструктуры.

Это распространение является причиной того, что мы ввели понятие способов оплаты, которые могут работать с платежными картами, Google Pay и PayPal. В целом мы разделяем способы оплаты на две категории: локальные способы оплаты, являющиеся частью устройства, такие как Google Pay, и другие способы оплаты, требующие взаимодействия с платежным шлюзом, таким как Stripe.

Мы должны иметь возможность запрашивать у каждого из методов связанную с ним функциональность и использовать их во всем приложении по мере необходимости. Мы включили свойство, которое указывает, есть ли на устройстве цифровые кошельки, такие как Google Pay, или они существуют только на сервере. Мы назвали эти цифровые кошельки «местными способами оплаты». Пример этого приведен на рисунке 3 ниже, где методы оплаты — это абстрактный класс, который содержит общие свойства или методы, которые могут быть унаследованы конкретными методами оплаты.

Рис. 3 На диаграмме классов показаны различные типы подклассов (способов оплаты), которые наследуют общие функции и свойства надкласса метода оплаты.

Остерегайтесь ограничений и используйте рекомендации по внедрению, относящихся к способам оплаты

У поставщиков платежных услуг могут быть определенные способы отображения в приложении. Например, строгие правила UX Google Pay объясняют, как отображать логотипы и кнопки. Кроме того, Google Pay также требует, чтобы он был основным способом оплаты, где это возможно. Ресурсы приложения должны соответствовать всем правилам платежных систем.

Упростите процесс онбординга для новых пользователей

Недавно мы переписали большую часть нашего стека платежей на Android. При этом мы поняли, что у большинства новых пользователей не настроены способы оплаты. Приложение не позволило им совершить чекаут и вместо этого показало ошибку. Пользователи не знали, что делать, когда получали это сообщение, поэтому нам пришлось перепроектировать поток для быстрого включения новых пользователей. Одним из предложений здесь является использование локального метода оплаты на устройстве, такого как Google Pay, потому что он позволяет пользователям добавлять карту, когда они инициируют поток. Это означает, что пользователям не нужно иметь карту в приложении для совершения платежа.

Планируйте для потребителей в разных странах или путешествующих потребителей

Платежи обычно не могут быть реализованы универсальным способом, масштабируемым по всему миру. Каждая страна обычно имеет свои собственные методы оплаты и бухгалтерские особенности. Например, если потребитель зарегистрирован в США, но едет в Канаду и заказывает в ресторане, для компании возникают технические, юридические и бухгалтерские последствия.

Кроме того, для некоторых способов оплаты в других странах может потребоваться дополнительная проверка или информация.

В таких случаях мы должны убедиться, что публикуемые ключи API (предназначенные исключительно для идентификации учетной записи с помощью Stripe) относятся к конкретной стране, и убедиться, что мы извлекаем их на основе местоположения потребителя. Это также устраняет любые проблемы бухгалтерского учета или налогообложения, которые могут возникнуть в результате неправильного выставления счетов.

Безопасность и мошенничество

Большинство компаний не готовы бороться с мобильным мошенничеством. Мошенники пытаются найти ошибки или лазейки в каждом новом запускаемом приложении и могут использовать различные методы для обмана системы. У нас есть собственная система обнаружения фрода, которая предоставляет пользователю дополнительные проверки, когда подозревается, что какое-либо действие — например, оформление заказа, вход в систему или редактирование профиля — может быть мошенническим. Эти проверки разработаны таким образом, чтобы мошенникам было очень трудно их пройти, но они были легкими для пользователей с благими намерениями. Наши собственные системы обнаружения мошенничества состоят из моделей машинного обучения и правил, которые постоянно обновляются, чтобы не отставать от новых направлений мошенничества.

Хранение ключей или секретов API на устройстве — плохая идея, и ее следует избегать. Лучший способ — получить ключи из бэкенда. Однако у этого метода есть свои проблемы, потому что приложению потребуется кэшировать ключи или секреты API и иметь логику для их недействительности и получения нового ключа при необходимости. Также нужно быть осторожным, чтобы ключи API извлекались при запуске приложения и имели соответствующую логику повторных попыток, чтобы платежи в приложении не были ошибочными для пользователя.

План тестирования

У большинства платежных систем, таких как Google Pay или Stripe, есть тестовые и рабочие ключи API. Идея состоит в том, что тестовые ключи используются для отправки транзакций в среду песочницы (без взимания платы), в то время как активные ключи предназначены для использования в рабочей среде. Убедитесь, что серверная часть и клиент принимают и работают с этими тестовыми ключами, а также с активными производственными ключами.

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

План производительности

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

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

Добавьте много телеметрии

Телеметрия — это автоматизированное дистанционное измерение и сбор данных.

Телеметрия собирает показания и отправляет полезную информацию, которая помогает отслеживать работоспособность функций и позволяет нам узнать, действительно ли приложение служит нашим бизнес-целям. Если пользователи застревают или отваливаются где-то в потоке приложения, метрики будут отражать эту информацию. Телеметрия содержит события, которые представляют собой удобочитаемые глаголы или действия, которые мы хотим отслеживать. Обычно они представляют какое-то действие, которое пользователь выполнил, вместе с некоторыми метаданными для этого действия, например, когда пользователь выбирает другую карту или когда возникает ошибка, когда пользователь пытается заплатить.

Когда мы переписали наш стек платежей на Android, мы увидели, что потребители сталкиваются с ошибками при оплате. Однако у нас не было достаточно данных о потоках, вызвавших эти проблемы. Мы добавили дополнительную телеметрию в потоки платежей пользователей, чтобы определить новых пользователей, сколько у них способов оплаты, тип используемого устройства, был ли настроен Google Pay с существующей картой и тому подобные проблемы. Мы также добавили телеметрию для регистрации причин сбоя платежа, таких как недействительная карта, сетевые ошибки и ошибки проверки на мошенничество.

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

Вывод

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

Источник