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
Scaling up your microservice testing with Apache Spark—Part 2
Part 2 describes how to build a repeatable Apache Spark replay harness for testing high-impact microservices against historical, production-shaped inputs without reimplementing the service. The design turns dependency state—such as database snapshots, versioned rules, merchant configuration, eligibility state, and logged service responses—into datasets, while representing side effects as output rows and matching fidelity to the decision under test. A thin Spark wrapper reconstructs ReplayInput objects, invokes the same deterministic decision engine used online, compares current and candidate results, and writes traceable diffs with intermediate values and rule explanations. The source cautions that incomplete context, distributed state, asynchronous workflows, and external actors limit replay’s predictive power, so it should model explicit assumptions rather than claim full production simulation. It presents migrations as a practical point to establish these boundaries and use replay to reduce risk.
Scaling up your microservice testing with Apache Spark
Microservices whose behavior depends on long-tail production inputs—such as payment cost estimation—are difficult to validate with unit and integration tests alone. The described pattern separates deterministic service logic from transport and side effects, then invokes that logic in Apache Spark across historical records enriched with the required dependency state. The resulting datasets can compare current and candidate implementations, quantify changed outputs, model future rule changes, and identify affected transaction or merchant segments. Replay inputs and artifacts are minimized and protected through tokenized identifiers, redaction, access controls, and retention policies, while smaller privacy-safe golden datasets run in pull-request CI. The approach complements, rather than replaces, unit and integration tests: golden datasets cover known service behavior, and full replays expose changes across the real production distribution before deployment.
Compliance versus conversion: Tax ID validation at checkout
Tax ID collection at checkout supports compliant tax invoices and tax determination, including reverse-charge treatment for qualifying cross-border business transactions. Validation can be performed synchronously before purchase completion or asynchronously after checkout: synchronous checks reduce correction and audit risk but may increase abandonment and expose conversion to government-service downtime, while asynchronous checks preserve completion but require follow-up on failures. The implementation discussion covers direct national-registry integrations, third-party validation services, and Stripe’s CheckoutSessions and PaymentIntents integrations, where the Tax ID Element uses verification modes of if_supported or none. Stripe first applies a country-specific format check, routes validly formatted IDs to government APIs, may fall back to asynchronous processing after four seconds, and exposes status through customer.tax_id.updated and the customer object.
Modern Java at Stripe: Language upgrades as a service
Large JVM codebases often stall Java upgrades because build-graph constraints require coordinated changes across many owners, while manual scripts and stale inventories repeatedly rediscover blockers. Stripe built AutoJDK to continuously analyze the live build graph, compute eligibility using reverse-dependency, runtime, framework, and dependency-ordering constraints, and generate bounded, idempotent pull requests rather than opaque rewrites. It also tracks adoption and blocker categories, uses AI assistance for selected remediation tasks, and can operate continuously or on specified packages and services. Centralized JDK and runtime policy, CI checks, multi-JDK support, static analysis, and packaging applications with platform-specific JDKs support gradual transitions. After three months, the upgrader had merged more than 160 PRs, made JDK 17 the most common target, eliminated Java 8 services, and reduced the JDK 8 and 11 footprint by roughly 25K targets.
What it feels like building with Stripe Projects
The post recounts a 60-minute attempt to build a GitHub traffic dashboard with Stripe Projects, motivated by GitHub’s 14-day limit on traffic history. Using Cursor’s agentic chat workflow alongside Projects, the builder assembled a Next.js application with Auth0 authentication, Supabase persistence, Prisma schema management, Vercel hosting, scheduled jobs, environment wiring, and periodic GitHub traffic synchronization. The experiment largely avoided direct coding and instead tested whether AI-mediated orchestration could produce a production-shaped stack quickly. As services and credentials appeared across providers, the main difficulty shifted from implementation to understanding ownership, deployment topology, environment management, and operational flow. The repositories synced, charts populated, and historical data appeared, while the experience also exposed a need for clearer generated architecture or infrastructure-as-code descriptions of the assembled system.
You can't whisper at an AI agent
Stripe engineers ran roughly a dozen experiments to determine how to get AI agents to use current API versions, follow integration best practices, and load the Stripe skill. Passive hints, including SDK files, AGENTS.md guidance, and API warning responses, were largely ignored, while active prompts and distribution mechanisms performed better. A modular, progressively disclosed skill structure outperformed a monolithic file by roughly 10% and reduced token usage; a CLI login prompt led 30–35% of viewers to copy its install command, and explicit compatibility-mode errors prompted agents to correct version mismatches. The results suggest that agent-facing developer experience is primarily a distribution problem, with hard steering through errors and loaded instructions more reliable than soft hints agents may never encounter.
Learnings from init to deploy
An agent was used to build a transcription app for a team from initialization through deployment with Stripe Projects, OpenRouter, and Vercel. The app sends video-generated subtitles through an OpenRouter agent with a detailed system prompt and Stripe documentation tool calls, producing a formatted transcription whose speaker and service names are corrected. The author recommends treating agent-generated plans like design documents, verifying provider behavior, and using streaming for long transcripts because Vercel serverless limits made non-streaming responses prone to 504s for a roughly 1,500-line transcript. Testing led to removing an unreliable free-model tier, defaulting to openrouter/auto, and choosing Claude Opus 4.5-thinking over Claude Sonnet 4.5; shared agent files were committed, and a separate review agent was used before human review.
From init to deploy: building with agents and Stripe Projects
The post describes an internal agentic transcription app built to reduce the manual effort required to correct auto-generated subtitles for Stripe Developers videos. The app uses a Next.js interface with transcript, chat, and corrected-output panels, while Stripe Projects CLI links Vercel and OpenRouter and populates required environment variables. An LLM client supports selectable models, iterative instructions, and a transcription agent whose system prompt emphasizes preserving transcript structure; the agent can also use Stripe documentation search through MCP. In a benchmark on a 771-line meetup script, Gemini 2.5 Pro reached 99% accuracy, while the tested models reduced editing from more than 30 minutes to just over two minutes of generated edits plus a human check. The reported overall reduction was 4x, with testing costs totaling $2.54.
Formatting an entire 25 million line codebase overnight: the rubyfmt story
Stripe’s 25-million-line Ruby codebase needed a true autoformatter; before rubyfmt, no industry-wide Ruby formatter existed, and earlier tools had crashed on its files. rubyfmt began as a zero-configuration open-source project motivated by formatting disputes, Ruby’s slow startup, and the uncertainty faced by engineers arriving from other languages. To meet a 100ms target, it initially used a hand-authored C launcher and later moved formatting into Rust, with ripper parse trees first passing through JSON and eventually being deserialized directly from Ruby VALUE objects. Stripe adopted per-file opt-in, expanded coverage cautiously, and formatted the codebase on a Saturday in 2024; the excerpt reports that all 42-million-line Ruby codebase is now formatted. In 2025, migrating from ripper to Prism removed the need to link a Ruby VM and made rubyfmt smaller and dramatically faster.
How we built Stripe Credits: A programmable, auditable way to pay your Stripe fees
Stripe Fee Credits replaces ad-hoc discounts and manual cash adjustments with a programmable, auditable virtual balance dedicated to eligible Stripe fees. The architecture has three layers: a standalone gRPC credits engine for metadata, policies, lifecycle, and audit history; logical financial accounts built on Money Movement and Storage; and fee-settlement orchestration that applies eligible credits before the primary balance. Logical accounts carry ledger balances without representing real cash, while platform checks restrict Originated Money Transfers to logical-to-logical movements and exclude these accounts from cash sweeps. Prepaid and Stripe-funded credits share the user experience but use separate funds flows: prepayments create deferred revenue and collect tax at drawdown, whereas Stripe-funded credits are booked as Stripe costs with taxes written off. The resulting infrastructure supports incentives, prepaid annual fees, and other programs across 26+ countries, with Dashboard balances and real-time auditability, while avoiding bespoke engineering for each commercial model.
Using AI agents to build Stripe-Salesforce integrations faster
An experiment using Claude Code to build a Stripe App for Salesforce Flow exposed context gaps: the generated integration misnamed fields, targeted a nonexistent custom field, and omitted AsyncAfterCommit, causing a “Callout from triggers not supported” deployment error. The proposed remedy is a repository of grounding context files that present invocable signatures, request models, platform constraints, LWC patterns, and validated examples in concise, machine-readable form. Core files are about 35K tokens, while the full reference catalog is about 230K tokens and can be loaded on demand. With the context loaded, the agent selected the v02_CreateCustomers invocable directly and generated a helper Apex class for nested Checkout Session inputs, along with callout-safe Flow structure and other safeguards. The author reports minutes instead of hours and fewer iterations in personal usage, while noting that org-specific details still require human verification.
Selective Test Execution at Stripe: Fast CI for a 50M-line Ruby monorepo
Stripe’s Ruby monorepo contains about 50 million lines, 100,000 test files, and roughly 1.2 million test units, making sequential execution impractical at an estimated four months. To keep CI within minutes, Selective Test Execution (STE) runs tests whose recorded file accesses intersect files changed since a suitable baseline, averaging about 5% of the suite and under 10% of always-run compute. A dynamically linked C++ library loaded with LD_PRELOAD intercepts file opens, associates them with hierarchical test scopes, and propagates tracing to child processes; logs are aggregated into a selection index outside the syscall hot path. Guardrails cover tests affected by directory discovery, previously failing tests, selective linting, generated files, and reproducible database-backed baselines ordered by Monotonic Revision IDs. The system is presented as a way to preserve safety and affordability while scaling CI for a highly dynamic language.
Provision a production-ready dev stack from your terminal
Stripe Projects, a new tool in the Stripe CLI, addresses the manual, fragmented work of turning a local prototype into a production-ready environment. It manages a project manifest and Stripe-backed record for attached services, provider accounts, and required credentials, while an integration protocol standardizes provisioning, plan selection, upgrades, and credential handoff. The developer preview supports services from providers including Vercel, Railway, Supabase, Neon, PlanetScale, Turso, Chroma, PostHog, Clerk, and Runloop; resources remain in accounts owned by the developer, and credentials can be synced to local development, CI, or a team secret manager. Through CLI commands such as stripe projects init, add, upgrade, and env --pull, developers or coding agents can repeat setup, audit changes, and upgrade supported plans using tokenized payment credentials, although payment handoff is limited to supported providers and plans in the US, EU, UK, and Canada.
Designing flexible payment flows with Checkout Session
The post addresses the architectural challenge of taking a digital product business global while supporting localized tax, currencies, one-time purchases, subscriptions, and a branded embedded checkout. It recommends Checkout Sessions as the orchestration layer, with Stripe creating and managing the underlying Payment Intent while declarative parameters handle features such as Stripe Tax, Adaptive Pricing, subscriptions, and promotional codes. The implementation creates a session with ui_mode, mode, automatic_tax, adaptive_pricing, line items, and optional payment_intent_data, then passes the client secret to Stripe Elements for the Payment Element and Currency Selector. This approach supports localized payment methods and currency conversion without a backend rewrite, while direct Payment Intents remain appropriate when an application needs full control over carts, discounts, taxes, or its own checkout abstraction.
Building a mental model for Stripe payments
An online bookshop checkout must coordinate card networks, issuing banks, fraud checks, regulatory requirements, currencies, and varied payment methods while completing in roughly 2–3 seconds. Stripe abstracts these concerns through a unified API, with the PaymentIntent representing the payment lifecycle from amount and currency collection through tokenization, authorization, capture, and settlement. The Payment Element and client-side tokenization keep sensitive card details away from the shop’s servers, while Stripe may perform risk checks and additional 3D Secure authentication. Because payments can change state minutes, hours, or days later through refunds and disputes, webhook events should be treated as the source of truth for synchronizing order and downstream systems without polling.
Minions: Stripe’s one-shot, end-to-end coding agents—Part 2
Stripe’s minions are an unattended agentic coding flow whose pull requests are human-reviewed but contain no human-written code; more than 1,300 merge weekly. The system runs agents in AWS EC2-based devboxes that are prewarmed to become usable within about 10 seconds, providing parallel, predictable, and isolated environments. Its custom harness uses code-defined blueprints that combine deterministic nodes, such as linting and pushing changes, with agent loops for tasks such as implementation and fixing CI failures. Minions receive automated feedback through local linting, one full CI iteration, and a possible second repair attempt, while devbox isolation and security controls limit destructive actions; Stripe presents the approach as an extension of long-running investments in human developer productivity.
Minions: Stripe’s one-shot, end-to-end coding agents
Stripe’s Minions are homegrown, fully unattended coding agents designed to complete tasks in a single run, beginning with an invocation such as a Slack thread and ending with a pull request ready for human review. More than 1,000 pull requests merged weekly at Stripe are minion-produced and contain no human-written code, although engineers review them and can provide follow-up instructions. Each run uses an isolated, pre-warmed devbox and a customized fork of Block’s coding agent goose, combining agent loops with deterministic operations for version control, linting, and testing. Minions use curated MCP tools, including Stripe’s Toolshed with more than 400 tools, to retrieve internal context before and during work. Local checks and selective CI provide feedback, with no more than two CI rounds, balancing correction against token, compute, and time costs.
Configuring Stripe using Terraform and AI agents
The post addresses the difficulty of using AI agents to configure Stripe resources when one-off API calls leave no durable source of truth for state, changes, or environment differences. It recommends using agents to author Terraform configuration rather than operating Stripe directly, so products, prices, and webhook endpoints become explicit, reviewable code. The example defines a Standard Plan with $20 monthly and $200 annual prices, selected webhook events, and outputs for both price IDs, then applies it with terraform plan and terraform apply. Terraform provides declarative, repeatable configuration supported by Git history, pull-request review, and environment-specific workspaces. Separate sandbox and livemode workspaces, paired with matching STRIPE_API_KEY values, are presented as a way to reduce accidental cross-environment changes.
Versioning in Stripe Workflows: Ship workflow changes with confidence
Stripe Workflows previously required teams to edit live workflow definitions directly, leaving no draft state, historical definitions, straightforward rollback, or reliable way to inspect which configuration shaped an older run. Versioning addresses this with a dedicated draft for iteration, immutable numbered published versions, and version history that can include descriptions, authors, status, and run counts. Publishing creates a complete snapshot containing steps, branches, conditions, variable references, calls, and configuration; new runs use it immediately, while in-progress runs finish on the version they started with. Each run records its exact version and exposes the workflow definition, including taken and untaken branches, while a past version can seed a new draft for rollback; versioning is available in Stripe Workflows, where new workflows include a draft by default.
Building production-ready Stripe subscriptions using Kiro powers
Kiro's Stripe power is presented as a way to build a production-ready SaaS subscription flow while avoiding the fragmented output common with generic coding assistants. Using a natural-language specification for three monthly tiers and a three-month one-time option, Kiro creates a React frontend, Node.js backend API, CDN-hostable static assets, and server-side Stripe Checkout Session creation. The integration includes Stripe-specific steering files, MCP servers, and hooks, while the webhook handler preserves the raw request body, verifies HMAC signatures with stripe.webhooks.constructEvent(), rejects invalid events with HTTP 400, and routes lifecycle events such as checkout completion and subscription cancellation. The post concludes that this provides a secure, scalable foundation while leaving teams to customize business logic, including access provisioning and deprovisioning, instead of building payment infrastructure from scratch.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.