Hey Roy,
Sorry about the confusion here, I think we're talking about different things. I was trying to clarify when FX can happen and how to detect it in your code after the fact. It's not really what you have to do in the end, just a possibility.
You charge in the currency you want here as you're the one calculating the amount to charge and the currency to charge in. This is not related to Checkout specifically. What I've seen some users do here is to ask the customer which currency to charge in before collecting the card details and then charge in that specific currency. Others would simply always charge in their own currency. You don't *have* to ask the customer. If you always want to charge in USD you can do so and the decision is yours.
What we offer on our end is to convert the funds for you if you charged the customer in a currency that you don't have a bank account for. This means that if you charge in USD we do nothing and if you charge in EUR or JPY then we'll automatically convert those funds for you to USD.
Now to get back to your situation, if you charge using `destination` through your US platform on behalf of international users here's what can happen:
1/ Connected user has a US account and a USD bank account. There's no FX involved anywhere.
2/ Connected user has a GB account and a USD bank account. There's no FX involved anywhere.
3/ Connected user has a GB account but they don't have a USD bank account. FX is involved in that case.
Let's say that you charge $100 today on your US platform and take $10 as an application fee. For #1 and #2, you'd end up with $6.8 ($10 app fee minus $3.2 Stripe fee) and the connected account would end up with $90. No FX involved and flow of funds is pretty straightforward. If you look at the balance transaction associated with the original charge on your platform you'd see `currency: "usd"` that confirms no FX was involved.
For #3 it's a bit more complicated and corresponds to what you want to detect. Since the connected account doesn't have a USD bank account we'll have to convert to their default currency. For simplicity's sake, let's assume they have only a GBP bank account and it's their default currency. It means you charged $100 but we need to convert to GBP. This means that you end up with £66.62 in your account. This amount is *after* conversion from USD to GBP and includes the FX fee in it. This is also *before* we take our own fee from the transaction. We also take our fee (£1.13) which means you end up with £65.49 GBP in your balance. If you look at the balance transaction for that charge you'll see that you now have `currency: "gbp"` as it was converted. That's the logic you use to detect it in the first place.
We then transfer out the full amount of the charge to the connected account so you'll see -£66.62 in your balance which leaves you at -£1.13 in the end. The connected account then get those £66.62 and we take you $10 application fee from it. This is also FX-ed for the connected account. This means we take your fee in GBP as £6.66 so that you end up with the expected $10 application fee.
In the end, the connected account earned £59.96 after we took your fee and you as the platform got $10 as an application fee and -£1.13 for our fee in another currency.
The last step is a know quirk with the API and FX right now. This means that, as a platform, you'll end up with negative balances in other currencies that you don't have a bank account for. We recommend to simply ignore those negative balances for now while we work on better plots to fix this situation. You can also ask us to convert those to USD regularly by contacting support [1] until then if you don't want to see those build over too much.
I hope the full example helped clarify the situation here. Usually I recommend to play with the API and create such situations as #1 to #3 to better understand the flow of funds, who pays what, as it sinks in way better when seeing it in your dashboard and the connected accounts' (at least it does for me).
Let me know if you have any other question here though!
All the best,
Remi