We love the web, and care deeply about beautiful code, APIs, and documentation. This belief is as true today as it was when we first wrote this line on our website when we were ten people. Our engineering blog captures how, what, and why we code at Stripe.
Abstracting away the complexity of payments has driven the evolution of our APIs over the last decade. This post provides the context and conceptual frameworks behind our API design—and the milestones that led to the PaymentIntents API.
We set out to build a globe that inspires a sense of awe, invites people to explore, and conceals details for discovery. Along the way, we evaluated existing tools, designed our own solution, solved four interesting technical challenges, and improved the way we collaborate. Here’s what we learned.
Last May, Stripe launched our remote engineering hub, a virtual office coequal with our physical engineering offices in San Francisco, Seattle, Dublin, and Singapore. It’s now the backbone of a new working model for the whole company. Here is what we’ve learned.
Stripe enables businesses in many countries worldwide to onboard easily so they can accept payments as quickly as possible. Stripe’s scale makes our platform a common target for payments fraud and cybercrime, so we’ve built a deep understanding of the patterns bad actors use. We take these threats seriously because they harm both our users and our ecosystem; every fraudulent transaction we circumvent keeps anyone impacted from having a bad day.
Building and testing a Stripe integration can require frequent switching between the terminal, your code editor, and the Dashboard. Today, we’re excited to launch the Stripe command-line interface (CLI). It lets you interact with Stripe right from the terminal and makes it easier to build, test, and manage your integration.
Color contrast is an important aspect of accessibility. Good contrast makes it easier for people with visual impairments to use products, and helps in imperfect conditions like low-light environments or older screens. With this in mind, we recently updated the colors in our user interfaces to be more accessible.
Stripe launched in Singapore in 2016. Since then, we’ve seen strong traction, and are proud to work with some of the fastest-growing companies in the region, including Grab, Mobike, and Carousell. Today, we’re increasing our investment: we’re very excited to announce that Singapore is joining Seattle, Dublin, and San Francisco to become Stripe’s fourth global engineering hub.
Logging is one of the oldest and most ubiquitous patterns in computing. We’ve found using a slight augmentation to traditional logging immensely useful at Stripe—an idea that we call canonical log lines. It’s a simple technique: in addition to their normal log traces, requests also emit one long log line at the end that includes many of their key characteristics. Having that data colocated in single information-dense lines makes queries and aggregations over it faster to write, and faster to run.
DNS is a critical piece of infrastructure used to facilitate communication across networks. DNS issues can quickly lead to crippling, widespread outages, and you could find yourself in a real bind. Here's how we monitor our DNS systems and how we used an array of tools to investigate and fix an unexpected spike in DNS errors that we encountered recently.
Stripe uses machine learning to respond to our users’ complex, real-world problems. Machine learning powers Radar to block fraud, and Billing to retry failed charges on the network. Our machine learning infrastructure scores hundreds of millions of predictions across many machine learning models. Over time, the volume, quality of data, and number of signals have grown enormously. Here we discuss Railyard and our lessons on building and operating machine learning infrastructure.
Stripe has engineering hubs in San Francisco, Seattle, Dublin, and Singapore. We are establishing a fifth hub that is less traditional but no less important: Remote. We are doing this to situate product development closer to our customers, improve our ability to tap the 99.74% of talented engineers living outside the metro areas of our first four hubs, and further our mission of increasing the GDP of the internet.
Stripe builds economic infrastructure, and we’re designing for a global audience and market. In doing so, we carefully consider our technology and tools, organizational structure, and employee representation. Successful global organizations establish this mindset for different reasons. For some, it’s foundational—their mission, product, and addressable market crosses time zones. Others develop an international customer base, hire remote employees, or begin to open offices abroad to extend their physical presence.
Reserved instances are hard to purchase effectively. It’s easy to allocate the wrong number, and hard to predict future compute requirements over time. Deciding which and how many reserved instances to buy is a non-trivial exercise at the nexus of cloud strategy, bin packing, and capacity planning. Here's how we use AWS Reserved Instances to dynamically scale our fleet of servers and predictably forecast our cloud spend.
In this post, we’ll explain why we chose to build on top of Kubernetes. We’ll examine how we integrated Kubernetes into our existing infrastructure, our approach to building confidence in (and improving) our Kubernetes’ cluster’s reliability, and the abstractions we’ve built on top of Kubernetes.
At Stripe, we regularly contribute to open-source projects and rely on open-source software for developing many different parts of our stack. Stripe supported the development of Hypothesis, an open-source testing library for Python created by David MacIver. Hypothesis provides effective tooling for testing code for machine learning, a domain in which testing and correctness are notoriously difficult.
Today, we’re excited to add .NET to our officially supported languages (alongside Ruby, Python, PHP, Java, Node, and Go). Going forward, we’ll regularly be updating the Stripe .NET library to support our latest products and features.
When it comes to APIs, change isn’t popular. While software developers are used to iterating quickly and often, API developers lose that flexibility as soon as even one user starts consuming their interface. Many of us are familiar with how the Unix operating system evolved. In 1994, _The Unix-Haters Handbook_ was published containing a long list of missives about the software---everything from overly-cryptic command names that were optimized for Teletype machines, to irreversible file deletion, to unintuitive programs with far too many options. Over twenty years later, an overwhelming majority of these complaints are still valid even across the dozens of modern derivatives. Unix had become so widely used that changing its behavior would have challenging implications. For better or worse, it established a contract with its users that defined how Unix interfaces behave.
We recently released a new and improved version of Connect, our suite of tools designed for platforms and marketplaces. Stripe’s design team works hard to create unique landing pages that tell a story for our major products. For this release, we designed Connect’s landing page to reflect its intricate, cutting-edge capabilities while keeping things light and simple on the surface.
In this blog post, we’ll describe how we used several next-generation web technologies to bring Connect to life, and walk through some of the finer technical details (and excitement!) on our front-end journey.
Availability and reliability are paramount for all web applications and APIs. If you’re providing an API, chances are you’ve already experienced sudden increases in traffic that affect the quality of your service, potentially even leading to a service outage for all your users.
The first few times this happens, it’s reasonable to just add more capacity to your infrastructure to accommodate user growth. However, when you’re running a production API, not only do you have to make it robust with techniques like idempotency, you also need to build for scale and ensure that one bad actor can’t accidentally or deliberately affect its availability.
We just launched version 1.1.0 of our Android SDK, which fixes a few bugs and adds some new features: threading control, brand instead of type for cards, look up a card’s funding source, and Javadoc.