#Erik Magnusson

1 messages ยท Page 1 of 1 (latest)

desert harborBOT
knotty oyster
#

Basically there will be a conversion from the presentment currency (the price that you set) to the settlement currency (the currency the account can take payment in) there may be an additional currency when you take your fee from that payment if your account doesn't have a bank account for payments in that currency

#

Definitely read that doc if you haven't already, has a lot of good detail here

rugged sinew
#

If we take to the flow for one charge as an example:

I create a paymentIntent that is a destination charge to a connected account. The connected account could be a business from anywhere. So lets say that the currency differs from where the user is and where the company is.
My platform takes a 2% fee for all payments that are being made, 3% for subscriptions.

Should I set the currency for the paymentItntent to that of the user or the connected account?
And where do I have to consider it being extra conversation charges, and where will they be applied? To my platform or the connected account that will take the payout

knotty oyster
#

The example scenarios later there may help. Basically it depends on whether you use the on_behalf_of parameter or not. If you do, your platform's settlement currency is the first place the funds try to go so it will be converted to your platform's currency if need be. Without OBO it will go to your connected account and be converted to that currency if need be

#

You can choose to match whichever account's currency if you want to, that is kind of situational to your business

rugged sinew
#

Thanks, I think "Destination charges with on_behalf_of" is what would be the best for for my case.

But it does not mention how converstion works if the users has a different currency then my platform.
Also I can't seem to wrap my head around where conversion fees would be applied. If I use "on_behalf_of". Would conversion fees be applied to the "on_behalfed_of" connected account?

But am I right in assuming that I should let me platform decide on the currency that the charge/paymentIntent should be created with? Either by checking the region of where the user is or let the user decide the currency themselfs?

I also wonder what the actual differences would be between using charges or paymentIntents in these cases.

knotty oyster
#

Also I can't seem to wrap my head around where conversion fees would be applied. If I use "on_behalf_of". Would conversion fees be applied to the "on_behalfed_of" connected account?
That isn't quite what that OBO param defines. That param (among other things) determines where the funds are considered to initially land, which can determine the presentment currency, which can determine the number of times FX fees are applied if that changes the number of conversions there are.

#

The doc I linked does provide examples of how this works but I am a bit too busy to adapt them to your situation. Will try to pull in a colleague for assistance

rugged sinew
#

I appreciate that Pompey. Thanks

midnight gull
#

Hi there ๐Ÿ‘‹ jumping in here, please bear with me a moment while I catch up on context.

#

It is up to you as the Platform that is creating the Payment Intents to determine what currency you would like to use as the presentment currency.

#

I'll need to double check how currency conversions with on_behalf_of flow. For Destination Charges that don't use on_behalf_of, this is a good graph representing the flow of funds.
https://b.stripecdn.com/docs-statics-srv/assets/application_fee_amount.837aa2339469b3c1a4319672971c1367.svg
https://stripe.com/docs/connect/destination-charges#flow-of-funds-app-fee
In that case if the presentment currency differs from the settlement currency of the Platform, then a currency conversion needs to occur first on the funds from the payment settling in the Platform account's balance.
Then when the Connected Account's portion of the funds are transferred to them, if there is a difference in the currencies of the account then another currency conversion needs to occur as part of the Transfer's lifecycle.

With Connect, you can create charges on your platform account, take fees, and then transfer remaining funds to your connected accounts.

#

Alright, it looks like if you use on_behalf_of then the funds from the payment are settled in the default currency of the Connected Account, even the funds on your Platform account. If you don't have a bank account to receive Payouts for that currency, then those funds will be converted during the Payout process.

rugged sinew
#

Thanks for the info, Toby. I'm still not following exactly how the flow is handled when using "on_behalf_of".
If I use on_behalf_of, will the stripe fee and the conversion be handled on the connected account behalf? Meaning I the fees won't ever be taken out of my platforms accounts?

midnight gull
#

No, fees will always be deducted from you the Platform for destination charges.

rugged sinew
#

Another question regarding subscriptions and products/prices.
I have a product on my platform that is the value of "1 sek". this is because I want users to be able to pick an amount to pay themself, so I simulate that by giving the users the options to purchase x amount of the "1 sek" product to pick their own amount.
I'm still using a destination paymentItent and on_behalf_of to the specific connected account.

Do i have to take anything into consideration here since the product/price is on my playform account?

rugged sinew
midnight gull
rugged sinew
#

Hmm, not really.
I guess I'm justa bit worried because it's a bit of a random solution.
Firstly, I might just wanna clarify if there actually is a way to set a dynamic amount for a subscription? Without the use a preset product

#

Like a regular paymentIntent but for recurring payments

midnight gull
#

Yup, you can create a Subscription, and when doing so provide enough information to create a Price object in an adhoc fashion by providing information in the price_data hash:
https://stripe.com/docs/api/subscriptions/create#create_subscription-items-price_data

But taking a step back, how are you collecting payment information from your customers. Are you using one of our hosted solutions like Checkout Sessions, or are you using Stripe Elements in your own checkout flow?

rugged sinew
#

But "product" is required in the price_data?

midnight gull
#

Correct

rugged sinew
#

No, the users will fill out and add the payment method themselfs prior to the purchase

rugged sinew
# midnight gull Correct

So that means it's not fully adhoc? I do need to have a preset product in order to go this route?

midnight gull
#

Yes, but the Product doesn't control the amount of the price, that is controlled by the Price objects. Is there a particular reason you can't use a predefined Product?

rugged sinew
#

Not that they made one recurring purchase of the specific amount of x

midnight gull
#

I'm not certain off hand what the receipts for that would look like. What did they look like when you tested this? Did you try setting unit_amount to the desired amount and leave quantity at 1?

rugged sinew
#

Another question regarding this method. When creating the price via price_data. Is it favourable to set the currency in the connected accounts favor, or for the currency that is referred by the user?

rugged sinew
midnight gull
rugged sinew
#

ok. does this always apply?
If I decide to always pick the connected accounts currency, not matter if it's charges, paymentIntent or subscriptions, the conversion fee will always go to the user? Taking the responsibility away from my platform?

midnight gull
#

I believe so, but that also assumes the customer is paying with a payment method that allows them to make purchases in other currencies, if their issuer/bank does not allow that the payment will likely fail.

rugged sinew
#

I see!
Thanks a lot for having patience with my bombardment of obscure question, Toby.