Rails - создать отдельную таблицу или обойти все проверки моделей?

Question

Я сейчас использую wepay с рельсами.Не беспокойтесь, это сообщение не о wepay.

1. Поэтому, когда клиент хочет купить что-то с моего сайта, он / она будет перенаправлен на wepay.
2. Затем после оплатына wepay wepay перенаправляет пользователя на / покупок / получено
3. Через X промежуток времени Wepay также отправит ответный звонок / покупкам / обратному вызову, чтобы сообщить мне, что платеж получен (обработка кредитной картой)медленно)

Итак, мой первоначальный план выглядит следующим образом:

1. Для модели Закупки, введите поле wepay_id и wepay_confirmed.
2. Когда пользователь размещает заказ на wepay, перенаправление на / puchases / полученный создаст экземпляр покупки и сохранится в моем БД
3. Когда вызывается обратный вызов, ищем wepay_id и затем устанавливаемwepay_confirmed для истинного.

Однако, как я обнаружил, количество времени X может быть настолько быстрым, что / покупок / обратный вызов вызывается до того, как / покупок / получено может создать объект.

Так что теперь у меня есть два варианта:

1. Разрешить / покупкам / обратному вызову для создания пустого экземпляра покупки только с идентификатором и подтверждено = true.Делая это, я понял, что больше не могу проверять свою модель традиционным способом.Это действительно меня беспокоит.
2. Создайте отдельную таблицу с именем Wepay_Confirmed.Когда бы ни вызывался обратный вызов, создайте запись в wepay_confirmed.Сопоставьте наличие (checkout_id) в этой таблице с атрибутом Purchase.confirmed.

Я думаю о том, чтобы сделать 2. Как я могу это сделать?Нужно ли создавать каркас для конкретной модели для сопоставления с Wepay_Confirmed?

Если у вас есть другие предложения, пожалуйста, ответьте

Answer 1

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

Простонаписал разработчикам на WePay и получил ответ:

Привет, Девин,

У нас есть автоматические попытки IPN.Повторные попытки происходят через 5 минут после первой попытки, если повторная попытка не работает, мы пытаемся через 15 минут, а затем через час.Однако сейчас они только на пустых 404 ответах.

Лучшее решение - просто игнорировать IPN, если у него нет записи в его базе данных.Наши IPN-адреса только сообщают приложению, что нужно искать детали оформления заказа с помощью вызова / checkout.У них нет никаких деталей оформления заказа.Так как он должен в любом случае искать статус / checkout, когда он создает объект checkout на своем конце, ему не нужен IPN, чтобы сказать ему, чтобы искать статус в этом случае.

Если это не 'он не может работать на него, он также может написать мне на api@wepay.com, и мы сможем найти решение.

Андрей

Похоже, вы можете изменитьпоток вашего приложения, чтобы игнорировать IPN без записи и проверить вручную, или вы можете ответить 404, и они будут повторять через указанные интервалы.

Answer 2

Я создал камень под названием wepay-rails , который обрабатывает все это для вас.Под капотом создается запись (WepayCheckoutRecord) перед отправкой плательщика в wepay.Он имеет встроенный прослушиватель IPN, который обрабатывает обновление этой записи.В моем личном приложении rails я использую конечный автомат в модели WepayCheckoutRecord для отслеживания изменений в состоянии и выполняю «дела» по мере изменения состояния в этой записи.

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

Адам - ​​

Answer 3

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

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

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

Answer 4

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