Целостность данных, когда данные хранятся на нашем сайте и пользователь переходит в PayPal и обратно?

Question

Одно из недавно разработанных веб-приложений работает следующим образом:

1. Пользователь выбирает уровень подписки
2. Пользователь вводит различные пользовательские / личные данные на сайт, а также выбираетопределенные параметры
3. Пользователь подтверждает свои данные
4. Система сохраняет эти данные в массиве с установленным флагом, указывающим, что данные являются неполными
5. Пользователь направлен в PayPal для оплаты
6. PayPal делает запрос IPN, и мы получаем идентификатор строки, содержащий их информацию, и заполняем остальные поля, эффективно завершая процесс.

Теперь, очевидно, есть несколько проблемс таким подходом.

1.Эти строки создаются всякий раз, когда пользователь посещает форму и могут быстро добавить

. Я решил эту проблему, добавив столбец last_touched, который является меткой времени, и я обычно удаляю записи старше 48 часов (болеедостаточно времени для завершения транзакции PayPal).

2.Из-за вышеизложенного возможно, что пользователь мог успешно оформить заказ через PayPal, и в базе данных нет строки

Я передаю важную информацию, такую ​​как идентификатор пакета подписки, с помощью настраиваемого поля PayPalи если строка не существует, когда я выполняю свой запрос IPN, я заполняю пробелы, используя данные, предоставленные PayPal и из настраиваемого поля.

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

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

---

Я не уверен, что это лучший способ справиться с данными ситуациями или есть лучшая альтернатива (не включая PayPal Payments Pro).В какой момент потенциальные проблемы с такой системой перевесят стоимость PayPal Payments Pro?

Answer 1

Лучше всего хранить все данные учетной записи в вашей базе данных, как если бы пользователь создал учетную запись до отправки их в PayPal.

Так что храните все, включая имя пользователя, прежде чем разрешить им перейти к оформлению заказа. Это позволяет вам проверить их информацию и имя пользователя, прежде чем они перейдут в PayPal. Затем вы кешируете все это в течение 48 часов, чтобы убедиться, что они не потеряют имя пользователя при проверке. Вы также можете воспользоваться поддержкой сессий PHP для отслеживания пользователей, если они случайно вернутся на следующий день, чтобы совершить покупку. Пока они не очистили свои файлы cookie / кэш-память, а время жизни вашего сеанса не истекло на стороне сервера сеанса, они должны иметь возможность возобновить сеанс с того места, на котором они остановились, и сразу перейти к PayPal.

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

Вы также можете использовать эту систему, чтобы «проверить», если пользователь уже начал платить. Возможно, попросите их сначала ввести адрес электронной почты. Свяжите все данные с этим электронным письмом и IP-адресом пользователя ($ _SERVER ['REMOTE_ADDR']). Если у вас нет параллельного сеанса для пользователя, но он вводит адрес электронной почты уже в базе данных. Проверьте их IP (и, возможно, даже браузер, если вы хотите быть действительно анальным об этом), и если это совпадение, скажите пользователю «похоже, что вы начали проверять раньше и никогда не заканчивали. Хотите продолжить?» и пусть они подберут, где они остановились. Очевидно, что таким способом не храните конфиденциальную информацию, а только кэшируйте ее во временной таблице для PayPal, так что в лучшем случае она длится всего 2 дня.

Таким образом, пользователь может нажать «Да», и ему не нужно будет снова выбирать свою подписку и проходить весь этот выбор / выбор во второй раз. Если пользователь говорит «Нет, я бы хотел начать все сначала», просто удалите строку во временной таблице и создайте для нее новую.