Таким образом, у меня есть многостраничная система проверки, которая полагается на сеансы для хранения содержимого корзины покупок. Я также использую стороннюю систему для обработки кредитных карт, на которой размещена фактическая страница оплаты на своих серверах. Мне просто нужно отправить сообщение на страницу итоговой суммы.
Проблема, которую я предвижу, – это то, что если кто-то нажимает, чтобы перейти на страницу оплаты, а затем по какой-то законной или подозрительной причине изменит содержимое корзины покупок на другой вкладке. Я изначально планировал, что, когда размещенная страница оплаты переадресовывается обратно на мою страницу квитанции, я затем вставлю заказ в мою базу данных. Но, если сеанс будет изменен в этот момент, порядок будет отличаться от общей стоимости.
Каким будет решение этой проблемы. Я вижу, что это проблема для всех систем тележек, поэтому мне интересно, как они это делают.
Может быть, когда пользователь нажимает кнопку, чтобы перейти на размещенную страницу оплаты, я могу сделать временную запись заказа в таблице temp_order в базе данных, а затем, когда будет проходить платеж, я могу перенести эту запись временного списка в постоянную таблицу записей? Таким образом, я не вставляю запись из информации о сеансе, которая изменилась. Но если мне нужно отправить POST на гостевую страницу оплаты, где у меня есть возможность сохранить корзину покупок в таблице temp?
Кроме того, идентификатор temp order должен быть уникальным как для временных, так и для постоянных таблиц, так как я не хочу дублирования.
Наконец, мне нужно часто очищать таблицу временного порядка, поскольку они являются только временными записями. Некоторые могут не пройти, так как пользователь может изменить свое мнение на странице размещенной оплаты.
Я очень смущен, что я должен делать!
Я не вижу необходимости создавать отдельную таблицу. Просто добавьте один столбец в существующую таблицу, скажем, payment_in_progress и проанализируйте ее, когда клиент payment_in_progress изменения в корзину.
Требование об отказе от необработанных устаревших заказов остается
Когда платежный шлюз возвращает только сумму, полученную против корзины покупок, и если полученная сумма меньше итоговой суммы, верните ее на страницу оплаты, указав остаточный остаток, оставленный для оплаты.
Если платежная система не вернет управление вашему веб-сайту до окончательной обработки заказа, например, как PayPal Express Checkout, нет способа контролировать процесс оформления заказа. Системы одностороннего контроля действительно должны быть односторонними. Последующее управление выполняется вручную (посредством квитанции об оплате) или обрабатывается уведомлениями сервера на сервер.
Проводка непосредственно на сайт оплаты не даст вам никакого контроля после отправки на другой сайт. Вероятно, лучшим сценарием является то, что вы отправляете заказ на свой веб-сайт в качестве заказа UNPAID в свою базу данных, а затем предоставляете страницу с надписью «Вы почти закончили. Продолжайте платить». – В этот момент вы также должны были опорожнить корзину покупателя, чтобы они ничего не могли изменить о процессе (который уже находится в вашей БД). Когда платежная система перенаправляется на ваш сайт, вы просто будете искать неоплаченный заказ и отметьте его оплаченным. Также было бы неплохо проверить сумму платежа, на случай, если пользователь изменит данные POST, пытаясь заплатить меньше.
РЕДАКТИРОВАТЬ:
Возможно, вам действительно понадобится решение для платежных шлюзов, которое даст вам больше контроля над процессом оформления заказа. Ваши проблемы реальны, но они обычно не рассматриваются адекватно с использованием потоков платежей, которые отправляют пользователя прямо из вашего сайта без предварительной настройки сервера транзакций.