Цыпленок и яйцо: сохранить модель, прежде чем перейти к платежному шлюзу?(Rails) - PullRequest
Новая
       18

Цыпленок и яйцо: сохранить модель, прежде чем перейти к платежному шлюзу?(Rails)

0 голосов
/ 16 февраля 2011

Я нахожусь в процессе интеграции оплаты Barclays ePDQ CPI в наше приложение.

Код, который я до сих пор кодировал:

1. Пользователь вводит данные 2. Модель сохраняется в сеансе (не в дБ) 3. Пользователь перенаправляется на страницу оплаты.4. Пользователь вводит платежные реквизиты.5. Сервер eDPQ выполняет обратную передачу, полученную контроллером.Это должно сохранить детали заказа и сохранить модель пользователя.6. Пользователь перенаправляется на страницу результатов по ИПЦ.

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

Однако - теперь я понимаю, что, поскольку сервер eDPQ вызывает сообщение напрямую, сеанса не будет.Можно отправить order_id на страницу оплаты, которая будет отправлена ​​обратно в качестве ссылки.Так что теперь я думаю вернуться и сохранить пользователя перед отправкой его на страницу оплаты, поэтому я отправляю ссылку в order_id.Затем это можно получить с помощью метода post_back, который найдет пользователя и завершит процесс регистрации.

Но, если они нажмут назад и попытаются повторить отправку, будут ошибки, так как пользователь уже существует.

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

Я надеюсь, что кто-то сталкивался с чем-то подобным и может дать здесь несколько советов.

Спасибо за чтение!

1 Ответ

1 голос
/ 16 февраля 2011

В общем, я думаю, что лучше сохранить полностью свою модель.Если вы хотите отслеживать прогресс, вы можете сделать это с помощью столбца прогресса.Например, в вашем заказе вы можете сделать следующее: 

class Order
  def processed?
    status == 'processed'
  end

  def entered_details?
    status == 'details entered'
  end

  def can_process?
    entered_details?
  end
end

И тогда вы можете просто обновить свой статус по мере продвижения.Например, после того, как пользователь вводит свои платежные реквизиты, вы можете изменить статус на «введенные данные», а после обработки с помощью шлюза оплаты вы можете обновить статус на «обработано».Это позволит вам принудительно применить состояние в вашей модели, не сохраняя его временно в сеансе.

Что касается кнопки «Назад», вы не можете контролировать то, что видит пользователь, когда он нажимает кнопку «Назад».Они попадают на страницу, на которой они были ранее, и ваш сервер не уведомляется об этом.Это проклятие кнопки назад.Единственный способ обойти это - убедиться, что отправка второй формы вызывает ошибку проверки или что, если она приходит из того же сеанса, она выполняет обновление, но в целом это не тот случай, который вы должны пытаться принять, поскольку онне следит за ходом вашего приложения.Вот почему многие платежные сайты часто пишут «не нажимайте кнопку возврата» при обработке платежей.Тем не менее, вы должны предоставить свою собственную кнопку возврата на странице, но вы можете настроить ее для перенаправления на страницу редактирования вместо новой страницы.

...