#dan - refunds

1 messages · Page 1 of 1 (latest)

median moth
#

Hello! Just starting a thread for you -- I'll review and respond as soon as I can 🙂

dusky tartan
#

Hey Synthrider. Thanks for the quick response.

median moth
#

Hey there, i can do my best if its related to your integration, sure

dusky tartan
#

We are a platform. We have a connected account acct_1JVHFJPQaeBPkl8R

median moth
#

They are the experts on actual flows of individual refunds/reversals etc

dusky tartan
#

From what I can tell the customer has performed a combination of refunding a payment to their customer, and paying out to themselves at the same time.

#

This has left us somehow bridging the gap and paying the refund to their customer, because they had no funds in their account to cover the refund after the payout.

#

As far as I'm aware these actions have all been performed via our API

#

So what I'm trying to get to the bottom of is

#

  1. Is my understanding of this correct. Have we been left covering this refund to the end client, because our client's Stripe balance had already paid out.

  2. If so can we reverse this.

  3. How can we avoid these things happening in the future. Is there a block we can put on a refund if the appropriate funds aren't in the client's account at the time etc?

median moth
#

Can you share example refunds for that account I can look at? I want to see how you're creating them.

#

What charge flow are you using?

dusky tartan
#

I'm not sure to be honest. I'm not the developer who set this up. I can try to pull her in though if that helps?

#

Just getting her on now.

#

@inner sable

#

Can you answer the question above that Synthrider asked please

median moth
#

So, at a high level, I suggest reaching out to your Stripe account manager to get some broader guidance on this, but at the atomic level the adjustment would be eg setting up new connected accounts with manual payouts or longer payout delays to accrue some funds before they get paid out

dusky tartan
#

OK can we address this step by step please.

#
  1. Is there anyway through Stripe for us to recover these funds that we have been left refunding because the client's account was empty. I.e. when they add funds to their account in the future can we take them back then?
median moth
inner sable
#

@median moth we are using destination charge .

median moth
#

If you've already got that set, then in supported countries Stripe will attempt to debit the external account account for the funds

#

Yep I see that

dusky tartan
#

I've just read through that. Sorry if I'm being slow but I didn't get the answer to the question. I saw it says it takes from the business first but if it can't get the funds for the refund from them it will take from us.

#

So I get that. It sucks but I get it.

#

But beyond that I can't see any reference to how we might get these funds back from the client?

#

Can we recover the funds from their account as they add more funds or take more payments? If so how?

median moth
#

You'd need to get in touch with them to collect funds another way if the external account debit was not successful, eg getting other bank info

dusky tartan
#

So basically outside of Stripe

median moth
dusky tartan
#

We can't

median moth
#

You might first want to switch them to manual payouts

dusky tartan
#

That's our quickest way to go out of business.

median moth
#

(just for that account, i mean)

dusky tartan
#

We can't. Our fees are set across the board. 2%

#

This customer will take around 10 years to pay back this issue.

#

Hence why it's a pretty big issue.

median moth
#

This is really a business decision you need to make account by account depending on your trust of that account and their ability to pay back over time etc

dusky tartan
#

So OK, let's assume we're now holding the bag here, and we have to simply hope that this customer is a nice person and will manually refund this money.

#

That's the past.

#

How can we stop this happening in the future

#

I.e. can we block any refunds that are attempted if the client doesn't have sufficient funds in their Stripe account?

median moth
#

Future payments will pay back that balance if it remains negative and won't create payouts while negative

dusky tartan
#

Wait... so if they take more payments, those payments will pay back ClassFit's balance? So as long as they take payment above the amount we covered here - that will automatically be returned to ClassFit?

#

So there is a "self-righting" mechanism built in here already?

median moth
#

Again, I suggest reaching out to your account manager to help you plan for this

dusky tartan
#

I get it. But us pumping up our fees to account for 1% anomalies is how we go out of business. We need a way to block the anomalies instead.

median moth
#

Yes, you can evaluate each account when considering a refund, that's possible, but when using automatic payouts the account balance may not be accruing, so it really depends on a lot of factors

dusky tartan
#

It looks like what has happened here is

#

Client has stopped using ClassFit. But left one recurring membership with a client ongoing. This is likely by mistake. Each month they have paid into his account with neither noticing. His payouts are automatic, so he has been withdrawing these funds.

#

I assume one either the business or client has realises this and then the business has initiated 4 months of refunds through ClassFit. I imagine they expect that this money would be taken from their linked bank account but it hasn't been.

#

So us recovering this money seems very unlikely.

#

As I doubt they will receive any more payments.

#

So I can contact the client and hope that they pay us back.

#

But what we really need, and I assume Stipe must have, is some from of check through the API that determines if the customer has the funds in their Stripe account, or Bank account, before we allow them to refund the payment through ClassFit?

#

Otherwise I could quickly think of a way to pretty much empty the bank account of any platform using Stripe Express...

median moth
#

Yes, you'll likely want to get in contact with that account holder to square up if this is a normal use case but an inactive account

#

While you can block refunds based on the account relationship as you see fit, you are ultimately responsible for the express account balances and eg if a customer was not able to get a refund they might try to dispute the payment
https://stripe.com/docs/connect/best-practices#impact-from-chargebacks-and-negative-balances

Best practices for going live with Connect

Learn best practices for your Express or Custom accounts integration before going live and for managing onboarding requirements, fraud prevention, risk, and support.

dusky tartan
#

Well in this instance the business owner clearly wants to refund the client - which is fine. They are expecting to pay it out of their own pocket.

median moth
#

This is not so much a technical integration aspect, but an operational business decision, of when and how much to pay out to your connected accounts

dusky tartan
#

Well it's pretty technical

#

Because it seems the issue here is that the business wanted to pay the refund out of their own pocket, but because of the way the integration is set up, they likely unknowingly paid it out of our pocket.

#

So what I'm trying to understand is how do we point the flows in the correct order

#

i.e.

#
  • Business Stripe balance
  • Business Bank account
  • If neither have funds - block refund with error message giving instructions on next steps.
#

Because if we could do that, I think we would have avoided all of this.

#

Is creating an action flow like that possible?

median moth
#

Business Bank account
That isn't and can't be known, you'd only know if a debit were possible or not after it was attempted

#

You can check the connected stripe account balance before issuing refunds, yes

#

But again this is a choice you make based on your relationship and expectations for that account

dusky tartan
#

So the flow could be

Attempt debit

  • If success proceed
  • If fail send email with corrective action
  • NOT proceed to take from our bank account.
#

We're happy to make that choice to change the flow and check the balances accordingly first. Can you provide a process for how we can do that please?

median moth
#

You could do that, but you might end up in the same scenario with a negative balance, but yes you could absolutely try building that

dusky tartan
#

Why would we end up with a negative balance in this scenario?

median moth
#

So you could log the refund request, and attempt the debit after notifying the customer & account holder of what will happen

#

then when creating the refund later you wouldn't want to reverse_transfer since you already debitted for that amount

#

but this might add considerable delay to the refund flow, you'd only want to do so in some cases, maybe there the connect account doesn't have active payments coming in

#

again, this is an operational choice

#

I really suggest contacting your account manager to work on this, though

dusky tartan
#

I haven't actually spoken with anyone since we signed up. I'm not sure if my account manager is the same person who sold us on the deal? I don't suppose you know?

median moth
#

Ah, I might be mistaken on that, apologies

#

but the advice I shared still stands, as above

#

You need t carefully manage this, but weight the risk of the connected account balance liability against the customer refund experience

dusky tartan
#

We're a small company. This one customer's unintentional refund flow accounts for 10% of our revenue this money. The process also seems highly hackable should anyone be so inclined. So the risks of this are just too high to accept. If refunds are slowed down that's a much more acceptable outcome. And in most scenarios, people will have funds in their account anyway so there shouldn't be a delay.

#

Thanks for all your advice. @inner sable this is over to you. I imagine shee might reach back out if she has any questions.

inner sable
#

yes i will read the stripe documents you sent about this and if there is any question i will get back to you

median moth
dusky tartan
#

No worries at all. You've been a big help

#

Does the confusion change any advice?

median moth
#

Only in that I will stop suggesting contacting a person who doesn't exist for you 🙂 -- otherwise the advice stands.
But taking a step back, your integration is correct and valid but yes has exposure to negative balances which may or may not be possible for Stripe to recover.

#

When customers (payers) make payments, are they transacting with your platform or the individual connected account business?

dusky tartan
#

We facilitate it, but in the background. 99% of payments are between for example a yoga studio and their client.

#

They might book a yoga class through ClassFit, they will think they are paying their yoga studio.

median moth
#

OK, so taking a completely different approach, you might want to consider whether Standard accounts are a better fit for you. If the customer relationship lies with the connected account, you can facilitate that and the liability reside with the account holder.
https://stripe.com/docs/connect/accounts#choosing-approach

Note this changes your payment integration, but you can still collect platform fees when creating payments:
https://stripe.com/docs/connect/direct-charges#collecting-fees
https://stripe.com/docs/connect/direct-charges#flow-of-funds-with-fees

I am not suggesting this is a better fit, but it's an option to evaluate for your needs.

dusky tartan
#

So the reason we switched is that we got better pricing for doing so

#

But we continue charging Stripe fees. So while we charge 2%, we actually get around 3% in theory because of the Stripe kickback

#

Which is a 50% boost... if we can plug the gaps.

median moth
#

The change in the liability model is significant, but you'll need to determine your priorities of those items

dusky tartan
#

We even considered offering a free service and just working off the Stripe fees kickback because it's so significant to our business model.

#

But we do need to plug the gaps

median moth
#

Yep, there are inherent risks to manage about the account balance liability

dusky tartan
#

They seem workable though. It's just about plugging the gaps

#

For example if we have a client's credit card on file, can we add that as a third option before us.

Stripe balance
Bank account
Credit card
ClassFit balance

median moth
#

Right, when a customer refund request comes, you likely want to look at how much it is relative to the activity of the account etc, and decide on a flow for that

#

What do you mean?

dusky tartan
#

So this needs to be automated to scale, with rules applied. So if a customer actions a refund:

  • Check Stripe balance to see if it covers it.

  • If it doesn't cover it attempt debit from the associated bank account

  • If the bank account debit fails attempt debit from payment card on file

  • If payment card fails send email to customer explaining why refund wasn't processed and provide them with next steps - i.e. add funds to your account and try again.

  • End loop before it gets to attempting to take funds from our Stripe account.

prisma bronze
#

Hi @dusky tartan taking over for @median moth. Give me a few minutes to get caught up

dusky tartan
#

Hey, no worried. I can do a TLDR if you prefer?

prisma bronze
#

Getting caught up with @median moth, so let me start there first (:

#

So this needs to be automated to scale, with rules applied. So if a customer actions a refund:

  • Check Stripe balance to see if it covers it.
  • If it doesn't cover it attempt debit from the associated bank account
  • If the bank account debit fails attempt debit from payment card on file
  • If payment card fails send email to customer explaining why refund wasn't processed and provide them with next steps - i.e. add funds to your account and try again.
  • End loop before it gets to attempting to take funds from our Stripe account.
    With all of the above in mind, this is totally doable, but it would have to be built out on your end. Stripe doesn't automate to that degree yet, but it shouldn't be too hard to automate from your end. The flow itself (at a high-level) makes perfect sense though and is definitely achievable.

As of now you just need to narrow down your operational preferences and begin building it out right?

#

Just making sure I understand the full context. Feel free to correct me if anything seems overlooked

dusky tartan
#

I think that's on the money

#

Basically right now it seems like Stripe defaults to take money from our account a little too quickly.

#

We want to add in a few extra steps before we get left funding other people's refunds.

#

If we have to build it ourselves that's not a huge deal. We might have a few questions, but as long as it's technically doable it's certainly worth doing.

#

Do you have any guidance on the steps we'll need to take to achieve this?

#

*please

prisma bronze
#

That's a big question. I would recommend taking each step and attempting to narrow down all the API calls you'll need to make, and what information you'll need to make them. For example this step is easy:

Stripe API reference – Retrieve balance – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.