Loading…
Stripe
Global payments and financial infrastructure platform building sophisticated technology for online commerce
Latest articles
Stripe ·
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.
Jack LoughranStripe ·
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.
Aditya AnchuriStripe ·
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.
Rami BannaStripe ·
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.
Allison FarrisStripe ·
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.
Allison FarrisStripe ·
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.
Alistair GrayStripe ·
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.
Alistair GrayStripe ·
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.
Michael SelanderStripe ·
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.
Tanya BoiteauStripe ·
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.
Kalyani KoppisettiStripe ·
Stablecoin payments for Stripe developers: zero crypto knowledge required
The guide explains how Stripe developers can add USDC stablecoin payments without managing private keys, gas estimation, network selection, or wallet connection flows. Stripe supports USDC on Ethereum, Solana, Polygon, and Base, settles transactions as fiat in the merchant’s Stripe balance, and charges a 1.5% fee; the described feature is currently limited to US businesses. Integration can use payment_method_types: ['card', 'crypto'], although Stripe recommends automatic_payment_methods for Dashboard-managed configuration, filtering, ordering, and testing. Stripe Checkout and Elements expose crypto without frontend changes, while confirmation, webhook handling, monitoring, and familiar failure processing remain aligned with existing payment flows. The guide also describes Sandbox testing without testnets or fake cryptocurrency and presents crypto payments as a way to offer global settlement and potentially lower processing costs.
Robert LoveStripe ·
Using a web-based POS with a mobile Terminal reader
Web-based POS systems can reuse ecommerce infrastructure for showroom-floor selling, but mobile readers such as the Stripe M2 and Tap to Pay cannot be accessed directly by a mobile browser. The proposed wrapper app avoids a complete native POS rebuild by embedding the site in a React Native WebView and connecting a mobile or Tap to Pay reader through the Stripe Terminal React Native SDK. A bridge message carries cart information, such as a cart ID and ready-to-pay status, to a ReaderManager that retrieves the amount and calls createPaymentIntent(), collectPaymentMethod(), and confirmPaymentIntent(). Payment results can return to the POS through a backend webhook and WebSocket or frontend polling, while security requires origin-checked messages, nonces, and server-side validation. The approach retains WebView performance, offline, native-access, debugging, and security limitations.
Benjamin NuttinStripe ·
How we built it: Real-time analytics for Stripe Billing
Stripe built a real-time streaming analytics system for Billing after customers said they needed to detect emerging behavior and adapt pricing quickly, replacing a batch pipeline whose subscription updates lagged by 24 hours on average. The architecture uses Apache Flink to maintain compressed subscription history and incrementally process analytics events, while a custom Apache Spark job generates initial Flink state from billions of historical events and supports validation and exports. A new Apache Pinot v2 query engine performs windowed aggregations and joins without offline preaggregation; most updates are processed in under one minute, nearly all reach users within 15 minutes, and production query latency is under 300 milliseconds. Metric-definition changes trigger historical recalculation while new events are buffered and later replayed, preserving a consistent Dashboard view during the transition.
Reed TrevelyanStripe ·
Seamlessly connect Stripe events to your frontend
Stripe events can connect backend state changes to responsive frontend interfaces for payments, subscriptions, connected accounts, and Stripe Terminal workflows. The post contrasts polling, which can increase traffic, latency, and delta-computation complexity, with push subscriptions, while noting that a hybrid of initial API loading and incremental updates is common. It describes webhook endpoints and Amazon EventBridge as ingestion choices, then emphasizes idempotency, ordering, duplicate detection, and failure handling. Frontend delivery options include WebSockets, MQTT, gRPC, Server-Sent Events, polling, AWS AppSync, and Momento, selected according to messaging pattern, direction, latency, scale, and operational trade-offs. An abbreviated lounge example uses a PaymentIntent and Terminal reader, routes payment_intent.requires_payment_method through EventBridge to AWS AppSync Events, and lets a React client mark the reader ready to collect payment.
Josh KahnStripe ·
Workflows: Automate compliance safeguards by flagging transactions
Stripe Workflows can automate additional compliance safeguards by flagging transactions that need review before order processing. The described pattern starts when a Payment intent succeeded event occurs, retrieves the customer, and checks whether the customer’s custom_status metadata is not “Approved” while the payment amount exceeds $5,000. When these conditions are met, the workflow emails one or more designated team members with instructions for assessing the order. The examples motivating review include unusually high order values, unfamiliar sales regions, and behavioral patterns commonly associated with fraud, such as a new customer order above a monetary threshold. Workflows uses a visual building interface in the Stripe dashboard to sequence actions across multiple Stripe products, helping enforce business rules, reduce manual effort, and support risk management.
Ashley AnsariStripe ·
Marketplace monetization with Stripe
Online marketplaces connect buyers and sellers while monetizing commissions, shipping, marketing, payment operations, insurance, or other value-added services. Greens & Dairy Mart illustrates a model in which farmers receive payment after delivery, sellers pay a 15% rate on sales, and shipping, marketing, payout, and insurance options create additional revenue streams. Stripe Connect supports transaction-linked fees through the Platform pricing tool or application_fee_amount, while Stripe Billing provides usage-based meters, subscriptions, and invoices for recurring or one-off charges. The example records pay-per-click, conversion, and penalty events against farm customers, charges monthly subscriptions automatically, and bills damaged-goods insurance annually, with the stated conclusion that programmatic disbursement and monetization give marketplaces a central point to monitor and report these activities.
Ana AndresStripe ·
Real-time vs batch reconciliation: Practical patterns for keeping data in sync
Product data reconciliation across internal databases, ERPs, and platforms such as Stripe becomes harder to maintain as catalogs and system relationships grow, affecting financial reporting, customer experience, and operations. The post compares real-time reconciliation, using tools such as Kafka, Flink, Delta Live Tables, and Debezium for more immediate consistency, with batch approaches built around Spark, AWS Glue, Snowflake, and dbt for periodic, large-scale checks at lower cost and complexity. It also presents validation options including Great Expectations, Apache NiFi, Talend, and Airbyte, and recommends defining data ownership, applying field-specific conflict rules, and routing critical mismatches to manual review. Soft deletes and tombstones preserve deletion history, while observability through synchronization latency, conflict rates, resolution patterns, and regular audits helps assess reconciliation health as product catalogs scale.
James BeswickStripe ·
From naive webhooks to durable sync: Queue-based and event-driven data reconciliation patterns
Maintaining consistent product data between an internal catalog and Stripe becomes difficult when outages, throttling, high volumes, and changes from both systems create reconciliation failures. The post compares a naive one-way flow, in which a Lambda calls the Stripe API with no persistent synchronization record, with a queue-based design that durably stores changes, controls processing rate, retries failures with exponential backoff, and sends persistent failures to dead-letter queues. For bidirectional synchronization, it contrasts periodic ETL, using extraction, transformation, and loading, with an event-driven model based on Stripe Event Destinations, EventBridge, SQS, and symmetrical events from internal systems. The conclusion is that durable, observable queues and event-driven processing provide buffering, auditability, near-real-time propagation, independent change processing, and more graceful scaling for distributed reconciliation.
James BeswickStripe ·
Keeping product data aligned with Stripe as your systems scale
Keeping internal product data aligned with Stripe becomes an architectural challenge as catalogs grow from hundreds to millions of items. The problem spans independently operated systems with different data models, API constraints, rate limits, availability guarantees, and consistency models, while products may change faster than periodic reconciliation can complete. Stripe's payment-focused model covers identifiers, descriptions, prices, currencies, billing terms, and subscription behavior, whereas internal systems may contain categories, inventory, rich content, technical specifications, media, and sensitive cost data. The series examines manual verification, simple scripts, and periodic jobs for smaller catalogs, then points to streaming, change data capture, intelligent partitioning, and conflict resolution for high-scale reconciliation. It concludes that cross-system synchronization requires deliberate mapping and automated architecture because perfect synchronization is difficult to guarantee in eventually consistent distributed systems.
James BeswickStripe ·
Gating entrances with Stripe and NFC passes
The post presents a gym membership access system that replaces plastic cards, fobs, and physical keys with Apple Wallet and Google Wallet passes scanned by an NFC reader. It uses Stripe Checkout and subscriptions for payment, PassNinja as a single API layer for issuing passes, and a DotOrigin VTAP100 connected to a Raspberry Pi Zero 2W, relay, and door strike for entry control. After Checkout, the website verifies that the Stripe subscription is active, creates a pass whose nfc-message contains the Stripe subscription ID, and redirects the member to add it to a wallet. A Linux gate process reads that identifier from the reader's virtual serial port, retrieves the subscription from Stripe, and activates the relay for five seconds when the status is active; otherwise it denies access.
Joshua Nussbaum