Loading…
Stripe
Global payments and financial infrastructure platform building sophisticated technology for online commerce
- 108 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
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.
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.
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.
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.
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.
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.
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.
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.
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.
Guardrails for money movement: Integrating Stripe MCP with Portia AI
Portia AI presents a customer-refund agent that combines its guardrails with Stripe’s official Model Context Protocol server. The agent reads a refund request, compares it with a policy file, identifies the relevant Stripe customer and payment intent, and evaluates whether the request should be approved. Portia’s planner produces a multi-agent plan, while execution agents run it and persist outputs in plan state; an execution hook pauses before the Stripe create-refund call. A clarification presents the request and the agent’s rationale to a human, who can approve it in the CLI; approval allows the refund to proceed, while rejection exits without creating one. The example also handles Gmail OAuth and can send the customer an email describing the outcome.
Building financial operations agents with Hypermode and Stripe
Hypermode Agents and Stripe can be combined to create domain-specific financial operations agents from natural-language descriptions rather than conventional code. The workflow uses Hypermode’s Concierge to generate a system prompt, then connects the agent to Stripe through the Stripe Model Context Protocol (MCP) server and optionally to services such as Notion, Slack, and Google Calendar. With a restricted Stripe API key and sandbox data, the agent can retrieve policies, inspect customer and transaction history, apply refund rules, process payments, create invoices, and analyze subscriptions for metrics such as MRR. The examples describe partial refund decisions, onboarding workflows, campaign suggestions, and populated test environments, while the guidance recommends prompt iteration, human approval for high-value transactions, and monitoring and logging for compliance and improvement.
Workflows: Automatically customize an object with metadata
Stripe Workflows can customize Stripe objects with metadata, adding contextual key-value information without changing the core data model or storing it separately. The example targets customers associated with successful Payment Intents that include a tip, so a customer can be labeled for business use, such as reconciliation, reporting, or internal integrations. To build it, the workflow retrieves the customer from the Payment Intent, emails a team member, checks whether the successful Payment Intent contains a non-empty tip amount, and updates that customer with the metadata key Tier and value VIP. Workflows runs a trigger and sequential actions or conditions in a visual Stripe Dashboard builder, while metadata can carry information to later workflow steps and support automation, analytics, and debugging.
How we built it: Jurisdiction resolution for Stripe Tax
Stripe Tax’s jurisdiction resolution system (JRS) determines which US taxing jurisdictions apply to a transaction, a difficult task because more than 16,000 combinations of rates and rules depend on intricate, changing boundaries. Its offline geographic information system cleans and standardizes boundary data, overlays states, counties, cities, and districts, and generates time-aware Stripe places of taxation (SPOTs), while the online system matches an address to the relevant SPOT. To reduce point-in-polygon latency, JRS indexes nested bounding boxes in a balanced R-tree rebuilt with the Sort-Tile-Recursive algorithm, narrowing candidates before applying the final polygon calculation; disjoint SPOTs are split and smaller boxes prioritized. Most states achieve address matching in a few milliseconds, with 95th-percentile latency below 10 milliseconds except South Carolina, while historical SPOT data creates an ongoing memory challenge.
Workflows: Creating early fraud alerts for streamlined refunds
Stripe Workflows can automate responses to early fraud warnings so potentially fraudulent charges receive refunds when disputing them would be more costly. The workflow starts when an early fraud warning is created in Radar, retrieves the related charge using its Charge ID, and checks whether the amount is less than 15 USD. If the condition is met, it creates a refund; if it is not met, an optional branch can email a team member for manual review. Workflows uses a visual builder in the Stripe dashboard, where triggers, actions, and conditions run sequentially across multiple Stripe products, while Stripe Radar provides real-time fraud protection and Radar for Fraud Teams adds customization and deeper insights.
Stay within limits: API rate-limit-friendly pattern for Stripe webhooks
Stripe webhook handlers that treat events as signals and fetch the latest resource can preserve correctness when payloads are stale, partial, duplicated, or out of order, but bursts of events can drive excessive API traffic. The post describes Stripe’s general limit as 100 read requests per second and notes that exceeding it produces 429 responses. Its solution places Hookdeck Event Gateway between Stripe and the application: Hookdeck authenticates and queues incoming webhooks, throttles delivery, and lets the handler retrieve the current Stripe resource at a controlled pace. The Express.js flow verifies the Hookdeck signature, checks the event and resource ID, fetches the invoice with the Stripe SDK, and supports queue monitoring, alerts, and retries for backpressure.
Stripe for marketplaces: Mapping commercial relationships in code
The post presents a guide to mapping marketplace relationships among buyers, sellers, and the platform in Stripe Connect, focusing on payment processing, seller onboarding, payouts, fees, refunds, and disputes. It uses Greens & Dairy Mart, a fictitious farm marketplace, to show how an unlicensed marketplace can manage payments with Stripe while meeting applicable regulatory requirements. Using the Account API, connected accounts, controller settings, KYC links, capabilities, Payment Intents, transfers, and webhooks, the implementation encodes responsibilities and money movements. Greens & Dairy Mart charges customers after farmers confirm dispatch, pays farmers after delivery confirmation, and retains 15% of the final price. The guide also shows refund and transfer reversal flows, including recovering disputed amounts from a seller’s balance, and concludes that Connect APIs can automate complex marketplace contracts and financial interactions.
Using Connect embedded components to streamline your Connect onboarding flow
Furever, a test Connect platform for pet grooming, needs to onboard connected accounts and keep them compliant and activated while reducing friction. It first creates Custom accounts with card_payments and transfers requested, then contrasts Stripe-hosted account links with an embedded flow built from Account Sessions, loadConnectAndInitialize, and ConnectAccountOnboarding. The integration supports appearance variables for branding, disable_stripe_user_authentication when the platform owns losses and requirement collection, and onStepChange analytics for onboarding progress. A shared connectInstance can also render ConnectPayments, which provides payment listing, refunds, and dispute management without building that interface; the source also notes localization, framework support beyond React, and additional components.
Implementing scalable metered billing with Stripe: How Edgee handles billions of events
Edgee needed usage-based billing for a business combining flat-rate subscriptions with charges for proxy requests and delivered data events, while processing billions of monthly requests across more than 100 edge locations. Its architecture captures web data at the edge through a proxy and records raw metering data centrally in Google BigQuery. To control several terabytes of data, Edgee aggregates usage by tenant and sends hourly Stripe meter events through AWS Lambda, with graduated pricing and idempotency handled by Stripe. A Go configuration defines meters, prices, flat-rate plans, and pricing tiers, while retry logic and idempotent updates support resilience during disruptions. The resulting billing system remains stateless and low-latency while providing accurate monthly invoicing and a simple hosted customer interface.
Stop juggling multiple POS devices with Stripe Terminal
Traditional point-of-sale workflows often collect signatures, contact details, receipt preferences, and other customer information through separate devices, verbal input, or manual entry, creating errors, delays, and clutter. Stripe Terminal’s on-screen input collection lets businesses request this data on a compatible reader, supporting selection, signature, email, phone, text, and numeric fields before or after payment. Developers configure forms with the Stripe API or Terminal SDKs, can sequence multiple inputs and attach metadata, and receive responses through terminal.reader.action_succeeded webhooks; signature files are returned by file ID and need to be downloaded within 24 hours. The rental-car example uses selection and email forms for reservation lookup, followed by an on-reader agreement signature, replacing a separate signature pad and manual transcription while giving the POS more accurate data for receipts, lookups, and loyalty interactions.
Extending Docusign with Stripe to automate complex billing workflows
Docusign’s Stripe extension app addresses agreement workflows that continue beyond eSignature, where customer and billing data previously required manual transfer or complex integrations between platforms. The post shows how to install the app, start from the “Send new customer data to Stripe for invoicing” Maestro workflow template, and map web-form data to Stripe Customer, Invoice, InvoiceItem, and Email Invoice steps. It also explains how developers can switch the workflow to an API trigger, retrieve trigger requirements, and launch an instance with two authenticated API calls: one GET and one POST. The resulting flow collects customer information, creates a Stripe customer and draft invoice, adds an invoice item, and sends the invoice, while the returned instance URL can be opened or embedded for participants.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.