Of course, neither Stripe nor users of Stripe Treasury would be launching a bank, but you could provide financial services for other businesses, entirely powered by Stripe Treasury and Stripe Connect. It's pretty analogous to what Shopify is doing with Stripe Connect, Treasury, and Issuing to launch Shopify Balance: https://www.shopify.com/balance
Stripe Invoicing is purpose built for exactly that problem: serving enterprise customers who don't want to use a card for payment. While I think Treasury or Treasury+Connect could help in a pinch, Invoicing is likely the best solution with the smallest implementation lift.
We definitely want platforms to make money on Treasury - there’s a lot of flexibility in how platforms can structure monetization (and revshares are totally possible) so please contact us to talk more about how this works.
With respect to customer service for the end customer, this follows the same process as Stripe Connect. Depending on the type of connected accounts you choose, you can have either Stripe take on customer support for you entirely, or manage customer support yourself. While our bank partners power this product, they’re never interacting with end users at all: that layer, from a customer support perspective, is abstracted by Stripe.
Stripe isn’t a bank either! We hold various financial licenses and partner with a number of large global banks to power Stripe Treasury. That said, you can definitely build atop Stripe Treasury to offer your customers fintech services, so that they can perform all of their money management needs on your product. Though we’re interested in helping entrepreneurs build financial services for many use cases, today we only support businesses (which includes sole props!)
To the point of legal requirements -- there are absolutely a lot of legal requirements here, but Stripe Treasury abstracts a lot of the complexity of those requirements and makes it easier for you to comply than if you had to go at this alone.
There are many financial services companies which are supportable. For example, Clearbanc, a financial services company, uses multiple Stripe products. We try to help users by offloading some of the regulatory and compliance work to us, but as you are aware regulation in financial services is complicated and nuanced. I can’t speculate on each possible use case serially, but we’re interested in hearing specifics and trying to support more legitimate fintech businesses versus less with this product.
As for handling exceptions on individual transactions: this is something which Stripe does very frequently with respect to our Stripe Connect users. For example, we might need to inquire about a large payment made over a Stripe Connect platform, particularly if it appears out-of-character for their usage or for that platform. (We might have questions about a million dollar “pizza” order.) Depending on our specific business relationship with the platform, the flow might be the platform reaching out to the customer for documentation, it might be the platform reviewing information provided contemporaneously with the transaction, it might involve us reviewing metadata on the transaction, or it might involve us reaching out to the user.
Depending on the specifics of what a platform does, it might have internal compliance or fraud teams. Many of our large platforms do; we interface with them (and create interfaces for them) to maximize their effectiveness and minimize silliness.
Stripe Treasury currently supports businesses whose customers make business use of the platform. We are interested in innovation in personal financial services, too, but see more need currently from B2B platforms. We will see how things develop as we improve this offering!
We absolutely want platforms to make money on Treasury and our other financial services products (Capital and Issuing.) For our Issuing and Treasury products, contact us to talk more about how this works -- there’s a lot of flexibility in how a platform can structure monetization. For loans, it’s more immediately straightforward: you’ll earn a revenue share on all loans extended, with zero financial liability on credit losses.
Money management accounts created with Stripe Treasury can send bill payments, which depending on the payee may be delivered entirely electronically or as checks. We have no current intentions of making printable paper checks a feature, but please get in touch if you have a compelling use case for that that isn’t solved by online bill pay.
The accounts can also do both push and pull ACH payments.
While we do not currently support depositing checks into the accounts, we expect to soon, via “remote deposit capture.” You may have seen this sort of experience in mobile applications for many U.S. banks the last few years: take a picture, check gets deposited. If we offer this, we will do it in a fashion which minimizes the engineering work required by the software company, like we broadly try to minimize non-value-creating engineering work for our users.
Here are some of the common use cases we’re seeing so far:
* Bank account replacement for SMBs and sole props, integrated directly into the platform or marketplace they’re already using. For example, today a Shopify merchant earns their revenue on Shopify but then has to transfer funds out to manage overall cash flow elsewhere (e.g., pay bills). Shopify is building Balance [0] with the Treasury API so this user can manage all of this in one place with a single view of revenue and spend. Other benefits of course include faster payouts, rewards specific to the ecosystem, and adding product features enabled by read/write access to the money management data (e.g. you could roll your own invoice reconciliation or alerts, or give users a discount on your SaaS if they ran sufficient volume on your card).
* Open loop wallets, like offering a “spend” account within your product that a user can either use to buy in-product purchases, or use the card/ach/wire functionality to buy external goods. E.g. a car leasing platform for drivers adds Treasury, drivers can use the wallet for discounts on car leases, also use the card to spend on gas.
* Product operations, like having a platform-level Treasury balance you use for reserves, chargebacks, and as glue to make your product flow work. E.g. On demand services marketplace that “buys items customers need and delivers it to their door” can issue cards from a central Treasury balance to their drivers, so that they can use a physical card to buy the burrito for the customer at the restaurant.
...but part of the point with Treasury is that we don’t know every use case prior, just like we didn’t know every way developers would use Stripe Connect (developers are pretty creative!). Our goal was to build for specific use cases, of course, but also build composable enough primitives that people could recombine them in ways we didn’t imagine. We wanted to make a tool that helped unlock developer creativity, because flexible tools were so lacking in the existing fintech infrastructure space.
definitely! we want to make it as easy as possible for existing Stripe Connect users to add Treasury functionality for their connected accounts. Request an invite [0] (the product team is personally monitoring this queue) and let's chat about what you're looking to do!
Hi everyone, I’m Tara, PM on Stripe Treasury. Treasury is a banking-as-a-service API for platforms—built in partnership with the world’s leading banks. Embed interest-earning accounts, bill pay, ACH and wire transfers, and faster access to revenue directly in your platform. Happy to answer any questions here—and I’d love to hear your feedback!
Hey there! I work on Stripe subscriptions -- would love to hear what's been difficult for you today. We're actually rolling out a bunch of changes to make upgrade and downgrades easier and the entire experience more simple. Feel free to email me: [email protected]
(I work at Stripe, specifically leading our subscriptions and recurring revenue product, Stripe Billing)
On a high level, the EU is trying to protect consumers from predatory businesses. We think protecting consumers is awesome. However, by virtue of creating stringent laws to do so, they've inadvertently caught many good businesses in the trap as well.
You're right that the worst case scenario is that you'd need to send an email (or just use the pre-built emails we created/tested/optimized) to your customer every month, for every charge. But it's quite unlikely that this worst case scenario would happen. This is because the regulation allows for exemptions, which means that certain charges don't need to go through 3D Secure2 every time.
Examples of exemptions include regular amount subscriptions (same amount, same interval; only the first charge needs to be authenticated), what's called "Merchant Initiated Transactions" which means that metered/usage based billing can also be exempted, and "merchant whitelists" where customers can just put trusted businesses on an exempted list. The challenge with these exemptions -- the reason we can't 100% promise all of your same amount recurring charges won't have 3DSecure applied -- is that it's up to your customer's issuing bank (e.g. Chase, HSBC, etc.) to apply the exemption at their discretion. We have been interviewing top EU banks in the past months and the vast majority of them plan to exempt recurring transactions when they assess fraud level as low.
We know this is complicated, developing expertise on the vagaries of issuing banks and global regulators is not everyone’s dream job, and is not why you started a SaaS business.
But this is where we have spent time developing expertise, and that's why Stripe Billing wants take care of this for you: we will automatically apply for an exemption whenever it is potentially available, and deeply optimize for recurring related exemptions in particular. We will understand the nuances of different issuing banks, and give them the right information in the network request we make to maximize chances of success. From your standpoint can treat this logic kind of like a black box -- just attempt the charge, Stripe will either tell you it's all good or not. If it's all good, you'll just see a successful outcome. If not, you can then choose to have Stripe auto-send emails and reattempt the charge, or you can do so yourself.
Most importantly: Stripe wants to do whatever is in our power to help SaaS businesses and other subscription businesses succeed. As this continues to develop (and btw, it looks like something like this is going to happen in Australia as well), we've got your back and promise to do whatever we can to maximize your revenue under these regulations.
If you have any other questions, would love to be helpful. Stripe will stay in touch — we’ll be emailing you as changes happen — but you can always email me at [email protected], or just reply to the email you received earlier today!
Hey! I work at Stripe, specifically on helping Saas businesses get started on Stripe. Our goal is to make this as easy as possible for you, but sounds like there are places where it's painful. What are those spots? What can we make better?
(I work on Stripe Billing.) Broadly we think most people should buy rather than build here, because billing is infrastructure and doesn't create the unique value in your product that makes more customers willing to pay. Why is there relatively little OSS for it? Probably because it's difficult to do right, a bit crufty, and tough to motivate a volunteer workforce to wake up in the morning and crank through some tickets about German invoice formatting.
Here's the evolution that we see at a lot of companies as they grow: the table stakes version of billing ("just get something that lets us charge for our MVP!") is an N week project. Everyone gets it wrong, but right enough to not kill the business. Then it worms the way into the rest of their systems, because of a lack of clear design boundaries or a documented internal API to answer questions like "Should account X have access to feature Y?", and it becomes an ongoing maintenance task both for the billing system and all the code which touches it, which is everything.
Once your business gets big, billing isn't just annoying and taxing on your productivity: you have to start telling the business "No, you can't do that, because the billing system won't support it and we can't fix that in less than 6 months." There are products which are not available in Japan because billing systems hardcode currency formats. There are marketplaces that can't tolerate cross-border commerce because they can't accept a pay-in and pay-out with different currencies, as a purely technical limitation.
These are not good problems to have. We think startups should just adopt a billing system which was written by a team of people who breathe billing issues. We feel so strongly about this that we subsidize startups use of our billing product down to free, for their first million dollars in sales.
There, of course, exist other options. As someone who works on this every day: please adopt one of them. You will save yourself a lot of toilsome work which largely doesn't advance your business goals.