Мы разрабатываем приложение для электронной коммерции, использующее Android в качестве внешнего интерфейса и Spring-Boot в качестве внутреннего (с использованием REST API). Для большинства платежных шлюзов, с которыми мы играли (paytm, cashfree и т. Д.), Поток выполнения выглядит примерно так.
1) После выбора заказа приложение для Android запрашивает контрольную сумму и orderid с торгового сервера.
2) Используя контрольную сумму и идентификатор заказа, приложение для Android вызывает API-интерфейс шлюза платежей для выполнения транзакции и предоставляет обратный вызов (названный A) шлюзу платежей.
3) Платежный шлюз при успешной транзакции вызывает обратный вызов A и возвращает в наше приложение для Android, предоставляя ему аргументы, такие как идентификатор заказа, идентификатор транзакции, дата и т. Д.
4) Наше приложение для Android затем отправляет HTTP-запрос HTTP POST REST на наш торговый сервер для хранения всей информации, предоставленной платежными шлюзами.
Мой вопрос заключается в том, каким должен быть дизайн MVC, если шаг 3) успешно выполнен, но каким-то образом шаг 4) завершается неудачей, возможно, из-за некоторой проблемы с подключением к торговому серверу.
Вариант 1) Сохраните эти возвращенные данные с платежного шлюза на самом устройстве и продолжайте опросить торговый сервер, пока данные не будут сохранены в бэкэнде.
Вариант 2) Когда приложение для Android запрашивает у продавца-продавца контрольную сумму и идентификатор заказа, сервер-продавец возвращает контрольную сумму и идентификатор заказа и ожидает некоторый определенный промежуток времени, а после истечения этого периода он напрямую связывается с платежный шлюз и проверьте статус транзакции, используя сгенерированный идентификатор заказа.
Вариант 2) нарушает ли какой-либо стандарт RESTful? Есть ли другой лучший дизайн?