Можно ли полагаться на Paypal IPN исключительно для записи покупок?

Важно сделать двухстороннюю проверку, как у вас.

Вы сохраняете информацию о заказе (общая сумма, количество) до того, как пользователь покинет вашу систему в PayPal. Когда ipn возвращается, вы подтверждаете запрос (это должен быть IP-адрес PayPal или что-то еще), вы подтверждаете, что это успешная транзакция, затем ваш шаг 2 выходит на сцену. Вы проверяете, совпадает ли общая сумма, возвращенная с PayPal ipn, с общей суммой, которая была сохранена до того, как пользователь ушел (Paypal иногда может возвращать частичные платежи, пользователь может получить данные публикации и сделать свою собственную публикацию из измененного html с более низким total задавать). Шаг 2 также должен хранить user_id покупателя, поэтому вы также должны сравнить его.

вот пример слоя (без языка программирования, просто фиктивный код):

if request comes from paypal:
    #   query the order
    if order.total == request.total && order.user_id == request.custom:
        payment may come in...

Как разработчик и администратор системы, обработавшей более 600 000 платежей PayPal за последние три года, полагаясь исключительно на IPN, можно избежать некоторых ошибок.

Реальные данные:

        Total transactions   No IPN    Invalid IPN  Duplicate IPN
year 1      170,000 +          2           101           0
year 2      205,000 +         54            15           3
year 3      230,000 +         20            24          13

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

Наиболее распространенными «недействительными» IPN являются страница с ошибкой HTML или усеченные результаты... При желании я могу предоставить образцы.

Лучший выбор — это комбинация IPN и PDT (с данными вашей «корзины», хранящимися в вашей БД, как и вы). Либо процессы IPN, либо процессы PDT могут создать транзакцию (и удалить запись данных «корзина» в БД). Второй прибывший процесс не будет иметь записи «корзины», из которой можно записать транзакцию.

ПРИМЕЧАНИЕ. - как вы отметили в своем окончательном решении по использованию настраиваемого поля - имейте в виду, что для настраиваемого поля существует ограничение по длине, и оно может быть усечено при возврате вам.

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

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

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

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