UPI-first checkout для индийского D2C: как построить флоу с UPI intent, понятным фолбэком на карты и меньшими отказами на мобайле.
На мобайле оплату бросают чаще не потому, что люди передумали покупать, а потому что флоу легко ломается. Экран маленький, связь прыгает, а главное - почти любой UPI-платеж означает переключение между приложениями: ваш магазин -> UPI-приложение -> обратно в браузер или WebView. Каждое такое переключение повышает шанс, что пользователь потеряется, закроет вкладку или не увидит подтверждение.
UPI отличается от карты ожиданиями. С картой человек готов вводить данные и проходить 3DS, но хочет, чтобы форма была быстрой и предсказуемой. С UPI пользователь ждет простую последовательность: выбрать UPI, подтвердить в знакомом приложении, вернуться и сразу увидеть статус. Поэтому задержки и непонятные экраны в UPI воспринимаются острее: «я уже подтвердил, почему тут все еще крутится?».
Обычно отвал происходит в нескольких точках: UPI спрятан среди десятка кнопок, intent запускается без подсказок (непонятно, что будет дальше и что делать, если приложение не открылось), после подтверждения статус долго не обновляется, а при возврате из UPI-приложения страница перезагружается и заказ «теряется». Отдельная боль - ошибки, после которых просят заново вводить адрес и контакты или повторять оплату без объяснения.
«Приоритет UPI» в UPI-first checkout - это не запрет карт и netbanking. Это про то, чтобы UPI был первым и самым простым вариантом для большинства, а остальные способы были рядом как спокойный план Б. Например: по умолчанию показывать UPI intent (с выбором популярного UPI-приложения или UPI ID), а ниже - «Оплатить картой» и «Netbanking».
Один ориентир, который почти всегда работает: люди уходят там, где они не понимают, что происходит и сколько ждать. Ваша задача - убрать сюрпризы, сократить шаги и на каждом экране давать понятный следующий ход.
UPI в чекауте обычно показывают двумя способами: через UPI intent и через запрос на оплату (collect).
Intent пытается открыть UPI-приложение пользователя и сразу подставляет сумму и получателя. Collect чаще просит ввести VPA (например, name@bank) и отправляет запрос, который потом нужно найти и подтвердить в приложении. Для мобильного UPI-first checkout intent обычно лучше: меньше ручного ввода, меньше шагов, меньше поводов передумать.
UPI intent выглядит для человека как понятный переход: нажал «Оплатить через UPI» - открылось знакомое приложение (PhonePe, Google Pay, Paytm или банк) - подтвердил оплату - вернулся в магазин. Но это всегда «прыжок» между приложениями. Если магазин открыт во встроенном браузере соцсети, возврат иногда ломается, и это частая причина зависших оплат.
Просить VPA уместно, когда intent недоступен или человек сам хочет платить через конкретный UPI ID (например, для бизнес-аккаунтов). Но по умолчанию проще дать выбор приложений или кнопку, которая открывает последнее использованное UPI-приложение. Чем меньше ручного ввода, тем меньше ошибок и отказов.
По времени у пользователей есть понятные ожидания:
Если человек вернулся из UPI-приложения, а на экране все еще загрузка, он почти всегда думает о двойном списании. Поэтому чекаут должен быстро показать один из трех исходов: «оплачено», «не оплачено», «статус уточняется».
Экран оплаты на мобайле должен отвечать на два вопроса за 3 секунды: сколько я плачу и что мне нужно сделать дальше. Остальное увеличивает шанс, что пользователь закроет вкладку или потеряется при переключении в UPI-приложение.
В UPI-first checkout принцип простой: один основной сценарий на экране, остальные способы видны, но не отвлекают.
Оставьте только то, что помогает принять решение и нажать кнопку:
Не ставьте две равнозначные кнопки («UPI» и «Карта») рядом. Это тормозит выбор. Пусть UPI будет главным действием, а смена способа оплаты - вторичной.
Под основной кнопкой добавьте «Другие способы оплаты» и раскрывающийся блок. Внутри держите карты и netbanking компактно.
Лучше вынести на следующий шаг (или в модалку), чтобы не перегружать экран:
Пример: покупатель видит итог 1 499 INR, кнопку «Оплатить через UPI», ниже - «Другие способы». Если UPI не сработал, он раскрывает блок и выбирает карту, не теряя контекст суммы и заказа.
UPI-first checkout начинается с того, что UPI стоит первым и выглядит как самый простой вариант. На экране оплаты оставьте один главный CTA: «Оплатить через UPI», а остальные методы уберите под «Другие способы оплаты».
После нажатия сразу запускайте intent и помогайте пользователю сделать один понятный выбор. Если система может показать список UPI-приложений - используйте его. Если нет - покажите короткий список популярных приложений и пункт «Другое UPI-приложение».
Линейный флоу без лишних экранов обычно выглядит так:
Экран ожидания нужен всегда, даже если ответ обычно приходит быстро. Покажите таймер (например, до 60 секунд), понятный текст («Ждем подтверждение от банка. Не закрывайте страницу.») и одну безопасную кнопку: «Вернуться к заказу». Кнопку «Оплатить еще раз» на этом этапе лучше не давать - она резко повышает риск двойной оплаты.
Частый крайний случай: пользователь вернулся из UPI-приложения, а статус не пришел (плохая сеть, приложение свернулось, банк задержал ответ). Показывайте нейтральный статус «Проверяем платеж» и предлагайте действия с низким риском: «Обновить статус» и «Выбрать другой способ оплаты». Добавьте короткую подсказку: если деньги списались, заказ подтвердится автоматически через пару минут.
UPI intent должен быть первым, но фолбэк должен быть таким же простым. Хороший UPI-first checkout не заставляет человека заново собирать заказ, искать промокод или повторять адрес, если переход в UPI не случился.
Ситуации, когда intent часто не срабатывает: не найдено ни одного UPI-приложения, среда блокирует переход (например, встроенный браузер), пользователь вернулся без подтверждения, пришла ошибка банка или PSP. Важно различать «не было попытки» и «попытка была, но неудачная» - от этого зависит, что показывать дальше.
Фолбэк должен открываться без потери состояния: сумма, доставка, скидки, выбранный метод, UPI ID (если вводился) и даже выбранный банк для netbanking должны сохраняться. Если меняется способ оплаты, меняется только «как платить», а не «что покупаю».
Переключение оформляйте как помощь, а не давление. Хорошо работает короткий блок:
Добавьте «Вернуться к UPI» одной кнопкой и сохраняйте введенные данные.
В UPI-first checkout самое неприятное - не ошибка, а неопределенность: деньги ушли или нет. Нужны понятные статусы и один безопасный сценарий на каждый.
Сведите ответы провайдера и вашего бэкенда к нескольким состояниям и всегда показывайте следующий шаг:
Для pending/unknown не оставляйте человека со спиннером. Делайте автообновление статуса (например, каждые 3-5 секунд до 60-90 секунд) и прямо пишите: «Мы проверяем платеж, не оплачивайте повторно».
Сделайте повторные попытки идемпотентными: у каждой оплаты есть уникальный идентификатор (order_id или payment_id). Если пользователь нажал «Повторить» или вернулся в чекаут, не создавайте новый платеж автоматически. Сначала проверьте статус предыдущего.
Кнопки действий держите предсказуемыми: «Повторить», «Сменить способ», «Написать в поддержку». Если пользователь закрыл вкладку и вернулся позже, по заказу должен быть виден последний известный статус и кнопка «Проверить платеж».
Тексты решают больше, чем кажется. На мобайле читают по диагонали и боятся двух вещей: что деньги спишутся два раза и что заказ пропадет. Поэтому микротексты должны быть короткими, конкретными и про следующий шаг.
На кнопках избегайте «Продолжить». Лучше называть действие и способ оплаты:
На финальном шаге добавьте сигналы доверия: сумму крупно, название магазина, номер заказа. Для UPI полезная формулировка: «Подтверждение будет в вашем UPI-приложении».
Если итог зависит от комиссии, скидки или кэшбека, объясняйте это рядом с суммой, без скрытых подсказок. Важно, чтобы «Итого к оплате» не менялось неожиданно на следующем экране.
После успешной оплаты снимайте тревогу сразу: «Оплата получена», номер заказа, что будет дальше (например, «Подтвердим и отправим SMS в течение 2 минут») и одна понятная кнопка «Перейти к заказу».
Если статус «оплата в обработке», формулировка должна защищать от повторной оплаты: «Проверяем оплату, обычно до 60 секунд. Не нажимайте оплату снова, чтобы избежать двойного списания».
На мобайле люди уходят не из-за «нежелания платить», а из-за мелких раздражителей: экран тормозит, кнопка срабатывает дважды, вылет из UPI-приложения сбрасывает состояние, а при слабой сети непонятно, что происходит.
Скорость важнее украшений. Экран оплаты должен грузиться быстро и выглядеть легким: меньше баннеров и тяжелых блоков, больше воздуха. Если вы делаете UPI-first checkout, кнопка UPI intent должна быть доступна сразу, без прокрутки.
Когда пользователь уходит в UPI-приложение и возвращается, частая причина потери оплаты - сброс экрана. Сохраняйте состояние: выбранный метод, сумму, примененный купон и, главное, статус попытки (в процессе, подтверждено, не удалось). После возврата показывайте один понятный экран с результатом, а не пустую корзину или повтор формы.
При плохой сети ведите себя честно: вместо бесконечного спиннера давайте таймер и понятный план действий. Рабочий минимум:
Защита от случайных тапов простая: блокируйте кнопку оплаты после нажатия, показывайте «запрос отправлен», а повторное нажатие превращайте в «Проверить статус».
Для маленьких экранов решает читаемость суммы. Делайте сумму и валюту крупно и контрастно. Кнопка оплаты должна быть высокой, с большим хитбоксом, и оставаться видимой (например, фиксированной внизу), чтобы человеку не приходилось искать ее после возврата из UPI-приложения.
Если вы строите UPI-first checkout, без событий в аналитике вы увидите только «оплата не прошла», но не поймете, где именно люди сдаются. Хорошая воронка для оплаты - это 6-8 понятных шагов, которые складываются в один путь пользователя.
Зафиксируйте базовые события:
Дальше добавьте метки причин и не сваливайте все в один error_text. Удобно иметь 2-3 стандартизированные метки (who, reason, stage). Примеры: отмена в UPI-приложении - user_cancel, таймаут подтверждения - provider_timeout, «недостаточно средств» - user_funds, «техническая ошибка банка» - bank_error.
Что полезно мерить по UPI: долю pending, медианное время от upi_start до успеха, и отказы после возврата (app_switch_in -> failed/abandon). Если много pending и долгие времена, людям нужен сильный экран ожидания и понятный путь «проверить статус».
Простые A/B тесты: порядок методов (UPI сверху vs выбор последним), микротекст на кнопке («Открыть UPI-приложение» vs «Оплатить через UPI»), длительность и дизайн ожидания (счетчик, подсказка, кнопка проверки статуса).
Сегментируйте результаты, иначе средние цифры обманут: новые vs повторные покупатели, версия Android и модель устройства, тип сети (Wi‑Fi/4G/плохая сеть), источник трафика, банки и UPI-приложения (если можете безопасно определить).
Когда отказы растут, начинайте с одного вопроса: на каком шаге путь ломается чаще всего. Это быстро приводит к точечным правкам вместо полной переделки чекаута.
Перед релизом пройдитесь по чекауту на реальном телефоне (Android и iPhone) и сделайте несколько тестовых оплат в разных сценариях. Цель простая: UPI должен быть самым быстрым путем, а остальные варианты - запасными, но такими же понятными.
Проверьте в первую очередь:
Отдельно прогоните «плохие» условия: слабый интернет, переключение между приложениями, закрытие UPI-приложения без оплаты. В каждом случае пользователь должен либо вернуться к понятному выбору метода оплаты, либо увидеть однозначный статус заказа: «оплачено», «ожидаем подтверждение», «не оплачено».
Представьте покупателя на недорогом Android. Он в метро, сеть плавает, а после нажатия кнопки оплаты его уводит в UPI-приложение. В UPI-first checkout важно, чтобы даже при таком раскладе человек не терялся и не бросал заказ.
Экран оплаты: выбран UPI intent, кнопка «Оплатить через UPI».
После клика - экран ожидания: «Открываем UPI-приложение. Не закрывайте эту вкладку». Плюс таймер или индикатор.
Возврат из UPI - экран успеха: «Платеж подтвержден. Заказ №1234 принят». Кнопка «Перейти к заказу» и короткое «Квитанция придет в SMS или email».
Цель - показать понятное завершение и не держать человека в неопределенности.
Иногда пользователь возвращается на сайт, а статус еще «обрабатывается». Нужен экран, который не пугает: «Мы проверяем платеж. Это обычно занимает до 1 минуты». Дайте кнопку «Проверить статус» и подпись: «Не оплачивайте повторно, пока идет проверка».
Если проверка подтверждает оплату - показывайте экран успеха. Если подтверждения нет, предложите развилку без давления: «Не видим подтверждения. Хотите попробовать еще раз через UPI или выбрать другой способ?».
Если intent не сработал (нет UPI-приложения, запрет на переключение, сбой), покажите короткое объяснение без обвинений: «Не удалось открыть UPI-приложение». Две кнопки: «Повторить UPI» и «Оплатить картой или netbanking». Важно сохранить корзину, адрес и сумму, чтобы человек не вводил ничего заново. Добавьте строку доверия: «Ваш заказ сохранен, оплата спишется только после подтверждения».
Чтобы UPI-first checkout не развалился в мелочах, начните с карты экранов и текстов. Должно быть очевидно, что видит человек на каждом шаге: выбор UPI, переход в приложение банка, возврат в магазин, ожидание статуса, успех или ошибка. Отдельно пропишите микротексты для ожидания и для сценариев, когда пользователь вернулся без оплаты.
Быстрый способ проверить логику - собрать кликабельный прототип вместе со статусами. Например, в TakProsto можно сначала описать экраны, переходы и состояния (pending на 60 секунд, успех, неуспех, неизвестно) в режиме планирования, а уже потом уточнять детали. Если вы работаете в команде и нужны быстрые итерации, удобно, что в TakProsto (takprosto.ai) есть снапшоты и откат: можно сравнить два варианта флоу и безболезненно вернуться к рабочему.
Чтобы не тратить дни на споры, идите короткими итерациями:
Параллельно подготовьте короткие требования к платежному провайдеру, чтобы не упереться в ограничения в середине разработки:
По умолчанию выбирайте UPI intent: он открывает UPI‑приложение и подставляет сумму/получателя, поэтому шагов меньше и ошибок ввода почти нет.
UPI collect (VPA) оставляйте как запасной вариант, когда intent недоступен (нет UPI‑приложения, блокируется переход) или пользователь явно хочет платить по UPI ID.
Сделайте UPI первым и самым заметным действием:
Так вы не запрещаете карты, но убираете лишний выбор в момент оплаты.
Дайте человеку понятный план и время ожидания:
Не показывайте «Оплатить еще раз» на этом шаге — это часто приводит к двойной оплате.
Вводите правило: повтор не создает новый платеж автоматически.
Практичный минимум:
payment_id/attempt_id на попытку;Это снижает риск двух списаний даже при плохой сети.
Сразу покажите короткое объяснение и два понятных выхода:
Важно: не сбрасывайте корзину, адрес, скидки и сумму. Пользователь должен сменить только способ оплаты, а не заново оформлять заказ.
Сохраняйте состояние оплаты до и после переключения между приложениями:
После возврата показывайте один экран результата или проверки статуса, а не перезагруженную страницу с «потерянным» заказом.
Сведите все ответы провайдера к нескольким понятным состояниям и всегда давайте следующий шаг:
Используйте тексты, которые объясняют что будет дальше и снимают страх двойной оплаты:
Избегайте абстрактного «Продолжить» — на мобайле это путает.
Начните с 6–8 событий, чтобы видеть, где именно люди пропадают:
payment_viewmethod_selected (upi_intent/upi_collect/card/netbanking)upi_startapp_switch_out и Проверьте чекаут на реальном телефоне (и в плохой сети) и убедитесь, что:
Если каждый «плохой» сценарий заканчивается понятным статусом — вы близки к хорошей конверсии.
Главное — не оставлять человека на бесконечном спиннере.
app_switch_inpayment_success / payment_failed / payment_pendingК ошибкам добавляйте короткие метки причины (например, user_cancel, provider_timeout, bank_error), иначе все будет выглядеть как одна и та же «ошибка оплаты».