Что делать, когда пользователь закрывает платежный браузер?

Question

В приложении Android, над которым я работаю, возникла проблема с платежами.

Когда пользователь хочет разместить заказ, мы выполняем запрос API, который возвращает URL платежа и идентификатор платежа. URL - это веб-страница, которую мы откроем для оплаты, идентификатор используется для получения статуса платежа из нашего API. Когда мы запрашиваем статус платежа у нашего API, он возвращает либо «успешно», «отменено», либо «ожидает рассмотрения». Когда платеж завершен или когда пользователь щелкнет ссылку отмены на веб-странице платежа, пользователь будет перенаправлен на URL-адрес, который обрабатывается приложением. Если пользователь перенаправлен, мы перейдем либо на страницу подтверждения заказа (если платеж был успешным), либо обратно на страницу оформления заказа (когда платеж был отменен, нажав на ссылку отмены на веб-странице). Платежная веб-страница открывается с помощью пользовательской вкладки Chrome.

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

1. Пользователь заплатил, но закрыл браузер до того, как произошло перенаправление. Запрос статуса вернется «успешно», и мы можем перейти к экрану подтверждения заказа.
2. Пользователь не заплатил, нажал кнопку отмены на странице оплаты, но закрыл браузер до того, как произошло перенаправление. Запрос статуса вернется «отменен», и мы можем отправить пользователя обратно на экран оформления заказа.
3. Пользователь заплатил, но платеж все еще обрабатывается. Пользователь закрывает браузер и возвращается в приложение. Запрос статуса вернется "в ожидании"
4. Пользователь не хочет платить и просто закрыл браузер, потому что он хочет go вернуться на страницу оформления заказа, чтобы что-то изменить в форме, запрос статуса вернется " в ожидании ", потому что API не знает, что пользователь закрыл браузер

Сценарии 1 и 2 в порядке, но 3 и 4 вызывают проблемы. Когда запрос статуса возвращает «ожидает», приложение не знает, является ли это сценарием 3 или 4. Приложение отобразит диалоговое окно в верхней части экрана оформления заказа с надписью «ожидание платежа». Проблема в том, что, когда это происходит, приложение не знает, 1) ли платеж все еще обрабатывается и когда-нибудь будет успешным в будущем или 2) никогда не будет успешным, потому что пользователь никогда не платил. Если пользователь закрывает этот диалог, все еще возможно, что платеж будет успешным, и пользователь не будет знать. У нас было много жалоб пользователей, которые закрыли этот диалог, а затем попытались сделать заказ снова, что привело к случайному двойному заказу.

Мы попробовали обходной путь, сделав диалог не подлежащим закрытию как минимум на 30 секунд, чтобы дать платежу некоторое время для обработки, но это принесет очень плохой UX пользователям, которые только что закрыли диалог, чтобы вернуться к оформлению заказа экран (сценарий 4).

Есть ли какая-либо функция Android, которая нам не хватает, которая могла бы решить проблему? Есть ли другое решение? Мы хотели бы видеть подходы к другим приложениям.

Answer 1

Что ж, решение в значительной степени зависит от поставщика платежных услуг, которым вы пользуетесь, хотя все основные из них имеют способы обработки, встроенные в их API / SDK.

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

Если у провайдера платежей нет хука для необходимых событий, я бы создал повторяющуюся работу для проверки статуса платежа от API поставщика платежа с идентификатором paymentId, предоставленным клиентом Android. Задание будет активным только во время ожидания оплаты. Когда статус изменяется, было бы неплохо иметь сокеты, реализованные как на бэкэнде, так и на клиентах, чтобы уведомлять клиента об изменениях без повторного задания на клиенте.

Если у провайдера платежей есть webhook, необходимо проверить статус платежей - используйте его вместо повторяющегося задания.

Если не указан paymentId - отследите все ожидающие платежи для конкретного пользователя.

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

Поскольку речь идет о Android, я порекомендую некоторые android техников для обработки это на Android клиентской стороне. Итак - Socket.io для сокетов, Room или какой-то реактивный sharedpref (даже android native будет работать) для хранения данных, LiveData для обновления пользовательского интерфейса.

Так я работал и буду реализовывать в будущем. Это не может быть идеальным, но хорошая идея - переместить все основные вещи, связанные с платежами, в бэкэнд.

Для таких ошибок комбинации и ошибок также может быть определен c - но каждый подход будет иметь некоторые.

Надеюсь, этот ответ вам как-то поможет.

Answer 2

Попробуйте справиться с Api, это лучшее решение для вас.

Шаг 1: Сохранить статус пользователя в вашей базе данных, когда вы получите статус платежа (успешно / отменено / ожидает рассмотрения)

Теперь, если какой-либо пользователь попытается закрыть браузер, хотя в вашей базе данных будет сохранен статус последней транзакции.

Шаг 2: Затем после попытки получить статус заказа пользователя, вызвав ваш API в onresume метод android.

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

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

Примечание: Мы делаем то же самое в CCAvenue Payment Gateway. В их платежном шлюзе мы пишем код для перенаправления URl и Cancle URL Method для сохранения статуса платежа.

Answer 3

Вот как бы я справился с этим:

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

, если у вас есть другой сценарий ios или некоторые ошибки в этом сценарии говорят мне, чтобы найти решение для него