Stripe Integration: Payments, Subscriptions, Webhooks
Payment gateway is a critical conversion point. An error at checkout means losing a customer. Stripe solves this: minimal friction for users, automatic 3D Secure handling, support for Apple Pay and Google Pay. Stripe supports over 135 currencies and dozens of payment methods, including SEPA, iDEAL, and Klarna. With a unified API, adapting to local methods takes half the time compared to competitors. We have been using Stripe in commercial projects for over five years, integrated it into 50+ projects, and guarantee stable integration with any stack—from Laravel to React.
A common pain point is incorrect webhook handling, causing orders not to be marked as paid. We break down how to avoid this and offer a turnkey solution. Reducing payment declines by 40% is a real result after configuring Stripe Radar and fraud monitoring rules.
Why Stripe is Better Than Alternatives
Stripe outperforms PayPal and Adyen in UI customization flexibility and implementation speed. Unlike PayPal, Stripe gives full control over the checkout flow via Elements and Payment Intents. Adapting local methods (SEPA, iDEAL) is twice as fast as competitors thanks to a unified API. The single Payment Intents interface simplifies PSD2 and SCA compliance.
How Stripe Protects Against Fraud
Stripe uses machine learning to analyze transactions in real time. Radar automatically blocks suspicious operations and reduces chargebacks. You can create custom rules: for example, reject orders from anonymous IPs or require 3D Secure for amounts over $500. In our projects, we configure Radar together with the charge.dispute.created webhook for prompt dispute response.
Why Choose Custom Integration via Payment Intents
Checkout Session lets you launch in a day but lacks flexibility for subscriptions and complex discount logic. Payment Intents gives full UI control via Stripe Elements: you can embed the payment form into your design, save cards for repeat purchases, and manage multi-currency. In the long run, custom integration saves up to 25% on fees by optimizing payment routing.
How We Integrate Stripe: Workflow
-
Analysis — we study your business scenario: one-time payments, subscriptions, multi-currency, UI requirements.
-
Design — we choose the integration method: Payment Intents (custom UI with Stripe Elements) or Checkout Session (ready-made page).
-
Implementation — we write code on Laravel (PHP 8.3+) and React/Next.js with TypeScript. We use the official SDKs
stripe/stripe-php and @stripe/react-stripe-js.
-
Testing — we run all cases: success, failure, 3D Secure, refund, limit exceeded, cancellation.
-
Deployment — we set up webhooks with signature verification, monitoring, and error logging.
Timeline: 3 to 7 business days. We'll assess your project in one day—get in touch. Receive a consultation on Stripe integration—we'll evaluate your project in one day.
What's Included in the Integration
- API documentation with request examples.
- Webhook handler with signature verification.
- Test environment with Stripe test cards.
- Team training (one hour).
- Two weeks of support after launch.
Comparison of Integration Methods
| Criteria |
Payment Intents |
Checkout Session |
| UI customization |
Full (Stripe Elements) |
Limited (ready-made page) |
| Subscriptions |
Supported (via Product/Price) |
Only via Customer Portal |
| 3D Secure |
Automatic |
Automatic |
| Implementation time |
3-5 days |
1-2 days |
| Recommended cost |
Higher (custom development) |
Lower (ready-made page) |
Typical Errors and Their Solutions
| Problem |
Solution |
| Incorrect webhook signature |
Verify the Stripe-Signature header using the library |
| Duplicate payments |
Use idempotency with the idempotency_key parameter |
| Session loss |
Save client_secret on the client and restore via retrieve |
How to Set Up Webhook Handling
For local development, use Stripe CLI: stripe listen --forward-to localhost:8000/webhook/stripe. On the server, specify the URL in the Dashboard. The handler must return 200 OK and verify the signature. Example code:
public function handleWebhook(Request $request): Response
{
$payload = $request->getContent();
$sigHeader = $request->header('Stripe-Signature');
try {
$event = \Stripe\Webhook::constructEvent(
$payload, $sigHeader, config('services.stripe.webhook_secret')
);
} catch (\Stripe\Exception\SignatureVerificationException $e) {
return response('Invalid signature', 400);
}
match ($event->type) {
'payment_intent.succeeded' => $this->handleSuccess($event->data->object),
'payment_intent.payment_failed' => $this->handleFailed($event->data->object),
default => null,
};
return response('OK', 200);
}
private function handleSuccess(\Stripe\PaymentIntent $intent): void
{
$orderId = $intent->metadata->order_id;
Order::where('id', $orderId)->update([
'status' => 'paid',
'transaction_id' => $intent->id,
]);
}
What to Do on Payment Errors
Stripe notifies via the payment_intent.payment_failed event. In the handler, log the reason (decline_code) and notify the customer. To reduce declines, enable automatic card updating and configure fraud monitoring rules.
Contact us for a project audit—we'll help choose the optimal solution. Order Stripe integration and get a stable payment gateway with a 12-month guarantee.
Payment System Integration: YooKassa, Stripe, PayPal, Apple Pay, Google Pay
Conversion dropped by 12% immediately after the redesign. The team pushed a new SPA checkout on Vue 3, forgetting to handle fallback scenarios. Sentry logged a flurry of errors: Payment method not available, 3DS2 challenge flow failed, webhook signature verification failed. Users abandoned carts at the payment method selection stage. Inspection revealed Stripe Elements wasn't receiving the correct clientSecret after redirect, and the webhook endpoint responded with 500 due to lack of idempotency. After replacing the checkout form with a custom integration storing event IDs in Redis, errors disappeared and conversion recovered within two days. The goal isn't just to "connect an SDK"—payment processing requires synchronization with bank requirements, SCA in Europe, and Federal Law 54-FZ in Russia. Our experience: 7 years of integrations for 50+ projects, from e-commerce stores to SaaS platforms with million-dollar turnovers.
What's Included in Turnkey Work
- Audit of current payment flow and requirements (currencies, fiscalization, subscriptions).
- Provider selection based on geography and business model.
- Backend integration (Laravel/Node.js/Go) with webhook handling, idempotency, and retries.
- Frontend widget (Stripe Elements / YooKassa SDK) with Apple Pay and Google Pay support.
- Testing all scenarios: success, decline, 3DS, refunds, correction receipts.
- Monitoring of first transactions and documentation.
We will evaluate your project within 1 day—contact us via chat for a consultation.
Provider Comparison: Which to Choose
| Criteria |
YooKassa |
Stripe |
PayPal |
| Currencies |
RUB only |
135+ |
25+ |
| Fiscalization 54-FZ |
Built-in |
No (needs OFD) |
No |
| Apple/Google Pay support |
Via SDK |
Via PaymentElement |
Via Braintree |
| Transaction fee |
2.5–4% |
2.9% + $0.30 |
2.99% + $0.49 |
| Recurring payments |
Via auto-payments |
Stripe Billing |
Reference Transactions |
| PCI DSS |
SAQ A (tokens) |
SAQ A (Elements) |
SAQ A (tokens) |
Stripe wins on flexibility: 135+ currencies vs. YooKassa's single currency. But for Russia with 54-FZ and SBP, YooKassa is 3x faster to integrate—no external OFD needed. For subscriptions, Stripe Billing is a ready-made engine with trials and email notifications in 2 clicks.
How to Choose the Right Provider?
Three key points. Where do your clients live? Only Russia → YooKassa; globally → Stripe. Do you need 54-FZ fiscalization? Yes → YooKassa; otherwise Stripe + cloud OFD. Do you plan subscriptions? Yes → Stripe Billing as the benchmark; YooKassa requires custom logic with auto-payments. Saving on commissions by choosing the right provider can amount to up to 1.5% of turnover. For a project with 2 million RUB per month, that's 360,000 RUB per year.
Where the Real Difficulties Lie
Setting up a test mode takes an hour. Properly handling all scenarios takes weeks.
Webhook reliability. A webhook may not arrive—server unavailable, timeout, network issues. The provider retries with exponential backoff (Stripe up to 3 days). The handler must be idempotent: if payment.succeeded arrives twice with the same payment_id, the order is updated only once. This is implemented by storing event IDs in Redis with a TTL.
3DS2 and redirect flow. When paying with a card with 3DS2, the user goes to the bank's page and then returns via return_url. During this time, the session may expire or the cart may be cleared. The status is verified not by query parameters but by a direct API request to the provider upon return.
Partial refunds and receipts. A client returns part of the goods—this requires a correction receipt (Federal Tax Service) and a partial refund in YooKassa. Stripe natively supports partial_refund. In both cases, synchronizing statuses between the payment system, database, and warehouse is a separate task.
Currency limitations. YooKassa only handles rubles. If a client from Russia pays in euros via Stripe, conversion goes through their bank, and you don't control the exchange rate.
Why Do Webhooks Require Idempotency?
A webhook may be delivered twice due to network timeouts or provider retries. Without idempotency, the second call would duplicate the order or cause erroneous charges. The solution is to store a unique event ID (e.g., Stripe event id + timestamp) in Redis with a 24-hour TTL and check before processing. If the ID already exists, return 200 without executing business logic. Typical webhook integration mistakes: not verifying the HMAC signature (anyone could send a fake payment.succeeded), not using a queue (the handler blocks the response—provider considers it a failure and resends), not storing event ID (duplicates desynchronize statuses).
How We Build the Integration
Architecture. We never store card data—only tokens from the provider. Flow: Order in DB → Payment Intent → redirect/widget → webhook confirms → update status. The source of truth is the status in the payment system.
For Laravel we use stripe/stripe-php or yookassa-sdk. Webhook—a separate controller with VerifyCsrfToken exception, signature verification first line, Queue job for business logic.
For Next.js/React—@stripe/stripe-js + @stripe/react-stripe-js. PaymentElement includes Apple/Google Pay automatically. Example:
const stripe = await stripePromise;
const { error } = await stripe.confirmPayment({
elements,
confirmParams: { return_url: 'https://example.com/order/thank-you' },
});
Testing. Stripe CLI: stripe listen --forward-to localhost:8000/webhook. Test cards for all scenarios (3DS, decline, insufficient funds). Cypress checkout flow test in CI—mandatory stability guarantee.
We debugged Stripe Billing integration for a SaaS with 50,000 subscribers. The issue was handling invoice.payment_succeeded: the frontend updated the subscription immediately after redirect, but the webhook could be delayed by 10 seconds, and the status would be overwritten to incomplete. Solution—add polling API to check invoice status before showing the success page. This reduced erroneous cancellations by 18%.
Process and Timeline
Audit → provider selection → backend → frontend → tests → deploy → monitoring.
| Scenario |
Timeline |
| Single provider (YooKassa or Stripe), basic flow |
1–2 weeks |
| Multiple payment methods + Apple/Google Pay |
2–4 weeks |
| Multi-currency + partial refunds + fiscalization |
4–8 weeks |
| SaaS subscriptions via Stripe Billing |
3–6 weeks |
Pricing is custom. Order integration and your checkout won't crash on the next update.
Links:
We guarantee: 7 years of experience, 50+ successful integrations. Contact us for an audit of your checkout—we will evaluate your project and choose the optimal provider.