Я создаю простую транзакцию «купить сейчас» с веб-сайта с этими основными шагами:
На данный момент я сохраняю запись базы данных на шаге 2, что потенциально означает, что будет количество записей, в которых не будет получен платеж, поскольку люди решают не продолжать свою покупку в конце концов. Эти записи не имеют реального использования, так как я буду использовать Google Analytics для отслеживания того, насколько успешным является поток проверки.
Я использую IPN Paypal для проверки подлинности платежей и протоколирования их с записями, вставленными на шаге 2, однако я мог бы реально полагаться исключительно на данные из транзакций IPN для заполнения базы данных в первую очередь, тем самым удаляя необходимо сохранить их на шаге 2 и выполнить очистку базы данных, чтобы удалить транзакции, которые никогда не выполнялись?
Я лично не вижу причин, почему я этого не сделаю – IPN содержит все данные, которые мне нужны для оплаты, и, возможно, более того, и Paypal будет повторно отправлять IPN в течение нескольких дней, если они не пройдут в первый раз из-за сбоя сервера, но я пропускаю что-нибудь еще важное?
Очевидно, что соображение номер один заключается в том, что никакие транзакции не теряются или не регистрируются, чтобы не возникало несчастье клиента!
Важно сделать проверку на 2 пути, как и у вас.
Вы сохраняете информацию о заказе (общее количество, количество) до того, как пользователь покинет вашу систему в направлении paypal. Когда ipn вернется, вы проверяете запрос (он должен быть от PayPal IP или что-то еще), вы подтверждаете, что это успешная транзакция, тогда ваш шаг 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, позволит некоторым ошибкам проскальзывать через трещины.
Реальные данные:
Всего транзакций Нет IPN Недействительный IPN Дубликат IPN
год 1 170 000 + 2 101 0
год 2 205 000 + 54 15 3
год 3 230 000 + 20 24 13
К счастью, наша система структурирована с PDT (Transfer Data Transfer) в качестве «резервной копии», поэтому мы не потеряли никаких данных транзакций или не получили недовольства клиентов. Примечание: PDT нельзя полагаться исключительно исключительно на самом деле – в начале этого года была серьезная проблема с надежностью возврата PDT.
Наиболее распространенными «неверными» отзывами IPN являются страница ошибки HTML или усеченные результаты … Я могу предоставить образцы, если это необходимо.
Лучший выбор – это сочетание как IPN, так и PDT (с вашими данными тележки, хранящимися в вашей БД, как и вы). Либо процессы IPN, либо процесс PDT могут создать транзакцию (и удалить запись данных «cart» в БД). Второй процесс, который должен прибыть, не будет иметь запись «корзины», из которой можно записать транзакцию.
ПРИМЕЧАНИЕ. – как вы отметили в своем окончательном решении использовать настраиваемое поле – имейте в виду, что существует ограничение длины для настраиваемого поля, и оно может быть усечено при возврате вам.
Я не полагался исключительно на IPN для этого, но PayPal будет ломать неудачи, чтобы связаться с вашим сервером, если он терпит неудачу, и он должен повторить попытку позже, хотя у меня были только неудачи в разработке и никогда не проверялись повторные попытки. Я просто доверяю им это.
Для типичного сайта электронной коммерции, да, вы можете – он достаточно надежный. Если ядерные реакторы растают, и люди умрут, то нет, вы не сможете – я видел проблемы с ним, но очень редко.
Я разработал несколько сайтов электронной коммерции, и на практике вы всегда хотите записать, что можете, в случае каких-либо «аварий». Вы владеете данными, вероятно, более информативными.
Как вы сказали, да, вы можете это сделать, но я бы предположил, что это не очень хорошая идея.