#rafaelbaptista-connect

1 messages · Page 1 of 1 (latest)

lunar yoke
#

👋 happy to help

thin schooner
#

If you need me to provide more information let me know

lunar yoke
thin schooner
#

i'm using stripe express

lunar yoke
#

do you have a request id that gives you this message?

thin schooner
#

1sec will check

#

id : req_rSK0rCJcnZAO7j

next valve
#

ah ok

#

the problem is you're using on_behalf_of to do the charge locally(having the AR account charge the customer). That's what's not possible.

#

you can have an account in AR and payout to them, but they can't process charges themselves

thin schooner
#

can you elaborate more?

next valve
#

I can try, which part is not clear?

thin schooner
#

when should i use or not the on_behalf_of parameter,
because from my understanding of the parameter "on_behalf_of" this is the param that we should pass when we want the payment made to the connect account have the same descriptor as the charge made to the platform

#

so i was under the impression that the on_behalf_of could be used for every country, so that the payment would reflet the descriptor of the charge

next valve
#

and yes it can make it so the customer's bank statement shows it was the connected account charging them instead of the platform

#

you can't use it if the connected account does not have the card_payments capability, or if the connected account is in a country where we don't support creating payments(like AR today) so you just can't use it here.

thin schooner
#

alright, thanks for clarifying .. have another quesiton regarding this ..
i read that the capabilities of the accounts if not specified stripe assumes the ones that are setted on the platform defaults .. but i can't find bank transfer under that settings only specific banks like canada,...

next valve
#

what do you mean exactly? Like what is 'bank transfer' and what does that mean to you?

#

like what capability do you want the account to have that you can't find?

thin schooner
#

capabilties of the accounts when onboarding with the express flow

#

where you first create the account and then the account link

next valve
#

yep

thin schooner
next valve
#

I understand all that. So what capability are you looking for that you "can't find"

thin schooner
#

i sent a screenshot

next valve
thin schooner
#

i want to set it by default on my platform settings but i can't find it on the list

next valve
#

it's always requested so you don't have to enable it

#

it's the base level capability, the account has to have at least that(since otherwise you can't do anything with it if you can't send money to it)

thin schooner
#

ty for the link
another question on the charges for example Argentina.

When analyzing the charge seems like the amount of the charge return is on ars but then the transfer_data is converted to usd

#

so when i'm displaying that info to the clients the values are off, because the client received on the account only 85ars and the transfer_data gives 92

#

ch_3L1SYPCRI4H2eNZZ0VbqbF8n

next valve
#

Destination charges are converted to the platform’s default currency from the presentment currency and the funds sent to the connected account are converted again to the connected account’s default currency

#

so ARS->USD->ARS

thin schooner
#

so whats the best way to make the calculation of the fee that is charged, because in order to do this i need the values on the same currency, should i do the amount of the charge - the balance received on the balance_transaction obj

next valve
#

calculate which fee exactly?

thin schooner
#

im using transfer data so on my ui i want the client to know what is the fee that i'm charding

#

because on dashboard we only sees the payment that is sent to their account, on my dash i'm displaying the fee that i charged from that checkout

next valve
#

makes sense. Not following the question though

#

overall you should just take the application fee you need, which should cover the Stripe processing fee you pay on the charge, plus enough to make a profit. It's usually better to just set a specific percentage and always take that, not to try to customise it for each charge

thin schooner
#

this charge the values are off ch_3L1SYPCRI4H2eNZZ0VbqbF8n
the amount of the charge is $100.00ARS
but then on transfer says $92.00 that is not accurate

# 
Statement descriptor
12312SADF* INV#6935
Amount
$100.00 ARS
$0.83 USD

Payment exchange rate
1.00 ARS
0.008364 USD
Fee
$0.32 USD

Net
$0.51 USD
Status
Succeeded
Transfer destination
acct_1L1S6z2EW74coRVU
Transfer
tr_3L1SYPCRI4H2eNZZ0cjx1zB9
Transfer amount
$92.00
Transfer group
group_ch_3L1SYPCRI4H2eNZZ0VbqbF8n
next valve
#

why is it inaccurate?

#

you passed this in your request :

 "transfer_data": {
    "destination": "acct_1L1S6z2EW74coRVU",
    "amount": "9200"
  }

so that's telling us to transfer 9200 ARS to the connected account.

thin schooner
#

the value because 100ars are 0,84 usd

#

not the amount there is with the usd symbol

#

not ars

#

and also the value that hit the connected account was not 92

#

was 90.22

next valve
next valve
thin schooner
#

but if you check the amount that connected account received was not 92, was 90.22

next valve
#

it goes 92 ARS -> convert to USD -> convert those USD to ARS

#

so that ends up as 90.22 ARS because of the double conversion

thin schooner
#

my question is why the 92 is converted to usd and then to ars insted of being transfered in ars

#

Because stripe dashboard is not refleting that so is confuse to analyze the charge

next valve
thin schooner
#

because i have no way to know there the amount final received by the connected account

next valve
thin schooner
#

that amount is in usd not ars, the amount recevied by the connected account on api is given by balance_transaction[amount] i think

next valve
#

ah yeah, true

#

the transfer lands in USD and then is converted to the connected account's settlement currency so it' the amount of the BT associated with the destination_payment, you're right

thin schooner
#

alright, thanks .. have another question regarding the talk that we had before

how i would know when i could use the on_behalf_of or not?
I have multiple clients in different contries and need a way to know when i can add that param or not

#

because on the list of the crossborder payouts the argentina is there but then from what i understood argentina its not yet supported by stripe so how can i know when i can use it

#

for example if i make a charge to a pt connect account i'm required to use the on_behalf_of otherwise i get this error

 Cannot create a destination charge for connected accounts in PT because funds would be settled on the platform and the connected account is outside the platform's region. You may use the `on_behalf_of` parameter to have the charge settle in the connected account's country
next valve
#

there's no list unfortunately

#

I'd just test (like you're doing) and see what happens, that's the best option

thin schooner
#

i can't do that on live environment because then clients wont be able to process checkouts,
i need to do that prior of them going live

next valve
#

of course

#

so you test it in test mode before you launch your business in a country

thin schooner
#

thats not my point, my point is that what you are suggeting is simply not possible because i cant use that parm based on guessing , because that way some contries that should or shouldnt use that on_behalf_of can be missing and then my clients will not be able to close checkouts

#

stripe needs to provide a list on this

thin schooner
#

?

lunar yoke
#

sorry I thought I sent the message but it was only in draft, I must have forgot to hit enter 🙈 🤦

thin schooner
#

what will be the best way to keep the list on my side updated ?

thin schooner
thin schooner
lunar yoke
#

unfortunately I don't have a good answer for you there

thin schooner
#

what i'm worried is if i map this on my side into an array then if stripe adds a new country and i'm not aware i will not have the list updated

trim elk
#

You could schedule some job to update the list on your side every so often. That is up to you though