Payment systems integration: YooKassa, Stripe, PayPal, Apple Pay, Google Pay

A store dropped conversion by 12% after a redesign. The checkout page — new, beautiful. But errors started pouring into Sentry: Payment method not available for this currency, 3DS2 challenge flow failed, webhook signature verification failed. Payment integration is not "plug in the SDK and forget." It's a constantly living part of the system with updating bank requirements, changes in SCA (Strong Customer Authentication) in Europe, and new requirements from Russia's tax authority.

Payment ecosystem: how providers differ

YooKassa (formerly Yandex.Kassa) — main choice for the Russian market. Supports cards, SBP (Fast Payment System), YooMoney, cash on delivery, installments (through BNPL partners). Important: YooKassa requires fiscalization — integration with law 54-FZ is mandatory, receipts are sent to OFD. Webhooks arrive at the specified endpoint, signature verified via HMAC-SHA256 with a secret key.

Stripe — choice for international projects and SaaS. Payment Intents API, 3DS2 support, SCA compliance for European cards. Stripe Elements or Payment Element for custom UI without passing card data to your server (PCI DSS simplified mode). Webhooks via Stripe CLI for local development — standard.

PayPal — still relevant for B2C with international audience, especially USA and Western Europe. PayPal Checkout v2 (Orders API) — modern version, old Express Checkout is outdated. Feature: PayPal IPN (Instant Payment Notification) — legacy, new path via Webhooks REST API.

Apple Pay / Google Pay — not separate processors, but ways to initiate payment. Apple Pay works via Payment Request API or through specific JS SDK, requires domain verification (file apple-developer-merchantid-domain-association in /.well-known/). Google Pay — via Google Pay API, usually on top of Stripe or another processor.

Where the real complexities hide

Connecting test mode — one hour of work. Handling all scenarios correctly — several weeks.

Webhook reliability. A webhook may not arrive — server was unavailable, timeout, temporary network error. Provider retries (Stripe — up to 3 days with exponential backoff, YooKassa — its own logic). Your handler must be idempotent: if payment.succeeded arrives twice with the same payment_id, the order should update only once. Implemented through storing processed event IDs.

3DS2 and redirect flow. When paying with 3DS2 card, user goes to bank's page, completes verification, returns via return_url. During this time session could expire, cart cleared, URL with parameters lost. Payment status must be checked not only by redirect parameters, but also via direct API request to provider when user returns.

Partial refunds and receipts. If customer returns part of goods — need correction receipt (for tax authority) and partial refund in YooKassa. Stripe supports partial_refund natively. In both cases, synchronization logic between payment system, database, and warehouse is needed.

Currency limitations. YooKassa works only with rubles. Stripe works with 135+ currencies, but for currency conversion in different countries you need currency in Payment Intent. If customer from RF pays in euros through Stripe — they see conversion from their bank, not from you.

How we build integrations

Architecture. Never store card data on your server — only tokens from provider. Payment flow: creating Order in our DB → creating Payment Intent on provider side → redirect/widget → webhook confirms → updating Order status. Source of truth — status in payment system, not in our DB.

For Laravel projects we use official SDK: stripe/stripe-php, yookassa/yookassa-sdk-php. Webhook handler — separate controller with VerifyCsrfToken exception for webhook URL, signature verification in first line, Queue job for business logic (to not hold connection).

For Next.js / React — Stripe Elements integrated via @stripe/stripe-js and @stripe/react-stripe-js. PaymentElement handles all payment methods automatically, including Apple/Google Pay, without custom code for each.

Testing. Stripe CLI (stripe listen --forward-to localhost:8000/webhook) for local webhooks. Test cards for all scenarios: successful payment, decline, 3DS required, insufficient funds. Cypress/Playwright test for full checkout flow — mandatory in CI.

Process and timelines

Requirements audit → provider selection → payment flow design → backend integration → frontend checkout → testing all scenarios (success, failure, 3DS, refunds, webhooks) → deployment → monitoring first transactions.

Cost calculated individually.