Stripe

Коротко: Платіжний провайдер для онлайн-платежів (оформлення замовлення, підписки, вебхуки) — відомий чітким розділенням тестового та бойового режимів.

Докладніше: У тестовому режимі весь процес оплати можна пройти технічно так само, як у бойовій роботі (з тестовими номерами кредитних карток), без повної перевірки бізнесу. Лише перехід у бойовий режим (справжні гроші) потребує підтверджень, наприклад реєстрації бізнесу/запису в торговому реєстрі.

Наш контекст: В Emzett він поки що продовжує працювати в тестовому режимі, бо бізнес ще не зареєстровано — логіка оплати лишається в коді, тож потім потрібно буде лише замінити ключі.

Подробиці

Stripe заснований у 2010 році зі спостереження братів Коллісон, що онлайн-платежі для розробників непропорційно складні — відповідність PCI, банківські підключення й перевірки на шахрайство доводилося розв’язувати наново практично кожній компанії самостійно. Основна ідея — платіжна інтеграція, що додається кількома рядками коду, а всю регуляторну й захисну складність Stripe ховає всередині. Це стало галузевим стандартом: багато SaaS-продуктів, маркетплейсів і сервісів підписок сьогодні будуються просто на Stripe замість розробки власної обробки платежів.

Stripe моделює весь платіжний процес двома будівельними блоками: Checkout (платіжна сторінка, що відповідає PCI та розміщена у Stripe, на яку ви перенаправляєте клієнта замість самостійного приймання даних картки) і вебхуки (асинхронні сповіщення, якими Stripe повідомляє вашому серверу, що платіж справді завершено). Це свідомий шаблон безпеки та надійності: перенаправлення на вашу сторінку успіху після оплати — НЕ той надійний момент, коли слід, наприклад, позначати замовлення оплаченим: клієнт може закрити вкладку до перенаправлення, відкрити сторінку успіху знову вручну, або збій браузера може повністю завадити перенаправленню. Джерело істини — лише підписана подія вебхука (checkout.session.completed), бо вона надходить прямо з серверів Stripe і доставляється незалежно від браузера клієнта.

Безпека вебхуків

Часта помилка новачків: довіряти кінцевим точкам вебхуків без перевірки. Оскільки URL вебхука має бути загальнодоступним (Stripe має викликати його ззовні), теоретично будь-хто може надіслати підроблене повідомлення checkout.session.completed і тим самим отримати «оплачене» замовлення. Тому Stripe підписує кожен запит вебхука заголовком підпису HMAC (Stripe-Signature), який потрібно перевірити на сервері вашим власним секретом вебхука, перш ніж взагалі довіряти вмісту:

const sig = request.headers.get("stripe-signature")!
const event = stripe.webhooks.constructEvent(
  rawBody, // ВАЖЛИВО: незмінене тіло запиту, а не розібраний JSON
  sig,
  process.env.STRIPE_WEBHOOK_SECRET!,
)

Акцент на «незміненому тілі» — не дрібниця: багато фреймворків за замовчуванням автоматично розбирають тіло запиту в JSON до того, як його побачить ваш код, але перевірка підпису потребує саме сирих байтів у тому вигляді, як їх підписав Stripe, інакше перевірка не проходить (класична пастка інтеграцій Stripe).

Ключі ідемпотентності та підписки

Ще один важливий будівельний блок — ключі ідемпотентності: оскільки мережеві помилки можуть призвести до того, що запит прийде двічі (клієнт надсилає його знову, бо відповідь не дійшла), кожному критичному запиту на кшталт «списати платіж» можна присвоїти унікальний ключ — за ним Stripe розпізнає дублікати й гарантує, що дію буде виконано лише один раз, скільки б разів не надійшов той самий запит.

const session = await stripe.checkout.sessions.create(
  { line_items, mode: "payment", success_url, cancel_url },
  { idempotencyKey: orderId },
)

Для повторюваних платежів Stripe пропонує власний mode: "subscription", який автоматично керує розрахунковими циклами, пропорційними змінами (proration під час зміни плану посеред циклу) та невдалими спробами платежу (dunning — автоматичні повтори, коли термін дії картки минув), замість того щоб вам самим відтворювати цю логіку.

У порівнянні з альтернативами

Порівняно з PayPal Stripe пропонує набагато детальніші API та кращу документацію для розробників, але йому бракує величезної встановленої бази користувачів PayPal (багато клієнтів більше довіряють знайомій кнопці PayPal, ніж незнайомій формі кредитної картки). Adyen орієнтований радше на великих клієнтів із дуже індивідуальними вимогами та складнішими умовами договорів, тоді як Stripe свідомо спирається на самообслуговування без переговорів про договори. Mollie і Klarna сильні в Європі з місцевими способами оплати (прямий дебет SEPA, миттєвий банківський переказ, оплата за рахунком) — Stripe тепер підтримує багато з них, але спочатку був більше зосереджений на кредитних картках.

Про перехід від тестового до бойового режиму: обидва режими мають цілком окремі ключі API, клієнтів, продукти та кінцеві точки вебхуків — «підвищити» тестові дані неможливо; перехід практично означає чистий перезапуск із бойовими ключами.

Див. також: Змінні середовища, JSON