История одного платежа

Я как программист вообще-то не против извращений, но иногда…

Дано: магазин у которого нет доступа к бекенду, и сами товары выводятся вообще из другой ecommerce платформы. Платежная система которая не принимает Ajax запросы и с ней нет интеграции у платформы. И надо всё это связать в кучу.

Итак, покупатель нажимает оплатить в корзине и его направляет на прокси сервер (был для этого куплен домен и хостинг) с post запросом с данными корзины. Прокси форматирует это под апи платежной системы и пишет в базу, затем отправляет данные на шлюз платежной системы от которой в ответ получает url страницы оплаты, пишет этот ответ опять в базу (на случай всякий) и перенаправляет покупателя на страницу оплаты. После оплаты платежный шлюз отправляет post запрос на прокси сервер с результатом что процесс оплаты запущен и перенаправляет покупателя на страницу благодарности на прокси сервере, который делает запрос платежному шлюзу о статусе оплаты (обычно этого времени пока покупатель возвращается на прокси как раз хватает чтобы получить положительный статус оплаты) и делает запрос на апи ecommerce платформы для смены статуса оплаты. И возвращает покупателя на страницу магазина. И это не конец, мы же помним про чеки ? ))) Платформа ecommerce отправляет post запрос на прокси с информацией о том что создан новый заказ, (так как заказы можно оплачивать наличкой то это было вынесено в отдельный алгоритм) Прокси фиксирует заказ и если статус заказа стоит оплачен то отправляет запрос на ещё одно апи которое ответственно за учет и создает там чековый документ который отправляется покупателю и продавцу. Фууухх

На GitHabe это можно тоже посмотреть

Сдедующая статья
Магазин на Laravel