Loading…
Stripe
Global payments and financial infrastructure platform building sophisticated technology for online commerce
- 109 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
Run recurring jobs on Stripe without a cron server
Stripe Workflows now supports recurring schedule triggers, enabling automated tasks like notifying teams about past-due subscriptions without external cron servers. Users set schedules in the Dashboard, and Stripe runs the workflow at each scheduled time, following the local clock and handling daylight saving time. A walkthrough lists past-due subscriptions, uses a metadata key condition to skip already-notified ones, and sends Slack notifications via the installed Slack app. The workflow handles pagination; if an action fails, the loop stops and remaining items are picked up on the next run, with details showing which step failed. This eliminates the need for a separate server, secret key storage, and daylight saving time logic, putting calendar-based operations under the finance team’s control.
Fine-tuning LLMs for risk assessment
Stripe makes thousands of near real-time risk decisions every second, balancing fraud detection against false positives that disrupt legitimate businesses. Zero-shot prompting achieved 0.487 precision, domain-guided prompting 0.706, and human reviewers 0.790 at the same recall. The team applied supervised fine-tuning (SFT) to an open-weight 4B-parameter LLM, serializing features like card payments and account activity into text records, training it on labels, and deriving a continuous fraud score from the next-token probabilities normalized over two label tokens. SFT increased average precision by approximately 24% over domain-guided prompting and 70% over zero-shot prompting, and consistently outperformed XGBoost across multiple risk tasks. Linear probing of hidden states showed that SFT made benign signals more linearly decodable, with ROC-AUC improving from 0.583 to 0.642, indicating the model better recognizes legitimate business activity and reduces false positives.
Creating a whitelabeled connected account dashboard with embedded components
This tutorial explains how to build a whitelabeled connected account dashboard using Stripe Connect embedded components, eliminating the need to manually implement pagination, permissions, and state management. The example uses FurEver, a pet grooming SaaS platform, and integrates the ConnectPayments, ConnectPayouts, and ConnectNotificationBanner components for payments, refunds, dispute management, balance and payout views, and account enablement alerts. The server-side requires creating an account session with enabled components, while the frontend initializes ConnectComponentsProvider with the fetched client secret and publishable key. Platform user roles can be enforced by setting features such as refund_management based on admin status in the account session, automatically adjusting component behavior. The dashboard’s appearance matches the platform using the appearance API with variables for colors, fonts, and locale, and it receives automatic updates for new payment methods and compliance.
Stripe’s Payment Method Factory: Orchestrating agents for repeated, custom integrations
Stripe offers over 125 different payment methods globally, each requiring integrations that previously took up to six months because teams started from scratch. They hypothesized that reusable prompts with hardening could reduce effort, and a bake-off showed vanilla Claude Code took 20 days versus 4 days with their prompts. The resulting factory has created three new payment method integrations and migrated ten existing ones to a modern stack, reducing timelines from six months to two to six weeks. The factory also uses code-based orchestration, continuous knowledge loops where agents suggest prompt improvements, and agents testing their own code against sandbox environments. The factory’s approach has since been extended to Stripe’s tax and verification teams for building their own connectors.
How Stripe is designing Checkout for AI agents
Stripe implemented WebMCP on its Checkout UIs, which processes around 0.45% of global GDP, to optimize the buying experience for AI agents. Previously, agents relied on slow browser automation, consuming an average of 1.8 million tokens and 38.83 tool calls per transaction, taking over 2.5 minutes. WebMCP exposes MCP tools from the client side, allowing agents to execute actions like get_order_summary or fill_payment_form instead of interpreting the DOM. The implementation uses progressive tool disclosure, revealing only relevant tools; in evaluations across six models, agents using WebMCP consumed 42% fewer tokens, made 38% fewer tool calls, and completed checkout 39% faster. Stripe reused existing UI state and forms via imperative and declarative APIs, avoiding a separate agent-only code path and keeping human and agent experiences aligned.
Building custom financial reconciliation workflows with Stripe
The post examines how enterprises can replace SFTP-based financial reconciliation with Stripe’s reporting APIs. Stripe’s Reports API v2 and Query Run API provide SQL-based report customization, consistent schemas, API-key permissioning, audit trails, and event-driven completion notifications instead of fixed files and polling schedules. Using fictional retailer Galtee, the examples run payout queries across multiple Stripe accounts with an Organization secret key, joining transfers with balance_transactions and using a succeeded webhook to trigger retrieval. Further queries join charges to add presentment amounts and exchange rates, then use aggregation and a common table expression to itemize IC+ fees; the conclusion is that this supports an on-demand pipeline that evolves with business requirements.
Harbor: Stripe’s AI-assisted prototyping tool
Harbor addresses a gap in Stripe’s AI-assisted workflows: designers needed dynamic information to assess stripe.com designs, but could not always justify a full engineering prototype. Built initially by one engineer in about 40 days, it lets designers describe an idea and use Stripe design systems and realistic mock data to generate shareable, browser-based prototypes without understanding code. Its agent writes a multi-file source tree, while Drydock compiles and renders React and TypeScript in the viewer’s browser; the agent can inspect pages, interact with elements, switch viewports, and iterate before publishing a single snapshot. Since May 2026, more than 3,000 Stripes have created 12,000 prototypes, and Harbor now integrates with other AI tools through MCP and Drydock’s standalone rendering contract, although live data and prototype-scoped state remain future goals.
What if Stripe could work the way your business does
Stripe’s default financial infrastructure covers common payment, subscription, invoicing, and money-movement needs, but businesses may require custom rules, data models, or operational views. Rather than placing every customization behind webhooks and a separately managed server, Stripe extensibility moves logic, data, and user interface capabilities into Stripe through Scripts, Workflows, Custom Objects, and UI extensions. Scripts handle individual decisions such as TypeScript-based proration, while Workflows orchestrate event-driven or manually initiated sequences involving Stripe APIs, third-party integrations, and custom actions. Custom Objects add typed fields, validation, and relationships for concepts such as Rocket Rides’ Vehicles and Rentals, and UI extensions expose that information and business actions in the Dashboard. In the example, an End Rental action updates status, triggers inspection, and marks a vehicle available, connecting the three dimensions without requiring a separate operational system.
AI didn't write our SDK. It changed how we built it.
Stripe's extensibility SDK was built with AI involved across prototyping, architecture, implementation, and refinement, but the main change was to the development loop rather than code-generation speed. For a custom-object design, one engineer produced a working prototype, demo, and documentation site in roughly two days instead of an estimated two to three weeks, allowing the team to evaluate boundaries and reprioritize the feature for the next major launch. The team then used reviewed, detailed specifications and persistent domain guidance to delegate bounded work, including about twenty ESLint rules covering authoring constraints such as sandbox boundaries, imports, and type safety. AI also helped keep scripts, workflows, SDK generation, runtime enforcement, tooling, documentation, examples, and tests aligned, while human judgment remained responsible for abstractions and trade-offs. The post concludes that AI's leverage came from making more artifacts concrete earlier, enabling earlier feedback and a tighter deliverable.
Building a data plane from scratch: Stripe’s own high-performance distributed proxy
Stripe replaced Envoy in its service mesh after reliability, connection-cardinality, rollout-risk, and customization problems became increasingly difficult at its scale. Mesh-proxy, a Go proxy, implements HTTP/1.1 and HTTP/2, connects directly to Stripe’s service registry, and supports retries, hedging, rate limiting, and dynamic priority-based routing. Unlike Envoy’s worker-per-core model, it uses one read and one write goroutine per connection and multiplexes requests over a shared connection, reducing connection counts from one per worker to one per host. Load tests and deployment results showed about half the CPU under high load and roughly 50% lower latency, equivalent to around 3,000 days of cumulative inter-service latency saved daily. Direct registry integration also reduced unnecessary xDS updates, while custom Ruby balancing added 15–20% headroom before bursts overwhelm machines; Stripe is now pursuing anomaly detection and smart routing.
Reading the signals: Helping your AI-built payment integration understand business intent
AI agents can quickly produce Stripe payment flows that create a PaymentIntent, render the Payment Element, and pass an end-to-end demo, yet a correct implementation can still violate the business intent behind the money. The post argues that payment expertise and business decisions are often missing from integrations built from API references, causing silent failures such as terminal declines being retried, intents stuck in requires_action, uncaptured authorizations, restricted connected accounts, and asynchronous payments being refunded. It recommends defining business intent before configuring the PaymentIntent, then writing those rules into code comments, metadata, documented requirements, or custom objects. A verifier agent can check rules on every build, either through an agent skill, automated tests, or CI, while shared ownership remains with the human who decides what correct means.
From charging a blended rate to IC++: pass network costs to your connected accounts
Platforms using blended payment rates absorb interchange variance, which can reduce margins as card mix shifts toward premium rewards, corporate, and other high-interchange cards. Network cost passthrough, also called IC++, lets eligible Connect platforms pass interchange, scheme fees, and applicable adjustments to connected accounts at cost while keeping Stripe fees and platform markup separate. Eligibility requires IC+ pricing, platform-controlled pricing, enabled transfers, an appropriate Merchant of Record fund flow, and eligible geographies; passthrough can then be enabled in the Dashboard or through the API. The rollout also requires lower application fees, new network-cost reporting, and a pilot with clear communication before broader deployment.
Agentic payments for marketplaces: How a smart fridge can shop safely
GreenMart’s smart-fridge scenario addresses how an agent can turn a detected grocery need into an authorized order without receiving unrestricted access to household card or wallet credentials. GreenMart uses Stripe Agentic Commerce Suite to expose its catalog and checkout through a hosted Agentic Commerce Protocol (ACP) endpoint, while retaining responsibility for inventory, pricing, fulfillment, and order operations. A fridge agent discovers products and creates a checkout, and a companion app evaluates the final checkout against deterministic household rules covering items, totals, delivery, substitutions, and budgets. After approval, Link can provide bounded payment authority, while direct Shared Payment Tokens (SPTs) support lower-level Stripe integrations; virtual cards are described for eligible non-Stripe merchants. The design emphasizes auditable policy decisions, explicit escalation or denial, idempotent retries, webhook reconciliation, and stopping when changes exceed the household’s authority.
Meet Stripe's Knowledge AI Platform
Stripe built Kai, a knowledge AI platform for non-engineering work that existing no-code and coding agents could not support with Stripe’s required data security and workflow specificity. It serves tasks including account research, incident triage, revenue modeling, compliance reviews, and data-warehouse queries, while adapting to different tools, data sources, outputs, and definitions of completion. Kai is organized into surface-agnostic APIs, AgentStudio for domain teams to build and govern agents, and shared execution environments with per-session Kubernetes sandboxes, multi-tenant virtual filesystems, access controls, and long-session state management. The platform connects to more than 1,000 skills and tools and supports web, Slack, embedded, and custom application experiences. Within two weeks of its April launch, most of Stripe was using Kai; it now has 83% weekly active users, and reported effects include 25,000 annual hours shifted from administrative work and higher sales activity and deal creation among Account Executives.
How Stripe uses graph search and state machines to auto-remediate a global database fleet
Stripe describes how its Document Database fleet previously handled degraded MongoDB shards with single-step, hard-coded plugins that struggled with combined failures, intermediate states, and more than 40 shard layouts. The replacement models shard topology and health as a directed graph, with infrastructure operations as edges and safety invariants defining valid states. A simulator uses breadth-first search to find minimum-operation recovery paths, while an abstraction over Temporal contexts lets the same remediation logic run in memory without real infrastructure calls; later, the system also uses Dijkstra's algorithm. The system reduced pager volume by 30%—about 200 pages annually—reclaimed 12 days of fleet health each year, and handled a new layout with zero code changes, according to the post.
Keeping funds where they belong: Implementing fund segregation in Stripe Connect
Marketplaces using Stripe Connect’s separate charges and transfers can pool seller funds with platform revenue, exposing them to payouts, unrelated disputes, fees, refunds, and operational mistakes. In response to anticipated PSD3 changes and tighter Commercial Agent Exemptions, Stripe introduced Segregated Separate Charges and Transfers, which places captured payment funds in an allocated balance that cannot fund payouts and can only be transferred to connected accounts. The integration enables allocated_funds on PaymentIntents, transfer_group tracking, source_transaction-linked transfers, and application fees collected from the same allocation; balances are inspected through the API. The post also details split transfers, refund and reversal ordering, dispute handling, prerequisites, and limitations including card-only support, preview-header requirements, and sandbox-only testing, presenting segregation as a way to make fund flows traceable and operationally safer.
Introducing a better way to process Stripe's thin events
Stripe introduces event notification handlers to simplify processing thin events, unversioned JSON payloads that remain identical across API versions. The problem is that current integrations require developers to validate and route notifications, manage Stripe-Context for connected accounts, and manually maintain event-type strings, while API-version or SDK upgrades can cause runtime errors. Handlers move casting, routing, validation, and conversions into the SDK: typed callbacks are registered with handler.on, and callbacks receive a parsed notification plus a StripeClient already bound to the event context. The handler also provides a fallback for unhandled events and supports normal function-level testing, while the webhook endpoint only needs to pass the request body and signature to handler.handle. The pattern is supported in seven server-side SDKs, with feedback sought before general availability and possible future improvements to validation and framework integrations.
Extending Stripe’s network with stablecoins
Stripe describes integrating stablecoin settlement into its existing Global Payments and Treasury Network (GPTN), rather than creating a parallel system. GPTN models accounts, wallets, and payment rails as a directed graph, allowing routing, netting, cross-entity settlement, FX, reconciliation, and liquidity management to span fiat and blockchain flows. For a payout, Stripe records a pending stablecoin obligation, Bridge draws from a stablecoin liquidity pool to credit the recipient within seconds to minutes, and fiat replenishment proceeds asynchronously over traditional rails; reverse flows work similarly. A direct mode bypasses the usual few-minute planning cycle for urgent wallet funding, trading netting efficiency for speed, while standard flows continue batching. The live infrastructure handles real traffic, with ongoing work focused on forecast-driven liquidity, faster replenishment through RTP and SEPA Instant, and broader product and corridor coverage.
From hobby to real world: integrating the hard stuff with agents
The post documents building a production-oriented leaderboard for open-source Stripe Projects applications, where users submit projects, share links, and vote. Unlike an earlier transcription app, this project required authentication, multiple database tables, hosting, and controls limiting unauthenticated users to one vote per project. The agent initially selected Supabase for database and auth and Vercel for hosting, then added Upstash Redis after an in-memory rate limiter proved unsuitable for serverless enforcement. Supabase's two-emails-per-hour authentication limit prompted a human-directed migration to Clerk, after the agent proposed an unsuitable Twilio solution. The resulting MVP used five resources across four providers, took more than a day, and received separate security and performance audits before review.
How API changes flow into Stripe's developer products
Stripe describes how API changes are propagated across its developer-product suite, including SDKs in seven languages and three release channels, the CLI, Shell, API Explorer, API Reference, changelog, and internal tools. Historically, v1 workflows used OpenAPI or a Ruby-based DSL while v2 APIs used protobuf-based DSLs and an internal API specification, forcing teams to maintain parallel generators and leaving some products without v2 support. Stripe chose OpenAPI as a shared representation and built a pipeline whose generated artifacts are tailored by variant, release phase, and API version, with vendor extensions carrying Stripe-specific metadata. Automated validation, OpenAPI diffs, pre-release comparisons, versioned snapshots, and downstream publishing now connect API definition changes to documentation, code samples, SDK and CLI releases, while older v1 versions remain difficult to regenerate with newly added metadata.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.