#mesudev-authorizations

1 messages · Page 1 of 1 (latest)

gloomy egret
#

hi there, can you share more about why you need authorizations to last more than 7 days?

ionic kernel
#

Hi, cheers!

#

It's not that I need it. But it would make the booking of the service of my platform more user-friendly. Services of my platform are always authorized only at the moment of the booking, and captured after the service has been provided. The consequence of this is that the system currently only allows the clients to book a service a little less than 7 days in advance.

#

And well for the service the platform users provide, it's quite usual to book up to sth like 2 weeks in advance

gloomy egret
#

hmmm, are you in the travel industry?

ionic kernel
#

nope

#

but my previous psp was for travel agencies indeed

#

my previous payment service provider = the previous API that I integrated in my platform

#

as I know that travel platforms are a problem at Stripe, so no worries

gloomy egret
#

what's the max interval that your customers will book in advance?

ionic kernel
#

oh sorry interval

gloomy egret
#

or timing 😁

ionic kernel
#

I would say 3 weeks in advance max, if I could provide that possibility, that would be perfect

#

imagine a gaussian distribution with max at 1.5 weeks

#

in advance

#

pretty much my scenario

gloomy egret
#

hmmm, i would say there's two options here :

  1. create a new authorization before releasing the old one. This ensures that you have a guaranteed auth (assuming it succeeds) before releasing the previous one. If it does not succeed you can decide between taking the risk or charging anyway.
  2. use separate charges and transfers like you mentioned before
ionic kernel
#

gotcha, for 1); wouldn't you need the client to re-authenticate`

#

?

#

If not, then 1) is definitely the preferrable solution, as I've setup the entire system using destination charges 😄

gloomy egret
ionic kernel
#

Hmm can you elaborate that a little further?

#

Like, when a client's credit card requires 3D secure upon every payment authorization. Can I re-authorize a payment that has already been authorized by that client, without triggering 3D - secure? Hence, only via backend? What's the risk here, in how many cases would you estimate that this woudl fail?

gloomy egret
#

whether the client needs to re-authenticate is up to the issuing bank, it's not within Stripe's control. But what you can do is to include the off_session=true when creating the PaymentIntent to indicate that the Customer is off session and to reduce the chances of needing the bring the Customer back on session to authenticate

#

i don't have any percentages to share here and it's a risk when using 1)

ionic kernel
#

aaah but I actually checked now that confirm => true

#

must be used in the payment intent call when using off_session => true

#

So this breaks the entire auth logic I've built using js stripe.confirmCardPayment()

gloomy egret
#

to clarify, when i say use off_session=true - this is when you create a new (subsequent) authorization

#

not for the first time

ionic kernel
#

yes I understand. But I mean if you can't tell me how big / small the risk is, the risk is too big for me ^^

gloomy egret
#

so your original logic is still fine

ionic kernel
#

I understand that it's up to the bank, as you said

#

Do you see any particular drawbacks / things that I should pay attention to when switching to separate charges and transfer from destination charges?

#

Cause that will probably be the next move

gloomy egret
#

hrm, are all of your connected accounts in the same region?

ionic kernel
#

no, that's the problem

gloomy egret
#

are you a US platform?

ionic kernel
#

even different countries

#

a to-be-international-platform

#

so it can occur that the customer vs platform vs connected account are all in a different country

#

mostly customer and connected account will be in the same

gloomy egret
#

are you the platform, based in US?

ionic kernel
#

no switzerland

gloomy egret
#

hrm, this is a problem then, separate charges and transfers won't work at all

#

so because you're not a US platform, and will have international connected accounts - you would want to implement destination charges with on_behalf_of

#

you would control the connected account payout schedule, to only payout when you want to

#

in that sense, it's kinda like separate charges and transfers

#

does this make sense?

ionic kernel
#

uuuhm

#

by "payout" here you mean transfer the service provider's amount from the platform's stripe balance to the concerned connected account's balance?

gloomy egret
#

payout : transfer (a.k.a movement of funds) from the connected account's balance to their bank account/debit card

ionic kernel
#

so what you're aiming at is making the funds stay as long as possible within stripe in case of eventual refunds, to not need to account for payout fees in case of reverse transfers. Is that what you're saying?

#

to kind of reach the same as with authorize and capture, do I get ya correctly?

gloomy egret
#

yep, that's pretty much it. Because your customer books up to only 3 weeks in advance, you can totally leave that amount in the connected account's Stripe balance till the service/goods is fulfilled

#

then when it's done/fulfilled, you can create a payout for the connected account

ionic kernel
#

But how can I control the payout moment ? AFAIK, you can only specify payout moments at an account-basis when creating connected accounts. Not when creating payment intents, no?

gloomy egret
ionic kernel
#

ok that means that funds are kicked directly from the platforms' stripe balance into the connected accounts bank account??

gloomy egret
#

with destination charges - the funds are automatically transferred from the platform balance to the connected account's balance i.e. platform balance -> connected account balance

#

that's why you specify the transfer_data.destination in the PaymentIntent when creating a destination charge

#

for a payout on the connected account, what you're doing is ensuring that funds move from the **connected account's Stripe balance -> their bank account/debit card **

ionic kernel
#

yup got that

#

How can I then get the ID that I need to specify for the payout? I can't find that in the docs; is that somehow tied to a connected account object?

#

I mean the destination for a payout*

gloomy egret
#

that ID is the connected account's bank account / debit card object id. You don't necessarily need to specify it

#

as it mentions, if you don't specify it, it will payout to the default bank account / debit card

#

it's really only useful if you want to allow your connected account to select which bank account / debit card to payout to (assuming they have multiple)

ionic kernel
#

but I'm missing sth

#

How does your API know to which connected account the payout refers to??

gloomy egret
ionic kernel
#

I see no "connected_account_id" parameter or whatsoever in the payouts API

#

So what you mean is doing this

#

with the payouts API call

#

so sth like this:

#

$stripe->payouts->create([ 'amount' => 1100, 'currency' => 'chf', ], ['stripe_account' => 'acct_1JQY10GX4jC1zJlQ'] );

gloomy egret
#

yep!

ionic kernel
#

well that's pretty awesome

gloomy egret
ionic kernel
#

so in the end we cannot modify the time payments can be authorized of 7 days, but after capturing for 7 days, would leave the amount within stripe's balance and wait with the payout until the service has been provide, then trigger the payout via API call

#

well technically I could leave the on_behalf_of thing

#

for now

#

All I really want is reduce unnecessary transactions to an absolute minimum, which is also why I use auth and capture. My users should not have any frequent refund hedaches 😄

gloomy egret
#

you must use on_behalf_of, otherwise the cross border transfers wouldn't work

ionic kernel
#

oh

gloomy egret
#

you can test it out on your own test env

#

try a destination charge and try a destination charge with the on_behalf_of parameter

ionic kernel
#

okok

#

I can implement all of this at a later stage without any problem right?

#

Time's short to do all of this right now

#

So I can like start with weekly scheduled payouts, and then later, at some point, switch to manual payouts for all of my connected accounts. Right?

gloomy egret
#

yep. The only thing which is key to your current implementation is the on_behalf_of parameter that needs to be included

ionic kernel
#

if the payments are cross-border

#

gotcha?

gloomy egret
#

if the connected account is in a different region from the platform account, then you must use on_behalf_of

ionic kernel
#

like if the customer pays in another currency than the connected account

gloomy egret
#

it's got nothing to do with the customer

ionic kernel
#

thank you so much Alex!

#

have an excellent evening / morning / afternoon 😄

gloomy egret
#

you're welcome, feel free to reach out if you have any other questions!

ionic kernel
gloomy egret
#

we say region, because of EU 😅

#

as an example, if you're a DE platform, you can transfer with no restrictions to Stripe accounts in other EU countries too

ionic kernel
#

ooh

#

so for EU cross-border transfers, I do not need on_behalf_of, as an example?

gloomy egret
#

yep, that's right

ionic kernel
#

ok

#

cheers!