Loading…
Latest reads
The engineering internet, summarised so you can actually read it.
Stripe ·
Easily debug your 3DS authentication with Stripe Workbench
Stripe Workbench provides browser-based tools for investigating EMV 3DS authentication and related payment flow behavior in the Stripe dashboard. It lets developers inspect Payment Intent and Charge data, including payment_method_details.card.three_d_secure.authentication_flow and result, to determine whether authentication used a challenge UI and whether it completed successfully. The Inspector also exposes API history and webhook events, while the Events tab can filter historical payment_intent.requires_action events and show their frequency over a selected period. In the Shell tab, stripe trigger payment_intent.requires_action simulates a 3DS-related flow and generates event data without installing additional tools, allowing webhook handling to be tested and investigated from the dashboard.
Hidetaka OkamotoStripe ·
Creating reusable developer environments with Stripe Sandboxes
Setting up development machines with the correct tools, permissions, and dependencies can take weeks for new engineers, so the setup combines Stripe Sandboxes with development containers. Stripe Sandboxes provide isolated accounts with full Stripe API access for testing without real transactions, while sandbox settings remain independent and production customer, product, and transaction data is not copied. A C# example uses Bogus to generate ten fake products and Stripe.net’s ProductService to create them with metadata in the sandbox, and the text notes that SDKs can populate additional account data. The containerized workspace uses Docker development containers, a .NET 8 image, Redis via Docker Compose, environment variables, VS Code customizations, and a post-create script that installs Stripe CLI. Configuration files can then be checked into source control, giving team members an isolated and consistent workspace for exploring payment workflows without affecting live data.
Cecil PhillipStripe ·
Testing subscriptions with Stripe Test Clocks and Workbench
Stripe subscriptions require testing scenarios that unfold across billing cycles, and the post presents Test Clocks and Workbench as no-additional-cost test-mode tools for doing so without waiting real time. It provisions three monthly recurring product tiers, creates a test clock with a Unix Epoch FrozenTime, and attaches newly created customers and subscriptions to that clock using the Stripe .NET SDK. Advancing the clock by one month updates time-dependent objects, allowing Workbench Inspector logs and events such as invoice.created and customer.subscription.updated to be examined alongside payment and subscription state. A second simulation attaches pm_card_chargeCustomerFail, makes it the default payment method, and advances to the next billing period. The resulting failed invoice, canceled subscription, and customer.subscription.deleted cancellation_details show how these tools reveal the events and properties an integration should test.
Cecil PhillipGrab ·
Leveraging RAG-powered LLMs for analytical tasks
Data analysts at Grab faced an increasing volume of stakeholder data requests that required manually writing and executing repetitive SQL queries with minor parameter changes. To automate routine tasks like metric reporting and fraud investigations, the Integrity Analytics team paired an internal prompt-management platform, Spellvault, with Data-Arks, an in-house Python-based middleware that packages SQL queries and Python functions into APIs. A scheduler triggers automated report summarization, while an analytical bot named A* bot executes relevant investigation queries via RAG and returns summarized findings in Slack. Automated report generation saves an estimated three to four hours per report and shortens multi-query fraud investigations to minutes. Grab favored RAG over fine-tuning because it avoids continuous retraining costs, scales faster across diverse use cases, and surfaces current production data.
Edmund HongImproving Compute Sustainability: A Case Study
Two Sigma's large computing footprint drives significant energy consumption and carbon emissions, particularly across live trading applications that require continuous real-time market data caching. To address this overhead without sacrificing performance, engineering teams used a routine hardware refresh to transition from legacy single-process machines to denser multi-core server configurations. By replacing roughly 60 legacy hosts with 28-core processor hardware, the team distributed baseline power draw over more cores and eliminated underutilized compute capacity. This architectural consolidation reduced absolute power consumption across production hosts by 66%, dropping electricity usage from 27 MWh in January 2023 to 10 MWh in January 2024. The initiative subsequently established an annual sustainability rationalization practice for hardware budgeting across the organization.
Emily MajewskiGrab ·
Evolution of Catwalk: Model serving platform at Grab
Grab developed and scaled Catwalk, an internal machine learning model serving platform, to address operational bottlenecks, low resource utilization, and deployment friction between data scientists and backend engineers. The platform transitioned from an admin-managed TensorFlow Serving setup into a low-code self-service system supporting PyTorch and ONNX, before replacing complex Helm charts with Kubernetes Custom Resource Definitions for declarative, blue-green deployment orchestration. To support complex business workflows and multi-model applications, Grab subsequently introduced Catwalk Orchestrator with bundled deployments that allow individual services to scale independently. Across two years, the orchestrator architecture expanded to 200 deployed applications serving approximately 1,400 production machine learning models.
Vishal SharmaGrab ·
Enabling conversational data discovery with LLMs at Grab
Grab faced major bottlenecks in dataset discovery across its 200,000 data lake tables due to low documentation coverage and vanilla Elasticsearch limitations in its internal tool, Hubble. To resolve this, engineers first tuned Elasticsearch by boosting frequently queried P80 tables and certified schemas while deboosting deprecated datasets. They then deployed a GPT-4 pipeline that generated documentation from table schemas and sample data, raising P80 documentation coverage from 20% to roughly 90%. Finally, the team developed HubbleIQ, an LLM-powered assistant built via Glean Apps and integrated into Slack and Hubble search to answer semantic queries. These initiatives increased search click-through rates to 94% and lifted the proportion of users finding discovery easy to 73%.
Shreyas ParbatStripe ·
Choosing the right sandbox strategy for your organization
Stripe sandboxes provide isolated environments for testing Stripe features without affecting a live integration, with access controls for the people who use them. Each live account can have up to five sandboxes, which admins can create, name, configure by copying selected live-account settings, and delete when no longer needed. The guide describes a staged setup for startups and small teams, using separate environments for development, integration testing, user acceptance testing, and spare capacity, while larger organizations may assign sandboxes to departments and rotate them between projects. It also presents an iterative model in which teams prototype, collect stakeholder feedback, retest changes, and document results. The recommended strategy depends on team size, organizational structure, workflow, and development methodology.
Ben SmithGrab ·
Bringing Grab’s Live Activity to Android: Enhancing user experience through custom notifications
Grab designed an equivalent to iOS Live Activities for Android to provide real-time order tracking outside the app. Because Android lacks Apple's native ActivityKit push token system, the team substituted push tokens with placeholder values to maintain technical consistency across platforms and preserve backend push targeting via their Hedwig service. For the user interface, engineering selected custom notifications over floating views because custom notifications avoid intrusive screen usage and do not require the 'Draw over other apps' permission. The client implementation separates responsibilities across dedicated classes: LiveActivityIntegrationManager handles token registration across business verticals, LiveActivityAttributes encapsulates UI configuration, and LiveActivityManager maps payloads to Android NotificationManager instances. The solution launched for Food, Mart, Express, and Transport verticals.
Jessica SeanStripe ·
Upgrading your Stripe plugin security
Stripe plugins commonly authenticate merchants’ accounts with unrestricted secret API keys, but those keys grant full access and can expose payment, customer, and subscription operations if mishandled or compromised. The post presents restricted API keys (RAK) and OAuth 2.0 as zero-trust alternatives that apply identity verification and least-privilege permissions to third-party integrations. RAKs let developers define narrowly scoped permissions, while OAuth 2.0 uses Stripe’s interface for tokenized, one-click authorization and lets merchants revoke access without sharing a secret key. For existing plugins, it outlines migration through Stripe Apps, Stripe Connect, or manual RAK setup, and states that Stripe will require RAK or OAuth 2.0 authentication from October 29, 2024, with possible fees for merchants still using full-access keys after June 2025.
Ben SmithStripe ·
Avoiding test mode tangles with Stripe Sandboxes
Stripe integrations can become difficult to test when an account has only one test mode, because unrelated work can interfere and sensitive configuration must remain protected. The post presents Stripe Sandboxes as separate testing areas and shows a Node.js Express application authenticating with a sandbox secret key stored in a .env environment variable. It creates payment intents through /create-payment-intent and retrieves account details through /account, then uses Jest and supertest to verify the sandbox identity, including the expected display name dev-sandbox. A GitHub Actions workflow injects STRIPE_API_KEY from repository secrets, installs dependencies, and runs tests on pushes to the main branch, while .gitignore excludes environment files. The conclusion is that isolated sandboxes and automated checks reduce test tangles and help prevent calls to the wrong environment.
Ben SmithGrab ·
Unveiling the process: The creation of our powerful campaign builder
Grab details the event processing architecture behind Trident, its internal marketing campaign platform that evaluates If This, Then That (IFTTT) logic over Kafka streams. The core processing unit is a treatment consisting of an event, optional conditions, and actions. Complex campaign capabilities—such as counters, limits, and delays across multiple hours via recursive SQS message scheduling—are assembled from multiple coordinated treatments. To simplify campaign creation, Grab introduced a flowchart-like visual builder represented as a JSON node tree that compiles recursively into treatments while persisting node-to-treatment mappings to reconcile edits over time.
Jie ZhangStripe ·
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.
Ben SmithStripe ·
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.
Ben SmithStripe ·
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.
Stripe TeamStripe ·
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.
Ben SmithStripe ·
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.
David Edoh-BediGrab ·
Chimera Sandbox: A scalable experimentation and development platform for Notebook services
Grab's Chimera team built Chimera Sandbox to address resource accessibility challenges and enable rapid machine learning experimentation across technical and non-technical teams. The platform runs on multi-cluster Kubernetes infrastructure capable of scaling to thousands of nodes per cluster during peak loads. Users can provision customizable Docker environments with varying CPU and GPU configurations, collaborate in real time, and query data using Spark-on-Kubernetes integrations and helper magic cells. The workspace integrates with Grab's AI Gateway for LLM access alongside tools like MLflow, Optuna, RStudio, and LabelStudio on shared storage, backed by user-level cost attribution.
Arkar Min AungStripe ·
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.
David Edoh-BediStripe ·
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.
Cecil Phillip