Dan(ClassFit)-question

[mild wharf]

Let's chat here

[granite goblet]

Hey Hanzo

Can we add @hazy cipher too please?

[hazy cipher]

hey , i am here

hey @mild wharf

[granite goblet]

OK great. So we've had a couple of conversations with Stripe on Discord that is making us feel like we're missing something.

I'm the product owner, Shimaa is the developer.

Let me catch you up quickly.

Situation

We're using Stripe Express on our platform. Our platform is for class instructors (yoga etc) to take bookings for their classes. These instructors take money from their clients for these bookings. When refunds are made, all parties involved expect that the class instructor will be the party refunding their client.

Problem

In some instances, the class organiser has paid out all of their Stripe funds to their bank account. They then refund the customer assuming they will be liable for this, but it seems as though Stripe's default flow is that the refund is taken from us, rather than the class organiser.

Proposed solution

We understand that Stripe's placed the platform as ultimately responsible for refunds, but we want to make sure this is the last possible option, as all parties involved will expect the person who took the money, to also be the person who refunds the money. We're trying to achieve something like the below:

1. Refund from merchant's Stripe account
2. If failed - Refund from Merchant's connected bank account
3. If failed - Refund from merchant's payment card on file
4. If failed - alert merchant that refund has failed and they need to top up balance and try again.
5. If customer complains to bank, ultimate responsibility for the refund lies with us as a last resort.

Right now we skip from 1 to 5 and that's killing our business model. I spoke to someone here before and he said we could create this flow ourselves, but when @hazy cipher has asked for support on how, she seems to have now been told this is impossible?

@mild wharf does this make sense?

[mild wharf]

hmm give me a moment to parse this 🙂

(Correct me if I'm wrong but want to make sure I'm on the same page)

• You have a Express Connect Platform using Destination Charges
• Refunds are debited from Platform account balance
• You want to create a flow that makes connected account responsible for refunds

[granite goblet]

Refunds are debited from the connected account as default, but only if they have the appropriate balance. If they don't have the appropriate balance then we get stuck with the bill straight away. We want to build some extra layers between these 2 actions so we're not paying for our merchant's refunds just because they happened to have paid out recently. Make sense?

[mild wharf]

Ah hmm. Interesting.
What kind of charges are you using w/ your integration?

[granite goblet]

Can you clarify? Or @hazy cipher can you answer that?

[hazy cipher]

Destination charges

stripe.Refund.create("reverse_transfer"= true,"charge": charge_id)

this is the refund Api used

[granite goblet]

Sure so if we reverse the transfer, we get the money back from the merchant. But this only works if their Stripe account has the appropriate balance right?

We're trying to put contingencies in place to ensure if they don't have the appropriate Stripe balance the flow doesn't direct straight to our balance.

[mild wharf]

Gotcha. Okay I understand now.
Let me think

I was under the impression that Stripe will try to debit external account on file for these connected accounts as when they don't have a balance and a refund is issued, it would create a negative balance
https://stripe.com/docs/connect/account-balances#accounting-for-negative-balances

[hazy cipher]

For Express and Custom accounts, the platform is ultimately responsible to cover negative balances. this quoted from this link

we are using express accounts

[mild wharf]

I know, it says ultimately which makes me think when the attempt to debit the external account fails

[hazy cipher]

this leaves our platform to cover the refunds

[granite goblet]

"ultimately" yes. We're trying to build in some buffer room though.

[mild wharf]

gotcha.

[granite goblet]

So is it possible to build a flow that goes through these steps

To create some real buffer room

1. Refund from merchant's Stripe account
2. If failed - Refund from Merchant's connected bank account
3. If failed - Refund from merchant's payment card on file
4. If failed - alert merchant that refund has failed and they need to top up balance and try again.
5. If customer complains to bank, ultimate responsibility for the refund lies with us as a last resort.

[mild wharf]

Not sure if you can refund directly from merchant's bank account

Have you looked into account debits?
https://stripe.com/docs/connect/account-debits

ah well, it'd have the same contingency where platform is ultimately responsible

[granite goblet]

We're OK with the platform being ultimately and legally responsible. We just seem to jump the gun and get to that point prematurely.

[hazy cipher]

we tried this before but it is not functional

most of our connected accounts not in the same region as the platform account and not in the same currency

[granite goblet]

"Stripe may auto-debit the external account on file."

Does external account mean the merchant's bank account, or the platforms account?

[mild wharf]

connected account's bank account

[granite goblet]

OK great. 99% of our merchant's and their clients will have the same currency as they're mostly local services. How can we do this?

Wait. it says the connected account and platform must be in the same region too. So if we're in the UK this wouldn't work for US customers?

[mild wharf]

Yeah that won't work

[hazy cipher]

Yes, we tried that before
it won't work

[granite goblet]

So as we are, if a client has an empty Stripe balance, we're still stuck paying their refunds. I'd like to hope everyone agrees that isn't what people would expect. So how can we work around our platform being an immediate plan B?

I also think this process is highly, and easily hackable.

1. Create merchant account
2. Create client account
3. Client buys expensive services from merchant
4. Merchant pays out all funds (zero Stripe balance)
5. Merchant initiates refund (which platform pays)
6. Rinse and repeat.

I think you could easily clean out any platform using Stripe express doing that, and from what I can tell it's totally allowed?

Can we reject a refund if the balance is at zero, and provide a way for the customer to add the appropriate funds to their balance before the refund is initiated. So rather than directly trying to pull funds from their various sources, we ask them to add funds to their Stripe balance first?

[mild wharf]

You could but the end-customer may file a dispute or a chargeback request

[granite goblet]

I don't think we will ever get away from that eventual conclusion

We just want to be plan Z rather than plan B. And we don't want to have someone figure out the process I outlined above to quickly, easily and possibly legally take all of our funds.

So if an action is initiated that requires refunds > merchant Stripe balance we can tell the customer no refunds will be made until they top up their Stripe balance is that correct?

If so does Stripe have a prebuilt mechanism we can use for the merchant to top up their Stripe balance?

[silent wraith]

👋 stepping in here and catching up

Have you already implemented Express?

Like really here you should be using Standard.

Express is designed for you as the platform to have control and thus to be responsible for refunds/disputes.

If you don't want to be the one liable, you need to be using Standard Accounts.

There is no real workaround for that.

[granite goblet]

We implemented Express based on the recommendation of one of your sales team

We're happy to be ultimately liable, but we're really looking for more of the "control" you're speaking about

right now we don't seem to have any

[silent wraith]

Well sure you have some

You can control the payout schedule of your Connected Accounts for instance

[granite goblet]

We are automatically paying for merchant/client refunds if their Stripe balance is empty.

So regardless of when the payout is scheduled for, we're pretty stuck if a refund is initiated the day after that happens.

And client's expect to be able to control this themselves.

As mentioned above, the whole setup seems easily hackable. I'm non-technical and I'm pretty sure I outlined a way to empty any platform's bank account using Stripe Express, so I'd imagine you must have some protection in place to mitigate this?

[silent wraith]

I'm sorry I don't understand what this means.

[granite goblet]

1. Create merchant account
2. Create client account
3. Client buys expensive services from merchant
4. Merchant pays out all funds (zero Stripe balance)
5. Merchant initiates refund (which platform pays)
6. Rinse and repeat.

I think you could easily clean out any platform using Stripe express doing that, and from what I can tell it's totally allowed?

If I've understood that correctly, and this is a genuine risk, I would have thought Stripe would have some from of protection in place for this?

[silent wraith]

Yeah that's not really possible. We require you to have a debitable bank account and we only allow you to refund to a certain negative balance amount before we disable refunds.

Also as mentioned before, there are ways for you to build in a buffer if you want to do so.

For instance, you could use separate charges and transfers instead of destination charges if you want to

Then you can hold funds on your platform for refunds before transferring if you so desire

Or you can use manual payouts on your Connected Accounts

But really what you are talking about is how Express works — you as the platform handle refunds/disputes.

[granite goblet]

OK great, so let's understand these buffers better as that's really what we're trying to put in place. I'd love to circle back to the below point too after please.

"But really what you are talking about is how Express works — you as the platform handle refunds/disputes."

[silent wraith]

Okay so why don't you outline exactly what you want to accomplish and I can try and help talk you through ways you might go

[granite goblet]

So what I've suggested so far is below:

1. Refund from merchant's Stripe account
2. If failed - Refund from Merchant's connected bank account
3. If failed - Refund from merchant's payment card on file
4. If failed - alert merchant that refund has failed and they need to top up balance and try again.
5. If customer complains to bank, ultimate responsibility for the refund lies with us as a last resort.

Right now we skip from 1 to 5 and that's killing our business model.

[silent wraith]

I assume you are reversing transfers when you refund?

[granite goblet]

Yes, which is all good when the Merchant's Stripe accounts have the appropriate balance.

[hazy cipher]

yes we do so

[granite goblet]

The issue is when they balance is less than the refund amount.

Then it jumps straight from step 1 to step 5 (as listed above), and we'd like to build in some "buffers"

[silent wraith]

Okay. So would you consider using manual payouts where you maintain a certain buffer balance in your Express accounts?

Or maybe you only do that for accounts that are new(er)

And once they show they are "trusted" you assume they will take more funds in the future to repair any negative balance that is accrued

[granite goblet]

Client's won't like that. They're used to automated and easy, we can't be the platform that asks them to move to manual and clunky

It's not about trusted

That's the issue here

We're not worried that people are abusing the system here

[silent wraith]

Do you have the debit negative balance flag turned on for these Connected Accounts?

[granite goblet]

We're worried that people are genuinely initiating refunds, assuming that they will be the one repaying their customers, but not realising that their Stripe balance doesn't cover it. Then it's just on us to pay their refunds with no buffer.

[granite goblet]

@hazy cipher ?

[hazy cipher]

i am not sure

[silent wraith]

https://stripe.com/docs/connect/account-balances#accounting-for-negative-balances

[hazy cipher]

do you mean this flag ?

[silent wraith]

Yes

What country(ies) are your Connected Accounts in?

[granite goblet]

Lots. Predominately UK US AUS CANADA, but probably 50 or so now.

To clarify the use cases a bit more.

• Merchant pays out. Stripe balance = 0.
• Client cancels a booking. System automatically refunds client based on refund policy agreed.
• Platform ends up paying for this refund.

Nobody involved expects this to be the case. Everyone expects the merchant to to cover this cost, but might not have considered the logistics of it.

[silent wraith]

The merchant "covers it" by you reversing the transfer.

Yes that will send the Connected Account negative at times.

This is expected.

Then that balance will attempt to be repaired in the future, either through a debit, or through future payments.

There is indeed risk here, as with any business.

[shrewd briar]

As a user: for my flows, using separate charges & transfers, the funds are NOT tranferred to the seller until services are delivered - especially since cancelling appointments is so typical

[silent wraith]

If you onboard a fraudulent merchant then it is possible you end up responsible.

[granite goblet]

Again we're really not worried about fraud here

[silent wraith]

Then I'm sorry, I really don't understand the issue.

[shrewd briar]

Customer could still ask for a refund (bad services, for example), but it will be much less common

[granite goblet]

Example.

A client stopped using ClassFit. They didn't close their account and they left one membership renewing, presumably by mistake. The merchant was receiving these funds and paying them out to their bank account automatically, likely without noticing.

A few months later, the merchant has realised this, and refunded their client ($500). Because their Stripe account was empty, the platform covered this cost. But because the merchant was no longer receiving any other fees through the platform, that negative balance was never going to be recovered.

I very much doubt the merchant was trying to scam anyone here. But the end result was still us paying the refund, and having no means of recovering it. Stripe's suggestion here was reach out to client who hasn't used us in months, and ask them to send us a bank transfer.... It's not ideal. We're looking for something to safeguard against this type of situation.

[shrewd briar]

As a business owner myself, it seems to me your issue is not monitoring your accounts, especially for that use-case.

[granite goblet]

It's just not possible.

[shrewd briar]

IF they are Express accounts, you should be able to prevent them initiating refunds - they should make a request through your platform to request a refund be executed, at which point your business operations would step in.

[granite goblet]

Our target market is startups. We have frictionless sign ups and crazy low fees that makes a ton of manual monitoring not possible. This is the case now, we're hoping to substantially scale. So swapping frictionless for manual just isn't feasible.

[shrewd briar]

then may I humbly suggest you change your business model? Large volume, crazy low fees with unbalanced risk isn't going to scale well

But the above suggestion would still be generally feasible - connected account requests refund; your software checks balances before issuing refund; in the exception of no balance (or pending balance) available you flag a separate process

[granite goblet]

You can suggest it, but we're not looking to do that. We're differentiated in a crowded market because we're so cheap and frictionless. The alternative won't scale at all.

Upending our entire business model because we can't immediately find an answer to this question isn't plan A here.

[granite goblet]

Yeah so that's what we're asking about here.

Right now we go from

1. Merchant doesn't have funds
2. Platform covers the bill

We want to build in some buffers, which is what the merchant's would expect.

I certainly would.

if you have access to 3 payment methods of mine, and you give up after 1, that's on you.

And that's what we're doing here.

1. Stripe balance is Empty. Skip to 4.
2. We have their bank details. Let's ignore it.
3. We have their payment card on file. Let's ignore that too.
4. The platform can pay it.

This seems bonkers to me. When we've asked clients to repay these fees before, they've made it clear it was bonkers to them too.

[shrewd briar]

Um... you'll note in the process I mentioned, the connected account DOES NOT INITIATE THE REFUND. They request the platform to do it - so no draw-down of balances occurs until you, as the platform, decie it's feasible

[granite goblet]

Yeah so that's one option we've asked abotu

Above in this chain

[shrewd briar]

your steps 2 & 3 involve you setting up the accounts as both Connected accounts (payout) and customers (making payments)

[granite goblet]

It's better than what we have now, but not perfect. There are components required which I asked about but didn't get an answer on.

So 2 and 3. It sounds like it's doable from what you're saying. So how do we do that?

[silent wraith]

You cannot charge a refund directly to a Connected Account's external account.

That is impossible.

However what @shrewd briar is talking about is retrieving the balance of the Connected Account when you go to issue a refund.

This is easily done via the API: https://stripe.com/docs/api/balance/balance_retrieve

So you can programmatically check on the balance of the Connected Account

[granite goblet]

Sure. So we can block it.

[silent wraith]

Correct.

[granite goblet]

And that's helpful

[silent wraith]

Also, you allude to having the Connected Account's "card on file"

[granite goblet]

Yes

[silent wraith]

Are you saying that you collect their payment details on your platform?

If so (or really if not), this is another potential workaround here.

[granite goblet]

Sometimes. It depends if they pay for other services.

But we could mandate it if it solves this issue.

[silent wraith]

You can collect their card details when you onboard them, then you can charge them if necessary.

[shrewd briar]

..Or send an invoice

[silent wraith]

For all of these cases though, you must remember that disputes are in the hands of the customer.

[granite goblet]

We're talking about ex-customers, globally. Invoice payment rates will be low.

[granite goblet]

I'm cool with that. There's a big difference between a client not paying an invoice if they think they can get away with it, and lying to their bank about whether or not they should have paid it.

[shrewd briar]

From your Stripe account perspective: not so much a difference - banks generally just want things "out of their hair"; they really aren't all that good at listening to dispute challenges

[granite goblet]

Agreed. We've told Merchants basically not to bother. We've provided emails from clients saying they raised the dispute in error. Still lost. Nobody at banks seem to read any evidence provided.

BUT. Ignoring an invoice, and lying to your bank will have massively different rates.

[shrewd briar]

..hence why bismark mentioned it - it isn't much more likely to recover funds. Since ANY charge at ANY time can be challenged, the only way you could "protect" yourself is to never transfer/payout any funds, ever... which isn't quite what you're looking for.

[granite goblet]

OK so I think we're getting somewhere here.

1. Refund initiated. Stripe balance insufficient.
2. Attempt to debit from merchant bank account - We can't do this?
3. Debit funds from payment card on file, before refund is initiated - We can do this?
4. Block refund and contact the customer telling them they need to add funds to their Stripe account to cover the refund before it will be processed. We can do this?

Is this correct?

[shrewd briar]

This is a universal business risk - which is why we usually model the expected refund/dispute rates based on typical industry #'s, and make sure the fees we do collect are sufficient to reasonably cover the possible losess. There will always be losses.

[granite goblet]

I get it. Losses are unavoidable. But we're looking to minimize them here.

[shrewd briar]

1. Refund requested. Stripe Balance insufficient. Do NOT initiate refund
2. Contact seller, request either funds in their account (which they may not be able to do)
3. Charge card/account on file, as a Customer. Seller could challenge this as dispute

But in the end, if a dispute occurs, it will come from your account. Full Stop. The use case you gave, the seller is no longer your user. Other than a legal case, you have little recourse.

[granite goblet]

It looks like we're getting the available components now. I'm trying to make the flow more seamless for the customer. I'd like to do everything we can from our side, before request they do things manually.

[granite goblet]

I get this. I've said I get it several times.

[shrewd briar]

(all of this is orthogonal to Stripe's services. Just the nature of Payment Processing)

[granite goblet]

So on step 2. Are there any stripe services or components that make this more user friendly to the customer.

I.e.

1. They are on our platform.
2. They issue a refund.
3. We create a popup stating they don't have enough funds to cover this and need to top up.
4. How do we make it easy for them to top up?

(Through Stripe)

[shrewd briar]

IF they have an associated "payment account" (Stripe terminology "customer"), you do the same as you would for any paying customer - you initiate a payment process.

I'm not aware of an API call for a Connected Account to "top up", honestly

(and I think the whole "top-up"concept is US-only, anyway)

[granite goblet]

When I say top up, I'm thinking like PayPal's ability to add funds to a wallet.

[shrewd briar]

That's OOB (out-of-band) for Stripe

[granite goblet]

So we take money from their debit card and add it to their Stripe account? And there wont be any issue with the user being both the merchant and client?

[shrewd briar]

That's what I mean by out-of-band - there is NO association in Stripe between the two. You can account for it outside of Stripe - your account loses the fund for the refund; they "Card on File" is charged and some amount after fees goes to Platform account.

Huh, although...

Not sure of "legality" here...

[granite goblet]

I'm guessing legally this is all civil rather than criminal law, so we can just update our terms to cover this.

[shrewd briar]

...But if their "payment account" (Customer) pays to their Connected Account, which is set to manual payout, you could, I suppose, then refund from that balance

[granite goblet]

I can also do some digging through a friend in the FCA

[shrewd briar]

Oh, this context I mean "Payment Processor Regulations", not court

But since you can charge for services, separate from processing payments for them, it seems maybe sorta OK - I'd worry about the "self-dealing" appearance of the flows

[granite goblet]

So is it better to :

1. take funds from the customer's payment card to the **customer's **Stripe balance before issuing the refund from the **customer's **Stripe balance.

Or

2. take funds from the customer's payment card to the **platform's **stripe balance and issue the refund from the **platform's **stripe balance.

Is there any difference?

On the surface they appear to achieve the same results, but I assume there is a difference or best practice?

[shrewd briar]

Let's try to separate "customer" from "Connected Account", just to be clear. But you are far outside of "best practices", here, so whichever works for your accounting. Not moving the funds from the Connnected Account's associated payment method to the Connected Account's balance seems to avoid the appearance of money-laundering

[granite goblet]

OK, so the less bad practice would be to move the refunds to the platform and the platform to issue the refund. Got it.

[shrewd briar]

IANAL, and NOT with Stripe, and all the other caveats, of course

[granite goblet]

So to recap.

1. Refund > stripe balance.
2. We can automatically debit the merchant's payment card to cover said refund amount.
3. If #2 fails we can contact them to let them know that the refund will be placed on hold until their Stripe balance covers the refund amount. The only way for them to do this is by updating their debit card details as in #2. Is that correct?

[granite goblet]

You're not with Stripe?

[shrewd briar]

Nope, not with Stripe. Active user/developer than understands both business and tech. At some point you'll have to make the decision to refund the customer before it turns into a Dispute.

[granite goblet]

If it comes to that I'm happy to take that risk. I just know that ignoring a bill is very different to going into your bank and lying on the record. If you want you can do it, but the rates will be highly different.

[shrewd briar]

But your process, such as it is, is about the best I can think of to try to recover.

Note: I am not endorsing the solution as a good solution - just an approach that matches what you are trying to accomplish.

[granite goblet]

Yeah I get that.

What I like about Stripe is we collect our payments at source. We aren't invoicing and chasing small businesses each month. It's safe and successful. I'm trying to apply that same logic to refunds.

@shrewd briar thanks for your help. Especially given you had no obligation to.

@silent wraith DO you agree with the below:

1. Refund > stripe balance.
2. We can automatically debit the merchant's payment card to cover said refund amount, before we issue any refund.
3. If #2 fails we can contact them to let them know that the refund will be placed on hold until their Stripe balance covers the refund amount. The only way for them to do this is by updating their debit card details as in #2. Is that correct?

[silent wraith]

Yes that would be a fine flow.

I wouldn't recommend it... I think you will encounter disputes

But you can go that route if you wish

[granite goblet]

Sure. but worst case scenario with this, is the best case scenario with what we already have in place.

Is there a better solution you would recommend?

[silent wraith]

I would likely issue the refund immediately, attempt to recover the balance through future payments or an external account debit (for those Connected Accounts where we can debit), and then after a certain amount of time I would charge their card on file if needed.

[granite goblet]

Can you clarify this part please.
**
for those Connected Accounts where we can debit), **

[silent wraith]

That references the debit_negative_balances flag that we discussed earlier

[granite goblet]

SO as a UK platform we can do this to UK customers using GBP. But not others correct?

[silent wraith]

No, it states in our docs This functionality works only for banks located in Australia, Canada, New Zealand, and the U.S.

So it won't work for your UK Connected Accounts

[granite goblet]

OK and because we're in the UK it won't work in the countries you've listed either, because we need to be there?

So it won't work for us anywhere right

[silent wraith]

Your platform country doesn't matter

[granite goblet]

OK

SOrry I must have misread

So basically the flow would be

1. Refund initiated
2. Check Stripe balance covers refund amount
3. If Aus, Canada, NZ or US customer debit bank account
4. If #3 failed or non UK/GBP debit payment card.
5. If #4 failed contact customer asking them to update payment card details to fund refund.

Possibly with some from or risk check done before step 3, if we can work out an appropriate one.

Does that work?

[silent wraith]

That seems good to me.

You may want to consider collecting bank debit payment methods instead of cards to charge as fees will be much lower.

But that is up to you

[granite goblet]

Is that something we can do through Stripe Express

[silent wraith]

What do you mean?

You are collecting these details as if they are a Customer (not a Connected Account) in this case.

So Express doesn't matter here.

[granite goblet]

So every payment we take via Stripe is via a payment card. We don't take any payments via direct debit - if that's what you mean?

[silent wraith]

Yes that is what I meant

That's fine. If you don't want to implement direct debits then just use cards.

Was just pointing out that there are lower fees for direct debits.

So it could help to minimize the fact that you are going to be hit with a processing fee when you do charge these Connected Accounts to recover their balance.

[granite goblet]

Actually It's worth picking up for sure. But I imagine that's a different conversation with my sales rep too as we had a specific agreement a while ago.

OK Perfect. I think we have all we need. I think @hazy cipher may have gone now. Is it possible to leave this thread open for 24 hours so she can review it tomorrow please?

[silent wraith]

The thread will be archived but if you pop back online we can always re-open it, just ask!

You should also still be able to read it when it is archived

[granite goblet]

Perfect - thanks so much for your help

[silent wraith]

👍