Last May, Stripe launched our remote engineering hub, a virtual office coequal with our physical engineering offices in San Francisco, Seattle, Dublin, and Singapore. We set out to hire 100 new remote engineers over the year—and did. They now work across every engineering group at Stripe. Over the last year, we’ve tripled the number of permanently remote engineers, up to 22% of our engineering population. We also hired more remote employees across all other teams, and tripled the number of remote Stripes across the company.

Like many organizations, Stripe has temporarily become fully remote to support our employees and customers during the COVID-19 pandemic. Distributed work isn’t new to Stripe. We’ve had remote employees since inception—and formally began hiring remote engineers in 2013. But as we grew, we developed a heavily office-centric organizational structure. Last year, we set out to rebalance our mix of remote and centralized working by establishing our virtual hub. It’s now the backbone of a new working model for the whole company.

We think our experience might be interesting, particularly for businesses that haven’t been fully distributed from the start or are considering flipping the switch to being fully remote, even after the pandemic. We’ve seen promising gains in how we communicate, build more resilient and relevant products, and reach and retain talented engineers. Here is what we learned.

Deploying engineers closer to customers has been a boon

One of our goals in establishing the remote hub was to connect more closely with our customers. A year ago, when an overwhelming majority of our engineering staff was located in two cities, it was more difficult to support a global user population with products that felt locally native in supporting commerce. Now, for example, our Developer Support Engineering team is distributed across three continents—and two thirds of the team operate outside of a Stripe office. Units within the team own one of four coverage areas (each spans approximately six time zones), enabling them to provide more timely, local support to users, as well as run uniform, simultaneous, and regionally resonant customer events around the world. We feel closer to customers because we literally are.

This shift has markedly influenced our product development roadmaps. We’ve made substantial improvements to support non-card payment methods throughout our product suite. Back in the day, we referred to these internally as “alternative payment methods” because from the perspective of someone living in San Francisco, that is accurate. However, for many of our global users, credit cards are the alternative still crossing the chasm to mass acceptance. We now refer to non-card payment options as “local payment methods”. This distinction recognizes and reminds us that while commerce is global, the experience is local.

We built Checkout to maximize conversion by intelligently prioritizing which payment methods are presented to the customer depending on where they’re located. Whether in Mexico or Malaysia, a company’s checkout experience should feel local and include the payment methods customers are most likely to prefer. One way to more naturally build in local considerations into global products is if they’re built by remote, distributed teams. One member of the Checkout team launched a local push payment method from Singapore and another shipped address collection from Maryland. Given the nature of Checkout, we hypothesize that the more distributed the team becomes, the closer we get to the needs and mindsets of more users.

Cultural improvements to support remote work have spilled over

We approached the building of our remote hub, in many ways, like any one of our other engineering hubs around the world. The standards and investments we’ve established for other Stripe offices have ported over well to our remote hub. We nominated a site lead (Aditya Mukerjee for the first year) to be responsible for the overall happiness and productivity of the hub. We ensure that our leadership regularly visits the hub via Zoom meetings to lead discussions, answer questions, and provide a sense of connection. We encourage virtual coffee chats to promote a sense of belonging. We survey the team regularly and review feedback and people data, so that we can understand both the shared needs of our employees and the particular needs of a hub.

Our remote hub’s organizational infrastructure enabled us to run experiments on individual engineering teams to determine how to best integrate remote engineers—and then horizontally scale the ones which generated notable successes. We still have more to discover, but have been seeing some themes emerge.

One is the loneliest number. The typical engineering team at Stripe has five to eight engineers. When only one member of that team is remote, they often suffer a combination of isolation (both socially and with respect to work-related decision making) and organizational burden (because they are effectively responsible for rearchitecting the team’s processes to be remote-friendly in addition to doing their actual job). Instead, moving multiple remote engineers simultaneously onto a team has yielded much better results for their productivity and happiness. This shift acts as a forcing function to support asynchronous communication, better distribute the workload, and accelerate the adoption of team norms to socially include all members.

One of our remote engineering teams works on invoices for our billing product. Previously, the invoices team was based out of our San Francisco headquarters. Over the last year, it has expanded to nine members distributed across nine cities and two countries, with an engineering manager based out of North Carolina, three time zones away from headquarters. The team has delivered significant improvements to Stripe’s invoicing products and quintupled their growth.

The invoices team, including one headquarters-based engineer, operates remote-first. Product and architectural decisions are documented in writing, code review SLAs account for time zone differences, and they set aside intentional time each week to connect with one another. Recurring meetings are prized time, as one of the only synchronous touchpoints the team members have together, but if there’s no agenda, the team is ruthless about canceling it. It’s the time slot that’s sacred; the discussions must be intentional. The team embraces ad-hoc meetings and pairing time to unblock decisions or work through complex technical problems.

We have also seen a flowering of cultural rituals. Teams find new ways to take a break together. Everyone might do individual tea orders and then post photos in their Slack channel or snack together on Zoom. Scheduled unstructured hangout sessions have also multiplied. We’ve seen parallel #TEAM-social channels adjacent to most #TEAM-work channels on Slack so that team members have an outlet to post about kids, hobbies, and other watercooler banter subjects without feeling like they’re intruding on a workspace. We’ve also experimented with entirely virtual offsites, particularly the bonding component. One team ran a simulated lunar crash exercise that required participants to collectively identify and rank the most critical tools needed to survive. We do not yet have any extraplanetary remotes (but watch this space).

Better tooling and communication norms have paid dividends. We rely on onboarding to set the tone for an employee’s relationship with the company, their team, and their work. An unexpected benefit to onboarding cohorts of remote engineers was that we got better at supporting engineers everywhere. Our onboarding curriculum became more polished and efficient, given the limited window of the work day shared by regionally scattered remote employees. We moved as many tasks as possible from synchronous batches to asynchronous processing via written documentation, videos, or small groups sharing time zones. These changes reduce the ramp-up time and friction for remote employees, as well as streamline traditional in-person onboarding.

When onboarding gets more efficient and asynchronous, teams can scale independently and at a faster rate. Over the past year, we’ve grown small engineering teams in offices like Tokyo and much larger engineering teams in all our engineering hubs. Those teams have quickly advocated for and brought to market locally-relevant products. Recently, engineers based in Japan and Latin America worked together to enhance local payment rails so that users could receive funds in a few working days rather than a month.

We have invested substantially in internal tooling and explicit communication norms to support the productivity of remote engineers. This includes tooling to coordinate deploys for our most sensitive systems (so that engineers don’t have to synchronously coordinate in-person), incident management tooling which rapidly spins up a virtual response room on demand, and socializing shared scheduled memos rather than daily in-person standups to help engineers stay informed about teammates’ work.

Efforts like these turned out to be critical during our COVID-19 response efforts. We closed all of our offices worldwide and worked to support users going through extremely heterogeneous shocks to their business models, ranging from surges in demand and transactions for delivery startups to cash-flow challenges as demand dried up and refunds spiked for travel companies.

This would have, candidly, been extremely difficult for Stripe a few years ago, and is still not easy by any stretch of the imagination. But we continue to develop and ship new products, thanks in part to an increased focus on supporting remote engineers last May. Earlier this year, we wouldn’t have guessed that early preparations undertaken to support a fraction of our engineers would benefit all our engineers—and the rest of Stripe.

We are tapping pools of candidates we could not reach before. Stripe, like all software companies, depends on having talented engineers from a wide range of life experiences, professional backgrounds, and seniority levels. We have found that increasing our population of remote engineers has helped to improve our company along several of these dimensions.

One demographic we have noticed interact interestingly with remote-friendly policies is engineers with family responsibilities. They often need to make hard choices about which housing markets to live in to support their family and their career. When we had fewer remote roles, we unwittingly narrowed our applicant pool of engineers with families, and missed hiring talented engineers. We also occasionally had engineers leave to favor their partners’ career aspirations, which sometimes required moving away from cities we had offices in. Our expanded ability to hire and retain engineers from many more places enables us to attract many talented engineers who don’t feel that working for us would require unpalatable tradeoffs.

We built our remote hub by initially seeking out engineers with significant experience working remotely; this naturally led us to hire more seasoned engineers. Similarly, we’ve seen anecdotal shifts in the composition of professional experience across engineers. Stripes in San Francisco have often had most of their professional experience at startups or in large consumer Internet companies, because those sorts of companies employ most engineers in San Francisco. We now hire engineers in cities where financial companies, larger enterprises, and agencies hire larger swaths of the engineering population. This helps us incorporate more DNA from their practices and informs how we build products for adoption for those sorts of companies.

Last May, we focused on hiring remote engineers, product managers, engineering managers, and technical program managers. But once we were able to support those roles remotely, Stripes across the company started to transition from working in our offices to doing their jobs remotely. They span teams and seniority, and among their ranks are tenured leaders and engineering interns. (This summer, we’re running an entirely remote intern program for 76 engineering interns.)

There are now hundreds of remote Stripes across our engineering and business teams. Three out of four teams at Stripe have at least one remote worker.

We are increasing our investment

Our experience developing our remote hub this past year has exceeded our expectations. We continue to test and trial remote work across Stripe, but it’s no longer an experiment. We will accelerate our investment in remote Stripes and the growth of the remote hub. Here’s how:

We are broadening the positions for which we will hire remotely. Last year, we intended to hire a mix of engineering individual contributors, engineering managers, and non-engineering technical roles such as product managers and designers into our remote hub. As of the publish date of this post, we now have open, remote roles on our design, legal and marketing teams.

We support this bottom-up transformation with more explicit company-wide direction so that we can meet our goals in remote hiring across technical and non-technical functions alike. We expect the number of remote-eligible roles will continue to grow; changes caused by COVID-19 are accelerating this transition.

We have increased the places we can hire remotely from. Today, Stripes are based in over 50 cities worldwide. We now have the capability to hire remote employees in Australia, Brazil, Canada, France, Germany, India, Indonesia, Ireland, Japan, Mexico, Netherlands, Singapore, Sweden, UK, and the U.S. We’re setting the foundation for remote hiring in many more countries, but are rate limited on hiring remotes in countries where we don’t already have an office presence. In those cases, we need to tackle substantial legal and logistical challenges on a country-by-country, city-by-city, and sometimes neighborhood-by-neighborhood basis. Other organizations seeking to increase remote hires will have to grapple with people systems and disparate tax regimes.

This is a fractally complex project and has variable lead times depending on the jurisdictions involved, where you have preexisting legal or business infrastructure to leverage, and what compromises you are willing to make prior to onboarding employees in a jurisdiction. To satisfy these requirements, companies inevitably need to manage parallel hiring systems to support on-site and remote employees; common standards would accelerate the world’s migration to remote work. As an example, Stripe must be able to issue equity before we make offers in a jurisdiction, whereas many other employee benefits can roll out more gradually.

We are improving the quality of life for remote engineers. We care that all of our employees have a successful experience at Stripe. To gauge this, we run bi-annual surveys. In our latest one, we found that, compared to non-remote employees, remote Stripes are more likely to have a sense of connection to their team, balance their workload and life demands, and stay longer at Stripe. Remote Stripes score lower when asked whether Stripe fosters a sense of connection for employees in their location. However, 77% said that their location is not a barrier to having an impact at Stripe, a 10% increase from a year ago.

Our goal in the coming year is to ensure remote engineers feel at a minimum the same level of impact, team connectedness, and velocity in career progression as any other engineer.

We want to talk to you

We’re looking for new colleagues to join us. Here are the remote positions; more will be added over the coming year.

Do you have questions about our remote engineering hub or its open roles? Our CTO, David Singleton, remote Stripe, Patrick McKenzie (@patio11), and inaugural remote hub site lead Aditya Mukerjee will join us in hosting a remote coffee chat to talk about our remote hub. Sign up to be invited—and don’t forget to share where you’re based. We’ll pick a date and time that accommodates as many attendees as possible.

Like this post? Join the Stripe remote engineering hub. View openings

Stripe is now generally available in the Czech Republic, Romania, Bulgaria, Cyprus, and Malta. This means Stripe can now support businesses in 39 countries (29 in Europe) with our complete payments platform, enabling them to sell to customers around the globe.

Stripe has been investing in our European engineering hub since 2018, and this launch was built almost entirely by those teams. That’s everything from new integrations with financial institutions to extending support for Stripe’s products.

Europe has a thriving startup ecosystem and one of the highest densities of software engineers anywhere in the world. Investing in global engineering hubs closer to users helps us better understand and build for their needs. This launch is the result of feedback from a number of businesses across Europe—MEWS, Ramon Nastase, Aesthetic by Science, and Mana are just a few of the many companies that helped shape this product during its beta phase.

The COVID-19 crisis has accelerated the shift from offline to online commerce, making the need for financial infrastructure and accessibility more urgent than ever. In the past few months, European entrepreneurs in Central and Eastern Europe have already processed hundreds of millions of euros in payments on Stripe. We’re glad we can support these businesses and are working diligently to make Stripe available to every business across Europe.

To mitigate the threat of climate change, the majority of climate models agree that the world will need to remove carbon dioxide from the atmosphere on the scale of approximately 6 gigatons of CO₂ per year by 2050. That’s roughly the equivalent of the United States’ annual emissions.

Last year, Stripe announced our Negative Emissions Commitment, pledging at least $1M per year to pay, at any price, for the direct removal of carbon dioxide from the atmosphere and its sequestration in secure long-term storage. We’ve since built a small team within Stripe to focus on creating a market for carbon removal by being an early customer for promising negative emissions technologies.

Today, after a rigorous search and review by a panel of independent scientific experts^[1], we’re excited to announce our first purchases. Our request for projects garnered a wide range of negative emissions technologies which came in two broad categories.

• Carbon storage in the biosphere: These projects include planting trees or modifying agricultural practices to store more carbon in soil. These projects are relatively less expensive and benefit from immediate scale (we can plant trees today), but have shorter long-term permanence since trees can be easily burned down and carbon storage in soil can be short lived. These solutions alone are unlikely to sustain the necessary 6-15 gigatons of annual CO₂ removal.

• Carbon storage outside of the biosphere: Projects in this more nascent category store carbon in places besides plants and soil. Examples include directly capturing CO₂ from the atmosphere and injecting it into stable rock formations underground or sequestering CO₂ in concrete via mineralization. These solutions are scarce and dramatically underfunded. If they can proliferate and scale, they’ll complement in-biosphere solutions by bringing new benefits: thousand-year or longer permanence and vast carbon storage using minimal arable land.

The world will need a portfolio of negative emissions approaches across these two categories to meet the 2 degree warming target sensibly adopted by many governments. We believe Stripe can make the most impact by focusing our purchases on the latter category to help these solutions improve.

Stripe’s first purchases

From 24 promising applications, we’ve selected four high potential projects that exemplify the kinds of innovation required to advance the field. We’re especially excited to be the first purchaser from three of the four projects. In cases where the projects are still quite early and have low capacity in 2020, we’ve pre-purchased volume for future years.

Climeworks
Capture + storage
Zurich, Switzerland • 322.5 tons at $775 per ton^[2]

Climeworks uses renewable geothermal energy and waste heat to capture CO₂ directly from the air, concentrate it, and permanently sequester it underground in basaltic rock formations with Carbfix. While it’s early in scaling, the capacity of this approach is theoretically nearly limitless. It’s also permanent and straightforward to measure. Climeworks has an ambitious cost and volume curve, with a long-term price target of $100-200 per ton. Though this technology is expensive today, we’re optimistic it will decrease in cost quickly with more early purchasers.

Project Vesta
Capture + storage
San Francisco, USA • 3,333.3 tons at $75 per ton

Project Vesta captures CO₂ by using an abundant, naturally occurring mineral called olivine. Ocean waves grind down the olivine, increasing its surface area. As the olivine breaks down, it captures atmospheric CO₂ from within the ocean and stabilizes it as limestone on the seafloor. This is a compelling approach because it provides permanent sequestration with the potential for very high volume at low cost. Questions remain about safety and viability: to validate coastal enhanced weathering, more lab experiments and pilot beach projects must be performed. Stripe is Project Vesta’s first customer and our purchase will accelerate their safety study and deployment timeline.

CarbonCure
Storage only
Halifax, Canada • 2,500 tons at $100 per ton

CarbonCure’s technology sequesters CO₂ in concrete by mineralizing it into calcium carbonate (CaCO₃)—as a bonus, this has the side effect of actually strengthening the concrete. This solution is compelling because it’s permanent, relatively low cost, and could scale to the size of the global concrete market, sequestering >0.5 gigatons of CO₂ annually. Today, CarbonCure captures most of its CO₂ from industrial emitters such as ethanol, fertilizer, or cement plants. In the future, CarbonCure’s technology could use CO₂ from direct air capture technologies once they become more readily available and economical, forming a full negative emissions technology. Stripe is CarbonCure’s first customer to purchase carbon sequestration, and the transaction will enable them to subsidize their costs.

Charm Industrial
Storage only
San Francisco, USA • 416 tons at $600 per ton

Charm Industrial has created a novel process for preparing and injecting bio-oil into geologic storage. Bio-oil is produced from biomass and maintains much of the carbon that was captured naturally by the plants. By injecting it into secure geologic storage, they’re making the carbon storage permanent. Stripe is Charm Industrial’s first customer for this approach, and Stripe’s purchase lets them begin testing this year.

Open-sourcing our materials

Over the last few months, we’ve brought together experts across a series of disciplines and institutions to guide us. We have published our process, applications, and project database on GitHub to equip other potential purchasers with better information and encourage transparency in negative emissions purchasing.

We’ve also partnered with CarbonPlan, a non-profit that evaluates carbon removal technologies and maintains a public database of project reports with independent analysis and visualization of public data, including each project application considered by Stripe.

Expanding our commitment

Much like the early-stage businesses that get started on Stripe, we recognize that many of the future impactful projects are still quite nascent today.

In addition to reducing our own emissions, and helping projects transition from R&D to commercial deployment by purchasing at any price per ton, Stripe will expand its commitment to advance negative emissions technologies by:

• Funding early-stage research to increase the number of projects with a credible path to achieving ambitious impact.
• Raising money to create a large-scale market for carbon removal. We’ve been encouraged by how many businesses, including many Stripe users, have offered to purchase alongside us. We’d like to make it easier for companies to contribute to the most promising and impactful negative emissions technologies and measure their impact.

We’ve developed a set of project criteria that characterize the kinds of solutions needed to help round out the existing gaps in the negative emissions portfolio. Stripe is excited to support projects that have the potential to achieve these criteria by 2040, even if they don’t yet achieve them today.

We hope that this approach will accelerate technological developments to remove and store carbon at the required scale, cost, and quality level.

Call to action

Our goal is not only to remove carbon from the atmosphere, but to become an early member of an ecosystem of funders and founders who will invent ways to solve the world’s largest collective problem. We continue to search for great projects, purchasers, and experts. Please reach out to us to work together on this effort or to give us any feedback. We can be reached at climate@stripe.com. (And if you’re an engineer or designer who cares about climate impact, consider joining our team).

[1] We’re grateful for our panel of experts who advised on our process, reviewed applications, and provided guidance. Reviewers included Dr. Jennifer Wilcox (Professor, Worcester Polytechnic Institute), Dr. Phil Renforth (Associate Professor, Heriot-Watt University), Dr. Steven Hamburg (Chief Scientist, Environmental Defense Fund), Dr. Jane Zelikova (Chief Scientist, Carbon180), Andrew Bergman (PhD candidate, Harvard), Dr. Bill Anderegg (Assistant Professor, University of Utah), Dr. Colin McCormick, and Dr. Zara L’Heureux.

[2] Climeworks Carbon Dioxide Removal pricing conditions are a function of various parameters, one being the volume of the purchase agreement.

Stripe Billing is designed to be the fastest way for ambitious businesses to set up recurring subscriptions or one-off invoices. Companies such as Slack, The Atlantic, Notion, and Postmates use Billing so they can focus their engineering resources on their core business instead of building and maintaining a subscription-management system. And they get key advantages because Billing is deeply integrated into the Stripe payments stack—for example, our customers recovered 41% of failed payments last year through automatic card updates, smart retries, and other included capabilities.

Over the past few months, we’ve added several new features to Stripe Billing to help you support more business models, shave time off of your operations, and let you bill customers globally with advanced invoicing features:

More flexible billing logic

• Subscription schedules: With subscription schedules, you can more easily configure changes to subscriptions, including starting a subscription on a future date, backdating a subscription, or upgrading or downgrading a subscription on a future date.

  

• Sub-cent billing: Decimal amounts for pricing let you charge unit prices of a fraction of a cent for a subscription or invoice. For example, a cloud storage SaaS business might want to charge $0.0005 per MB used.

• Subscription pending updates: Pending updates let you make a change to a subscription only when a payment succeeds. For example, if your customers add a seat or upgrade to a more expensive plan, you can now charge them a prorated amount right away (or restrict access to your service if the payment fails).

Shortcuts to save you time

• MRR by product and plan: The Billing analytics dashboard provides time-saving charts and analytics right out of the box so you don’t have to spend time building them yourself. You can now view monthly recurring revenue (MRR) by specific products and plans to measure the health and trajectory of distinct parts of your business.

  

• subscription.new and invoice.new: Does your team create a lot of invoices or subscriptions from the Dashboard? We added some shortcuts. You can just type subscription.new or invoice.new in any browser to save a few clicks.

  And once you’re there, Billing’s new invoice and subscription editors are faster to use and let you create customer records in-line. Saving just a few seconds for each transaction adds up fast for your operational teams.

Customized and compliant invoicing

• Send invoices from your own domain: Your business might send a lot of invoices, receipts, and other emails via Stripe. In order to maintain a consistent brand experience, you can now send these from your own custom domain.

• Line item credit notes: We’ve improved our credit notes functionality to make it fast and easy to adjust specific line items on a finalized invoice via the Dashboard or the API. This helps keep your records accurate and gives you an easy way to issue refunds or credit customers when an invoice changes.

  

• Flexible invoice numbering: Invoices can now be numbered sequentially across your entire account—this is particularly useful for businesses that have to stay compliant with local invoicing regulations in Europe. If you’re migrating from an older invoicing system, you can start with any arbitrary invoice number to continue an existing sequence.

  

We’ll continue to add features to Stripe Billing that give your business flexibility as it grows. To get started with Billing, visit the overview—you can use all of these new features either from the Dashboard or via the API. As always, please let us know if you have any questions or feedback—we’d love to hear from you.

Millions of businesses rely on Stripe to accept payments safely. Our goal is to help those businesses maximize payments from legitimate customers, while minimizing their losses to fraud.

Online fraud causes unnecessary losses for most online businesses; for some, it can be so expensive that it threatens their viability. Accordingly, Stripe has been investing in industry-leading fraud prevention technology since 2015. Radar uses advanced machine learning (optionally augmented by human-supplied rules) to shield Stripe users from hundreds of millions of dollars of fraudulent transactions every month.

As the online economy grows, online fraud is becoming more sophisticated, and Stripe dedicates large teams to improving Radar’s accuracy and building defenses that better-protect Stripe users.

As part of Stripe’s fraud prevention, we use fraud signals detected by Stripe.js and our mobile SDKs. These signals are most commonly used to identify “bots”—scripted web browsers that make fraudulent transactions. Signals we pay attention to include things like screen resolution and browsing patterns. Stripe’s ability to use these real-time signals is part of why Radar is so effective: in a domain where even small improvements can be a big deal, they reduce the expected number of fraud-driven chargebacks a business will receive by 11%.

In response to some recent questions about how we use signals gathered via Stripe.js and our mobile SDKs, we have made some updates to provide additional clarity:

• We updated our privacy and cookie policies to make it clear that our advanced fraud detection signals are used only for security and anti-fraud purposes. Stripe doesn’t—and won’t—share or sell this data to advertisers.
• We put up a page with more details about the advanced fraud detection signals we collect.
• We’ve added the ability for site and app owners to disable advanced fraud detection signals.

We hope these updates make our commitment to our users even clearer. If you have any questions, please don’t hesitate to reach out.

Stripe Issuing is an API that allows you to create and control virtual and physical cards. Today, we’re opening access to all businesses in the US, so you can sign up and start creating cards instantly.

We built Issuing to help businesses manage how funds get spent. Companies like Zipcar want to help renters fill up the gas tank without using their personal cards. Companies like Postmates want to help couriers pay for orders without allowing unapproved purchases. These businesses couldn’t just hand out corporate expense cards—they needed to create their own cards.

The card issuance industry today looks a lot like what the payments industry did a decade ago—it can take months to integrate to a provider and manufacture cards, only to get rigid capabilities on a legacy stack. We set out to launch the first issuance platform built for developers. Our self-serve APIs and public docs give developers the tools to build the unexpected. We even created a new manufacturing process so businesses can customize physical cards from Day 1.

Now, any US business can instantly launch a commercial card program, right from their Dashboard, at no cost to get started. And Issuing comes packed with capabilities that ensure that any business—from a new startup to a tech giant—can build flexible cards with our APIs.

Pricing

Issuing has everything you need to create a card program, with no setup or monthly fees. Create virtual cards for 10¢ per card and get branded physical cards shipped to your door for just $3 per card. We’ll waive transaction fees for the first $500K in transaction volume—after that, each card transaction costs 0.2% + 20¢. For companies with large volume or unique business models, custom economics are available.

Any business in the US can now activate Issuing from the Dashboard to instantly launch a commercial card program. If you’re outside the US, you can get notified when Issuing is available in your country. If you have any feedback or questions, we’d love to hear from you.

Stripe Issuing cards offered under this program are issued by Regions Bank, an Alabama FDIC-insured state bank.

Card Issuing services may require approval and are subject to terms and conditions.

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.

We provide our risk analysts with automated tools to make informed decisions while sifting legitimate users from potentially fraudulent accounts. One of the most useful tools we’ve developed uses machine learning to identify similar clusters of accounts created by fraudsters trying to scale their operations. Many of these attempts are easy to detect and we can reverse engineer the fingerprints they leave behind to shut them down in real-time. In turn, this allows our analysts to spend more time on sophisticated cases that have the potential to do more harm to our users.

Read more