Loading…
Stripe
Global payments and financial infrastructure platform building sophisticated technology for online commerce
- 107 posts summarised
- latest
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
From their blog
Latest articles
Advanced error handling patterns for Stripe enterprise developers
The post presents advanced error-handling patterns for Stripe integrations that face high request volumes, temporary API slowdowns, connectivity problems, and webhook delivery failures. It uses Stripe Workbench to inspect account-level API activity, traffic spikes, error rates, API versions, and webhook activity; one example links a 429 response to a scheduled job that created usage records across thousands of accounts simultaneously. The implementation combines request spacing with Limiter, a p-queue concurrency cap of five, and a token bucket configured for 100 tokens per 60 seconds. Stripe’s stated limits are 100 read and 100 write operations per second in live mode and 25 of each in test mode, with stricter limits for some resources. The reported before-and-after results show the combined controls processing high API-call volume within those limits, reducing errors and producing more predictable interaction.
Simple error handling strategies with Stripe Workbench
Stripe Workbench addresses the difficulty of finding and understanding errors produced by Stripe API invocations. It gives developers a view of recent errors, groups repeated failures, shows their frequency, and links summaries to request logs and actionable resolution guidance. The article describes Stripe error categories such as StripeCardError, StripeInvalidRequestError, and StripeConnectionError, then demonstrates Node.js try/catch handling that branches on the error type. It also covers webhook responses for payment_intent.payment_failed events, including retrieving event.data.object.last_payment_error, and explains how objects such as PaymentIntents, Setup Intents, Invoices, Setup Attempts, Payouts, and Refunds retain failure information for later inspection. Combined, these mechanisms support targeted responses, troubleshooting through detailed request and response data, and more reliable Stripe integrations.
Stripe Developer Digest (August 2024): Workbench is now available to everyone
Stripe’s August 2024 developer update announces that Workbench is available to everyone across every Dashboard surface, addressing developers’ request for in-context guidance and debugging tools during API integration work. Workbench is a developer home in the Dashboard that provides an at-a-glance view of integration behavior, lets users inspect API and event history, prototype integrations, and receive critical account alerts. As developers build, it highlights errors, helps resolve them, and recommends ways to improve integration efficiency; it can be opened with a single keystroke. The update also places Sandboxes and Event Destinations in public beta, expands Tap to Pay on iPhone with Stripe to seven countries, and notes community resources for Stripe Tax, the Stripe CLI, Payment Links, and related integrations.
Bringing your Stripe objects to life with Workbench
The post demonstrates how Stripe Workbench’s Inspector can be used to examine a PaymentIntent throughout its lifecycle and diagnose payment workflow issues. It maps states including requires_payment_method, processing, requires_action, succeeded, and canceled, showing how the status property changes as inputs and decisions move the object through a state machine. The walkthrough creates and confirms test PaymentIntents with Stripe Shell commands, including a 3DS-required card that produces a requires_action state and a use_stripe_sdk next_action. It also describes reacting to state changes through webhook endpoints or Amazon EventBridge, using the Inspector to identify friction such as PaymentIntents stalled at requires_action and to debug abandoned payments.
Debugging your Stripe Invoicing integration with Workbench
The post demonstrates how to debug and fix Stripe Invoicing integration errors with Workbench, a context-aware tool available throughout the Stripe Dashboard. It uses the Overview and Errors tabs to locate a recent parameter_missing error, then examines the failed Invoice create request and identifies the missing Customer object that prevented invoice creation. The Shell and API Explorer let developers list customers, supply a Customer ID, construct and run the corrected create command, and generate an SDK request from the configured fields. Workbench’s Inspector then exposes the invoice’s JSON data map, logs, and lifecycle events; the example confirms successful payment for a zero-dollar invoice and explains that non-zero charges require Invoice Items tied to products and prices.
Peeking under the hood of Stripe Invoicing
Stripe Invoicing’s no-code workflow hides the API calls and invoice state transitions that developers may need to inspect when debugging payment failures. Using Stripe Workbench’s Inspector, Logs, and Events tabs, the walkthrough maps object hierarchies, requests, event payloads, and previous_attributes across an invoice lifecycle. Creating an invoice in the Dashboard produces a draft Invoice, a separate Invoice Item, an automatically generated Invoice Line Item, and related creation or update events. Sending it creates a Payment Intent and finalizes the invoice from draft to open; charging captures the Payment Intent, creates a Charge, and changes the invoice to paid. Draft invoices can be deleted, while open invoices can be voided, preserving the record and canceling the Payment Intent, and the same Workbench method can be applied to other Stripe API areas.
Observing immediate versus delayed payments with Stripe Workbench
Stripe payment methods differ in how quickly they confirm attempted payments, with cards reporting status immediately and bank debits, bank transfers, and cash-based vouchers requiring additional processing time. The post uses Stripe Workbench and its in-browser CLI shell to create Checkout sessions in test mode, submit card and ACH Direct Debit payments, and inspect emitted events. For cards, charge.succeeded and payment_intent.succeeded signal successful payment, while integration code must inspect checkout.session.completed payment_status rather than confuse it with the session status. With delayed methods, checkout.session.completed can show unpaid before checkout.session.async_payment_succeeded or checkout.session.async_payment_failed arrives; the former changes payment_status to paid, and production processing can take days.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.