Блог

Я создаю приложение для продажи одного товара (т.Е. Каждый вид товаров, перечисленных на моей платформе, содержит только один товар).).

1. (эта часть была выполнена и не изменится) Я создал внутренний сервер с Rest API POST -D {"buyer_email": "abc@example.com"} url/items/{itemID} , назовем его transaction_call Rest API, который гарантирует, что после успешного завершения операции POST его контактная информация будет записана в мой серверный сервер как успешный покупатель; и все остальные клиенты не смогут купить этот товар (на уровне API, transaction_call возвращает ошибку 4xx) поскольку моя платформа может продавать только один товар для этого продукта;
2. (это шаг, о котором мой текущий вопрос) Я пытаюсь использовать Stripe в качестве своей платежной системы на этой платформе.

Я действительно хочу максимально просто интегрироваться с Stripe (насколько я понимаю, Stripe Checkout — это самый простой / готовый способ осуществления оплаты). Однако я не уверен, сможет ли Stripe Checkout правильно реализовать вышеуказанную функциональность. Поскольку проблема состоит из двух этапов, вот потенциальная проблема, с которой я могу столкнуться:

• Допустим, два клиента A B попадают на мою платформу в 10:00 утра, оба они начинают процесс покупки продукта, Item_a
• Если моя система сначала взаимодействует / вызывает проверку Stripe в качестве первого шага, а затем вызывает transaction_call , здесь может быть проблема:
  • A вызов Stripe поступает на сервер Stripe в 10: 00: 01, а вызов A для покупки попадает на мой сервер в 10: 00: 02;
  • B вызов Stripe поступает на сервер Stripe в 10: 00: 01, а вызов A для покупки попадает на мой сервер в 10: 00: 03;
  • таким образом, мы уже взимали B плату, но он действительно не получил товар
• Если моя система вызывает transaction_call первую, и только в случае transaction call успеха она взаимодействует / вызывает проверку Stripe, тогда
  • A transaction_call успешно работает в 10:00: 01, но он по какой-то причине решил не платить (не нажимать кнопку подтверждения в пользовательском интерфейсе Stripe Checkout)
  • Таким образом, моя система не может продать товар другим покупателям.

Мой вопрос заключается в том, является ли приведенный выше процесс рассуждения правильным, и могу ли я каким-то образом использовать Stripe Checkout для достижения того, что я делаю.

Возможно, я реализовал функциональность оплаты с использованием Stripe Intent API для создания оплаты на основе рабочего процесса, что, я полагаю, будет намного сложнее, если способ проверки Stripe (простой способ) действительно невозможен.

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

Для вашего первого сценария простым решением является вызов API Stripe на вашем сервере только после получения transaction_call . Например, вы создадите сеанс проверки только после того, как ваша система определит, что товар все еще доступен. Затем вы «заблокируете» товар, чтобы при B попытке покупки вы могли немедленно вернуть ошибку вместо создания платежа через API Stripe. Логика в отношении того, с кого взимать плату (в основном, кто первым инициировал процесс проверки) в случае ничьей, должна быть реализована на вашей transaction_call стороне, а не на стороне Stripe.

Второй сценарий немного сложнее, поскольку сеансы проверки не могут быть отменены после их создания. Они автоматически отменяют себя через 24 часа, если платеж не произведен, но я сомневаюсь, что вам захочется B ждать так долго, если A вы откажетесь от потока платежей.

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

Ваш поток для сценария 2 может быть:

1. A запускает процесс проверки, создает PaymentIntent на серверной части, «блокирует» элемент и запускает таймер
2. Таймер (который вы в идеале показываете своему пользователю) истекает через N минут, если A не оплачивается
3. Отмените PaymentIntent на вашем сервере и снимите блокировку
4. B теперь можно попытаться оплатить товар, после перезапуска процесса