Instant Payouts for Marketplaces(stripe.com) |
Instant Payouts for Marketplaces(stripe.com) |
If you normally wait 30 days for your money, but you opt for next day pay for a 1.5% charge on your $100 dollars in receivables, what's the real cost? The provider earns $1.50 for 29 days worth of floating money on your behalf (you'd get in in 30, but you opt for it tomorrow for $1.50).
Now, let's say the company flips the same $98.50 12 times per year. That's earnings of $18 on $98.50, or 18.25% on the company's money...not bad. But wait. What if the company has a strong cash position and can finance the $98.50 at prime, at 90% of receivables (cause that or better is what strong companies can get). Well, then the company needs to borrow $88.65 for the year, at 3.5% per year (prime rate). The company pays $2.66 per year in interest, out of the $18, to earn $15.34 on their initial 10% of the $98.50. So, 1.5% quick pay actually yields the company 15.34 / 9.85 or 156% on their money.
156% isn't a bad ROI.
This has an even better "turn" on money. Basically, it's not getting money today that would take 30 days, it's really getting money today that might take another 5 days. That means there can be 73 turns per year vs. the 12 turns.
This is still much better than a payday loan btw.
This is the killer for us and, I'm guessing, many other marketplaces without a Lyft-sized (20%) rake.
Our current solution for marketplace payouts charges one quarter per payout. The funds are direct deposited in the user's account the next business day. Maybe we have a sweet deal, but to go from this to 1.5%, in addition to Stripe's other (higher than average) fees, is hard to justify. (Which is unfortunate, we'd love to use their great libraries!)
It's unclear how all the pricing works. Does the normal stripe fee occur for the user of the market place in addition to the marketplace fee or does it only trigger when you the marketplace owner receives the payments? Or does it not trigger at all?
During the beta, we've seen many end users choose to pay a fee when they could have waited to receive a slower payout for free. We think the value of this product is in providing choice and giving end users immediate access to their funds when they want it. The stories I've heard from Lyft drivers about the difference it makes to have this flexibility has been my favorite part of working on Instant Payouts.
Thanks!
[0] does it rhyme with holla?
I can say that we aren't processing anything close to Lyft levels of revenue. (I wish.)
Handling information requests: instead of requesting
it directly from the account holder, Stripe will request
information, such as a social security number or passport
scan, from you. You must collect this information from
the user and provide it to Stripe, otherwise Stripe may
disable transfers to the account.
1) it didn’t take all that much work to integrate/support instant payouts
2) of course we at goPanache would rather work directly with our clients to collect barber and stylists info, since the whole point is that Stripe is behind the scenes/invisible to our Barbers and Beauty Professionals.
3. Our Clients- The Barbers and Hairstylist love getting paid same day and even on the weekends.
Two years ago, we tried this at Homejoy as an incentives for the cleaners to get 5 stars.ie. If you get 5's on your appointment, we'll pay you out the same day. We did this manually via Stripe, of course.
Efficacy of the incentive aside (it didn't actually have an impact on 5s), we cut this program for two reasons:
1) Transaction cost, as many users pointed out
2) Unpredictability - most of the workers on our marketplace preferred the predictability of weekly or biweekly payouts, even if the size of those payouts varied. It's hard enough for people to manage personal finances on a regular schedule without the added headache of getting money instantly, or daily.
A question for the Stripe engineers: does this mean we would instantly know if a transfer has failed? One of our biggest pain points right now is when a user enters incorrect account details, we transfer money to them, and the payment is reversed a week later.
And one other question: if we're using balanced transactions to take charges and use them to fund transfers, we still need to wait for the charge to settle right? So in that scenario, "instant" means 5-7 days instead of twice that?
The Visa/Mastercard oligopoly's fee structure isn't Stripe's fault...
EDIT: Gosh - it looks like they're building it around ACH in the US and taking the risk "on us". That's bold. I wouldn't even for 1.5%.
It really depends where the cost is being eaten. Is Lyft eating this or is the driver? Why would anyone agree to a 1.5% reduction in earnings to get their money now instead of tomorrow/2 days?
Will the owner of the marketplace be held responsible for the requirements like maintaining a low chargeback percentage, or is that requirement passed on to the managed account (which could be closed if that becomes an issue)?
https://stripe.com/docs/connect/bank-transfers
Normally it takes a few days for the payment to clear. With the new Instant Transfers option it shows up immediately.
$ flows like this:
X -> Y -> Z
Consumer -> Marketplace -> Provider
Now marketplaces can basically transact from Consumer to Provider instantly. That's huge.
What? It takes a few seconds. Or is this the USA and the USA is different from the rest of the world?
Only in the UK. In the US the average is 2-3% + $0.30
Are you taking about credit?
Within 30 minutes in the worst case. Most failures we would be able to communicate synchronously, such as if the card is not a debit card or the bank doesn't support instant payouts. Some other failures we communicate asynchronously, but ~instantly (e.g. if the bank account behind the debit card has been closed), as we have to reach out to financial partners for that information.
> we still need to wait for the charge to settle right?
Nope, we support instant payouts from the moment a charge succeeds, you do not need to wait for funds to settle in the traditional card-to-ACH sense! Specifically, instant payouts can be made off of an account's "pending" balance, as opposed to the usual limitation of "available" only.
The timing aspect that both of these questions touch on are one of the big features of this launch, and something we spent a lot of time on to get the logistics to work exactly right (there's a lot under the hood there). We're really excited to have something that operates faster than the 2-3 days ACH can take, both in moving money and giving you success feedback.
They just implemented a venmo-style "balance", and taking money out instantly now carries a 1% fee: https://squareup.com/help/us/en/article/5589-where-is-my-squ...
On the plus side, they give you a virtual card that you can use to spend that money, but it's a far cry from "the money is now available in your bank account"
I would argue that the .5% you are paying to use managed accounts would include some sort of "insurance" against fraudulent merchants especially since one would hope Stripe is providing platforms with a similar level of verification compared to standalone accounts.
Ideally platforms would be aware of the differences and make the best decision based on their risk tolerance and UX goals, but after spending a fair amount of time in Stripe's IRC room in the past, people just want to build something and don't always go into the deep documentation listing some of these gotchas.
iirc, Stripe holds the platform liable, so they get paid either way.
So, the question is whether the extra fee they are charging is worth it, since you would be liable for chargebacks anyway?
As for things like chargeback rate, it depends more on your type of business than the particular Stripe product you use. For example, if you are running a shopping cart hosting service, we recognize that each of your stores are different, and will consider them somewhat separately. However, as the direct line to your customers, if you're attracting a huge amount of fraud on your platform, we would expect you to take steps to reduce that, and would work with you to figure out what the best steps may be.
We are working to figure out the best balance between giving platforms control and using our expertise to help them with challenges like fraud. If you have any suggestions on how we could improve this balance I'd love to hear them, either here or via email at bkrausz@stripe.com
> Why would anyone agree to a 1.5% reduction in earnings to get their money now instead of tomorrow/2 days?
I have no idea. I don't live in that world. Sounds like some pawn-shop level need-for-cash to me.
But I do know that in business, factoring receivables is a thing. Dell used to expect vendors (such as Intel, but a lot of others too) to put their parts at the factory and then wouldn't take receipt of the part until it was picked from the bin for the purpose of placing it on the motherboard of a computer that had just been ordered and that they were now assembling. They'd essentially send Intel (or whoever) an email (well, EDI), and say: "Hey, we took receipt of your part. You can invoice us us net 60 now". Maybe it was net 30 - but I think it was 60. They worked out a deal where they'd send these through GE and GE would go to the manufacturers and say: "Dell owes you $10M in 60 days. You can have that (from us) in 30 days for a point and now for 2 points" (These were percentages, not basis points).
IF the vendor had been somebody that wasn't intel (and many were), waiting for 60 days (at least) after delivery of product to a site to get paid is a huuuge hicky on your balance sheet and a big factor in cash flow which constrains inventory turn over and growth.
Doing the volume and time shift of sums of money to allow mismatched transaction parties to match is a (the?) key thing that banks provide. They charge me - on whatever terms they like - to be able to close a transaction with a retail housing unit seller who expects 100% of the full amount today. My alternative would be to save up for 15 years. Most people don't want to do that.
I guess the issue here is that if someone doesn't want to pay 1.5% for that 48 business day hours (including holiday weekends), they'll wait. If they need the money, they'll take the hit.
A couple of common scenarios in the tech industry:
1) You're a web/mobile agency who gets paid on 30 day terms but you need to pay your staff (and contractors) on a monthly basis. If the times line up exactly you might get away with it but if your customer pays late you end up not being able to make payroll. Being able to get the money instantly as soon as you've issued the invoice is a huge peace of mind.
2) You're a software company which sells licences/subscriptions on a monthly basis. If you get that money up-front it means you can redeploy that money straight into marketing which when you're on an exponential growth curve makes a huge difference and is a vastly cheaper form of financing than venture capital (in this scenario we can actually advance up-to twelve months of subscription fees upfront).
3) You have to pay tax based on the amount of money you've invoiced for, not the amount you received to date, so you can easily get a tax bill for which you won't have the money for until your customer pays you. But the taxman won't generally be willing to wait so you have to finance it somehow.
To get an idea of how big a market this is, last year in the UK alone (where we're based) invoice finance was a ~100 billion pound market. A meaningful percentage of global GDP is dependant on this kind of advance.
In terms of cost most companies just build it into their pricing, it's often easier for these businesses to charge their customers more money than it is to convince their customers to pay faster (these are typically large corporates who can spend more but can't stop internal bureaucracy).
I was just re-reading this, and this doesn't sound quite right. Is this a cash-basis accounting vs. an accrual accounting thing?
https://www.gov.uk/vat-record-keeping/time-of-supply-or-tax-...
You can do cash-based accounting and pay only when you receive the payment but this is only available to small companies (<1.35m revenue) and with some other restrictions: