#asrob_code
lilac spearBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1308786115590881371
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
wicked sun
hi! if you use https://docs.stripe.com/payments/finalize-payments-on-the-server?platform=web then you can inspect the details of the confirmation_token.payment_method_preview.card.country before doing the payment.
icy ivy
So I left out that we're passing the fees on to the buyer. I know we have access to the payment intent at certain points but there is no way to do this on the client side? Also are the international fees as simple as country !== 'US'?
And what about currency conversion?
wicked sun
depends which international fees you mean precisely. See also https://docs.stripe.com/currencies#european-credit-cards
and not sure what your specific question about currency conversion is.
Ultimately passing the exact fee on the customer is difficult/semi-impossible and it's best to just factor things into your overall pricing instead. See also https://support.stripe.com/questions/scope-of-the-surcharge-ban-under-psd2-for-b2c-and-b2b-payments for reference
icy ivy
Right, yea that's part of the reason why I'm here. I'm unclear at the moment how to make this "sane". We do event ticketing similar to EventBrite but significantly less internationally (17 transactions in a recent event). I can tell you these charges represented our internal reporting being off yours but I'm unclear how to deal with it or at least how to deal with it that won't have us more permanently chasing whatever Stripe does. The way we're doing it now we show the buyer the fees so if we don't wrap it unto ours it looks like there isn't a clean way like the change event object having an is_international flag.
ch_3Pj8EiHMKnOi3Aai1bECsBYF card NZ
ch_3Pj8Q0HMKnOi3Aai09MVrgjf card AU
ch_3Pj99kHMKnOi3Aai06xF1MW5 card JP
ch_3Pj9HaHMKnOi3Aai1dPbVBuN card JP
ch_3PjDASHMKnOi3Aai1SOT6TCO card CH
ch_3PjDKvHMKnOi3Aai0pNcBLal card CH
ch_3PjE4yHMKnOi3Aai09kKFN4Z card DE
ch_3PjGRXHMKnOi3Aai0chOeirJ card ES
ch_3PjGkiHMKnOi3Aai00GZ5MVi card GB
ch_3PjH3iHMKnOi3Aai0wvRHY8j card GB
ch_3PjJW7HMKnOi3Aai1hBqmPWq card DE
ch_3PjKvrHMKnOi3Aai1BLehyKg card DE
ch_3Pk2xpHMKnOi3Aai0dC7mvLj card NL
ch_3PlbXVHMKnOi3Aai1Y0FWlzA card DE
ch_3Pm2JwHMKnOi3Aai0hXyLDVs card JP
ch_3PmVf9HMKnOi3Aai0WgIRfAY card GB
ch_3Q5UsuHMKnOi3Aai1zaK3a8z card TW
that would be nice but doesn't.
so you're a US Stripe account? then yes, I would think card.country != "US" would match pamyents that attract the international card processing fee, yes.
icy ivy
I'm getting the vibe you think that's the wrong way to deal with this. I'm just trying to currently account for the extra 1.5% added to "international" credit cards in a way I can show the buyer that they're paying more. It's more complicated because we're generally not setting the price our Connect client is. So FWIW this feels like a rough edge for Stripe.
wicked sun
checking the PaymentMethod country to determine if the charge will be an international fee is totally normal and works well, I think that's totally fine overall!
it gets more complicated if you want to completely know in advance what the processing fee will be in all possible cases, since it can be very variable, there can be extra fees for currency conversion that are dependent on market rates and markup that we don't publish in the API; and there are other things like if you want to amortise things like the Connect account/payout fees across the processing fee. And in those areas yes, we have tons of rough edges unfortunately. But the simple case of "is this card going to be charged as international" is well-solved at least.
icy ivy
I guess it was the "I would think..." and the fact that I'm assuming we'd have to look at the Connect accounts origin to truly be accurate.
wicked sun
well yes, you would potentially. Sorry, I have no idea if you're using Connect and if you're using Direct or Destination or Destination with on_behalf_of, which is all relevant and is not context I have in a quick Discord thread
icy ivy
For now that will have to do but it does feel like a lot of edge cases. I'd vote for adding more detail in the change event. I'd prefer to offload the complexity to you guys but it doesn't appear there is a way out side of I guess reviewing the payment intent details like you're mentioning.
wicked sun
correct
icy ivy
Oh well. Thank you.
wicked sun
to clarify you can test all this in test mode using https://docs.stripe.com/testing#international-cards + https://docs.stripe.com/expand/use-cases#stripe-fee-for-payment so it's pretty deterministic that way
icy ivy
For our use case that's probably good enough but still feels like it could be made much easier. Anyway, thanks again.
wicked sun
yep I don't disagree that "an API endpoint to see what the fee will be on an upcoming charge" is a common feature request and something my team advocates for, just hasn't happened yet