Рабочий процесс заказа PayPal REST API: Оплата - ›Продажа -› Webhook?

Я пытаюсь интегрировать API PayPal REST в свое веб-приложение Symfony 2, но мне трудно понять, как именно выглядит весь рабочий процесс:

В документации PayPal описаны следующие шаги для принятия платежа. . Для моделирования этих шагов можно использовать PayPal Playground:

  1. Получите токен доступа
  2. Создайте объект Payment, запросив API
  3. Перенаправить пользователя на approval url, полученный в ответе Payment
  4. После того, как пользователь утвердил платеж на странице PayPal, он перенаправляется обратно на мою страницу с помощью ссылки успеха, определенной в объекте Payment. Используйте полученную информацию для выполнения платежа.
  5. Платеж завершен со статусом approved

Из документации: После оплаты < / strong> завершено, это называется продажей. Затем вы можете найти распродажу и вернуть ее.

Пока все хорошо. НО: Где в этом рабочем процессе используются / запускаются Webhooks? Я определил групповой веб-перехватчик (принимающий все возможные события) на панели инструментов разработчика PayPal.

По моим наблюдениям, моя система получает событие Webhook через 1-2 минуты (!) после, когда пользователь был перенаправлен обратно на успешную ссылку и после оплаты был выполнен (шаг 4).

Помимо этой большой задержки между выполнением платежа и получением Webhook, этот рабочий процесс означает, что я получаю Webhook только ПОСЛЕ обработки успешной ссылки. Это означает, что обработка успешной ссылки абсолютно необходима для завершения платежа. Это правильно?

Нужно ли мне использовать Webhooks?

Я уже задавал этот вопрос за несколько дней до этого, и ответ nifr вполне разумен: нельзя доверять пользователю следовать любому перенаправлению URL, но должен полагаться только на события Webhook.

Однако это противоречит наблюдениям, которые я описал ранее, поскольку я никогда не получу Webhook без обработки URL-адреса перенаправления ...

Таким образом, обработка события PAYMENT.SALE.COMPLETED webhook не имеет большого смысла, поскольку это уже должно быть сделано при обработке URL-адреса перенаправления. Верно?

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

Итак, ответ: используйте Webhooks только для получения обновлений о ранее совершенных платежах. Верно?

Итак, основные вопросы:

  1. Пятиэтапный процесс приема платежей ничего не говорит об использовании Webhooks. В этом нет большого смысла, потому что без Webhooks можно было бы пропустить события обновления и т. Д.? Итак, действительно ли возможно реализовать полный рабочий процесс оплаты без Webhooks?
  2. Если да, как в этом случае обрабатываются обновления (возврат средств, ожидание и т. Д.)?
  3. Если нет, какова правильная стратегия / время для выполнения заказа, поскольку получение и обработка веб-перехватчика занимает довольно много времени?

php paypal paypal-sandbox paypal-rest-sdk
person Andrei Herford    schedule 29.03.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я все еще новичок в мире PayPal, но несколько дней назад я интегрировал PayPal Plus REST API в онлайн-магазин и, насколько я понимаю, могу сказать, что рабочий процесс выглядит так:

  1. создать Платеж
  2. перенаправить на PayPal
  3. Плательщик может произвести оплату с помощью учетной записи PayPal ИЛИ (с помощью прямого дебетования банка или оплаты кредитной картой без учетной записи PayPal).
  4. После завершения процесса на стороне PayPal PayPal перенаправляет пользователя обратно на ваш URL-адрес успеха.
  5. до сих пор с пользователя все еще не взимается плата (у вас нет денег). В тот момент, когда вы (в своем URL-адресе успеха) делаете $payment->execute($paymentExecution,$api);, вы просите Paypal списать сумму с пользователя. НО также после этого у вас не будет денег. Paypal должен сначала обработать платеж и уведомить вас позже через WebhookEvents.

Уведомление Webhook (с этой неприятной задержкой) особенно важно, когда пользователь платит прямым дебетом или кредитной картой и т. д. Обработка таких платежей занимает несколько секунд / минут.

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

поэтому я бы рекомендовал вам обновить свою базу данных (платеж завершен) только после получения уведомлений через WebhookEvent Listener, а не в случае успеха RedirectUrl.

person Rami.Q    schedule 01.06.2016
comment
Кажется, это даже хуже. В системе интеграции клиентов RedirectURL, а также вся другая информация и учетные данные отображаются на клиенте в виде открытого текста. Это означает, что злоумышленник может пропустить захват платежа PayPal и просто вручную нажать RedirectURL. Если продавец не проверяет Webhooks, они облажались. - person Chris Nadovich; 20.11.2018
comment
@ChrisNadovich, это неправда, если вы используете PayPal SDK. Это может быть правдой, если вы выполняете платежи через кнопки формы PayPal и т. Д. С помощью PayPal SDK, вы связываетесь со стороной сервера PayPal, и клиенту ничего не видно (только URL-адрес перенаправления, но это не проблема, если вы попросите PayPal проверить этот запрос , перед обновлением вашей платежной базы данных) - person Rami.Q; 21.11.2018
comment
Да, @ Rami.Q, мне кажется, старый Classic API безопасен. Я имею в виду новый REST API, который они, кажется, продвигают в наши дни. Все примеры, которые они приводят для интеграции клиента, похоже, сохраняют все учетные данные клиента. Я даже не могу найти обсуждение в документации PayPal о том, как смягчить этот праблем. - person Chris Nadovich; 08.01.2019