Как обрабатывать URL-адрес успеха в Stripe, учитывая, что запросы GET должны быть безопасными?

Когда мы делаем сеанс проверки с полосой, мы включаем URL-адрес успеха:

 session = await this.stripe.checkout.sessions.create({
payment_method_types: ['card'],
line_items: lineItems,
payment_intent_data: {
transfer_data: {
amount: 9999999,
destination: someaccountId,
},
},
success_url: `http://localhost:4000/api/checkout/success?true&session_id={CHECKOUT_SESSION_ID}&alias_id=${aliasId}`, 
cancel_url: `http://localhost:4000/api/checkout/canceled?session_id={CHECKOUT_SESSION_ID}`,
});

URL-адрес успеха — это место, куда Stripe отправляет пользователя после успешной оплаты. Это запрос GET, так как Stripe перенаправляет пользователя. Многим приложениям, использующим полосу, потребуется выполнить действия после успешной проверки — отправить квитанцию ​​по электронной почте, уведомления, отправить платный контент, обновить порядок в базе данных и т. д. Но рекомендуется не выполнять эти действия в запросах GET, поскольку запросы GET должны быть идемпотентным и безопасно.

Например, ссылка на отмену подписки в электронном письме не должна отменять подписку пользователя, вместо этого правильный подход к ссылкам отписки состоит в том, чтобы вести на страницу, где пользователь может нажать кнопку, чтобы отписаться (где нажатие кнопки вызывает запрос POST). источник Это связано с тем, что многие, многие, многие инструменты, утилиты, поисковые роботы и прочие штуковины предполагают, что GET никогда не будет деструктивным действием (правильно, поскольку оно определено таким образом). Если вы сейчас нарушите свое приложение, нарушив эту спецификацию, вы сохраните обе части своего приложения. источник

Итак, мне было интересно, как правильно обрабатывать URL-адрес успеха полосы? Если мы последуем предложенному выше совету, то URL-адрес успеха будет ссылаться на страницу, где пользователь нажимает кнопку, которая обновляет заказ, отправляет квитанцию ​​​​по электронной почте и т. Д. Но тогда мы полагаемся на то, что клиент завершит заказ, который уже был оплачен. за. Если они не нажмут эту кнопку, важные действия не будут выполнены. Каков правильный способ сделать это? Или предложение не менять базу данных по GET-запросу по какой-то причине не относится к такого рода действиям?


person Dashiell Rose Bark-Huss    schedule 16.04.2021    source источник


Ответы (1)


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

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

Для этого у вас также должен быть веб-хук, который будет получать POST-запрос. https://stripe.com/docs/payments/checkout/fulfill-orders#handle-the---event

person floatingLomas    schedule 16.04.2021
comment
Спасибо. В ответ на «Для инструментов, утилит, поисковых роботов и других штуковин попасть по вашему URL-адресу с действительным идентификатором сеанса проверки было бы почти невозможно» - Разве параметр идентификатора проверки не жестко закодирован в URL-адресе успеха, поэтому ссылка просканирована будет отправлен с правильным идентификатором? Или, может быть, это не имеет значения, потому что в моем коде есть возможность проверить, действительно ли был обработан платеж для этого идентификатора, поэтому все в порядке? - person Dashiell Rose Bark-Huss; 16.04.2021
comment
Нет, вы используете шаблон {CHECKOUT_SESSION_ID} в URL-адресе перенаправления, и Stripe заменяет его идентификатором сеанса оформления заказа для этого сеанса при перенаправлении. Поисковый робот не сможет получить это перенаправление, не завершив процесс оформления заказа. - person floatingLomas; 19.04.2021