228 karma · joined August 7, 2012
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.
Edit: made "connected accounts" lowercase.
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.
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.
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.
* 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.
0. https://stripe.com/treasury#request-invite
edit: added a space
We're actually launching something next week. Stay tuned!
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 tara@stripe.com, or just reply to the email you received earlier today!
(edit: quick grammar fix!)
Edit: you can also email me at tara@stripe.com if you'd prefer!
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.
On high decline rates -- Of course, we're hoping Smart Retries and automatic card updater help you here without any additional work on your side. That said, drop us a line! There's actually quite a few things you can do on your end to minimize declines (pass us the right information at the time of charge, segment your decline reason codes in Sigma, experiment with trials, etc.) that can help reduce passive churn. (Docs on declines here: https://stripe.com/docs/declines)
Excited to check out Cheddar when it launches!
More broadly, we believe in revenue-based business models because it's the clearest way to align our incentives with those of our customers. We want to be forced to find ways to generate more revenue, via smart recovery, better invoice payment methods, more payment method support, etc.