#BPerez-connect-payments

1 messages · Page 1 of 1 (latest)

south ridge
#

When you refer to your user - are you talking about a connect account that is connected to your platform?

#

And how are you charging them? Through an account debit, or something else?

toxic gale
#

Hey @fringe jewel 👋 I'm jumping in here. There's a couple things to unpack here:

  1. If the payment fails then there is nothing to refund
  2. It's hard to say what the customer's experience will be as it's up to their issuing bank to decide how to handle the insufficient funds. The bank may let the account overdraft, or they may decline the payment.
fringe jewel
#

Okay, I ask because we are collecting the user who sent the offer and the user who accepts the offer's payment at the same time.(we are a trading marketplace, so both users are charged a fee to do a trade) So, we dont want to collect one users payment and have the others decline. Then be forced to refund one of them.

toxic gale
#

What type of payment methods are you accepting?

fringe jewel
#

The only reason I’m skeptical of the pre-authorize option is because we don’t want the user who sends the offer to have money taken from their account before the other user accepts the offer

#

We’re just accepting cards

toxic gale
#

The authorization doesn't take the funds, just reserves them. The funds aren't actually moved until the capture.

fringe jewel
#

But will it show up on the bank account? We were pre-authorizing before with a different payment processor, and our users were complaining that the money was shown as being taken from their account.

toxic gale
#

Gotcha, I believe it's up to the bank exactly how they display it, but I believe it would typically be displayed as a pending transaction. It does reserve the funds, but they could be released if not used.

fringe jewel
#

Yes, that is why we decided to go with the future payments route with the SetUpIntent. Since our users could be sending a bunch of offers in one day. What if we were to go this route:
User A sends the offer (Payment details are collected)
User B accepts the offer (We then Pre-authorize both users cards)
That way if one users cards decline we could refund the other user without having to pay a fee. We could also then capture both users funds immediately after if each ore-authorization is successful.
Could this work?

cursive viper
#

Hey there just stepping in for @toxic gale here and caught up on the thread so far

#

to be super clear for your needs: authenticating a card with a setup intent is not a guarantee that a future payment will succeed. the bank can decline or require re-authentication for any future payment at their discretion, so you always need to be prepared to handle such payment failures in the app logic.

#

Only an authorized payment is actually guaranteed to be available to you for the 7 day hold window

#

So what you describe can work where you pre-auth/place a hold on one card A first, then try the second one B later and only capture the payment on A if the payment on B succeed

#

as long as this is within the 7 day limits for placing such a hold

fringe jewel
#

What would happen if the bank needed to get a re-authentication?

#

We would only want to authorize once User B accepts the offer though.

#

Could we make it so that we pre-auth both cards when User B accepts?

cursive viper
#

You can do that, sure -- though only the "first" one would need to possibly be refunded if the other wasnt successful

#

but getting both to having a pre-auth/hold would perhaps be simpler, since you could run the payment recovery flow in parallel until both were

#

Are these payments running as off session or on session?

#

If off session, they'd be declined with an error indicating authentication was required

#

if on session, the payment intent would transition to the requires_action state

fringe jewel
#

i'm not sure, let me ask my developer.

cursive viper
#

do you have any example payments like this in test mode? i can look at them in the back end

fringe jewel
#

Would i find that in the stripe dashboard?

cursive viper
#

you can, yea, if you click into example payments in test mode you'll find IDs like pi_12345 etc in the corner or the URL

fringe jewel
#

we actually just switched to live mode so we could test the flow. I dont want to switch over and mess up something that our devs did. I'm going to have them join the server and see what our best option would be.
Is there any way we can guarantee the future payment owuld succeed with the flow that I've mentioned?

#

Also, are we able to lower the authorization hold period to lets say 3 days? instead of 7?

cursive viper
#

why would you want to shorten it?

#

You can cancel the auth'd payment intent (/cancel API endpoint) if you no longer need to hold the funds for later capture, adn the refund process will start.

fringe jewel
#

Well currently on our app we have it so offers expire in 3 days. And if we were to go the authorization route, we would just capture the funds immediately after both users pre-auth went through

cursive viper
#

Yep thats fair -- like i said there's no need to shorten it, the holds would auto-expire after 7 days or you can cancel manually earlier if you prefer

cursive viper
#

are you all set here, or need help with anything else?

fringe jewel
#

I’m all set for now. I’m going to have my dev reach out in this server if she has anymore questions. Thank you for you let help 🙏

#

Youre*

cursive viper
#

Great! You're very welcome 👋