#_Giulio-stripe-fees

1 messages · Page 1 of 1 (latest)

bitter badge
#

Unfortunately there is not. You can see the Stripe fee after but can't get it before, there are a lot of factors that go in to the fee

deft arch
#

#dev-help message
(just dropping in our previous discussion on the same topic for context!)

whole plank
#

Yes I know, that's because I would need to adjust the price of the product according to the % fee (depending if it comes out 1.4/2.9/3.4/4.9)

#

thanks @deft arch

#

still need to figure out how to manage this aspect

#

Otherwise, if I'm not able to figure out that prior to the transfer, how could I know which f% relates to the specific transaction?

deft arch
#

by testing similar cases in test mode beforehand and calibrating your business logic based on that

#

so as I said in the other thread, you clearly have some scenarios in mind and Connect flows. So you'd try them out in our test mode API and confirm that you see the results you expect and then your code will be able to accurately predict.

The only thing affecting the fee is the country the card is issued in (e.g it's 1.4% + €0.25 for EU cards and 2.9% + €0.25 for non-EU), you can confirm all this using the international testing cards I mentioned in the previous thread.

#

it would be nice if our API could tell you the fee before processing the payment but it doesn't unfortunately so you need to build some logic around it if you want to pass on the fee.

whole plank
# deft arch so as I said in the other thread, you clearly have some scenarios in mind and Co...

Ok I get that, will do for sure. The only thing is that the fees coming out for a specific card would be available just after the first transfer happens, as you said before, I could get them with a PaymentIntent.retrieve call. Right?
So I'm thinking I wont be able to figure out them prior to a the first transfer that card makes. Or would I be able to "save and check" the specific card with PaymentMethod object?
I could ask owner where the country the card it's been issued in and then figure out fees in this way.
But if I implement that, how could I verify it? (checking if the card it's really been issued in that country?)
Otherwise malicious users could take advantage of this and that could result in a loss.

#

Plus, how could I be able to understand if there's need for a conversion? I understood an additional 2% of the trans. vol. would be charged, am I right?

whole plank
#

So I'm thinking about this solution, let me know if that's implementable:

-make users do a "test transaction" to activate their cards. Basically processing a payment with the min. amount to then refund it. This would even solve the conversion thing, as fetching fees using this ->

payment_intent = stripe.PaymentIntent.retrieve(
'pi_xxx',
expand=['charges.data.balance_transaction'],
)

fee_details = payment_intent.charges.data[0].balance_transaction.fee_details

would result in fee_details holding the % number related to the fees (so one of these options -> 1.4/2.9/3.4/4.9)

#

Let me knwo

#

Hello?

bitter badge
#

Hello still here, have been juggling other threads. Am reading through what you wrote and thinking on if that will work

whole plank
#

Hi, thanks a lot.
So my goal is to understand f% related to a specific card, before processing real payments.
https://stripe.com/docs/payments/save-and-reuse?platform=web
Doing this would work as well?
I'm reading "The SetupIntent verifies that the card information your customer is using is valid on the network. However, automatic verification isn’t always performed."
So a card verification isn't sure 100%. And also need for conversion would be not revealed

Learn how to save card details and charge your customers later.

bitter badge
#

So the test charge method would help you get the fee and then you could confirm that by going through the fee calculation formula with the info you have to make sure it matches up

#

And correct, a SetupIntent would help you with some of that but not all

whole plank
#

Ok @bitter badge thanks. With test charge approach would I know if there is some curr. conv. going on with that card?
for example, if the card is not european, when checking fee det. about test transaction I should get something like 0.25eur + 4.9% of transaction amount, right?

bitter badge
#

Let me look in to how you may find that out

whole plank
#

Ok thanks @bitter badge

#

payment_intent = stripe.PaymentIntent.retrieve(
'pi_xxx',
expand=['charges.data.balance_transaction'],
)

fee_details = payment_intent.charges.data[0].balance_transaction.fee_details

Doing this wouldn't tell me that? What would be in fee_details? The fee paid of course, but in % or absolute number?

fiery wasp
#

@whole plank sorry for the delay, we don't give you the percentage, we just give you the total fees you paid on that BT

#

and for the exchange rate you can compare the BT's amount and the original Charge amount

whole plank
#

So if there's currency conversion in the process BT would be <2% compared to Original Charge Amount?

fiery wasp
#

<2% after conversion yes

whole plank
#

Which Exchange Rate are you using to make the conv?
I would need to refer to the same to be able to make an accurate comparison

fiery wasp
#

You can't

whole plank
#

let's say if 12xxx = 10yyy BT would be 9.8yyy?

fiery wasp
#

We don't share that information today, we use our own internal exchange rate based on our partners

#

Basically what you are trying to achieve is just not possible, we do not surface that level of information in the API. You only see $100 USD -> 87€ mostly and that's it

#

I'd recommend chatting about your use-case with our support team https://support.stripe.com/contact/email but this isn't about code at this point it's because the data is not available in the API (or Dashboard)

whole plank
#

Would that give me the amount in which currency?
If the purchase happens in xxx but xxx needs to be converted to yyy

fee_details = payment_intent.charges.data[0].balance_transaction.fee_details

assuming fee_details = 10. Would be 10xxx or 10yyy

#

?

fiery wasp
#

The Charge is in USD, and has amount in USD. It converts to EUR so the BT is in EUR and has all amounts in EUR

#

so in your example fee details is in yyy because it's the conversion result

whole plank
#

Cool, got it.
Still tricky to figure out fees this way, even with a test transaction.
Doing the test transaction I could just figure out if the card is eu or not (comparing amount of fees paid with transaction vol, I could say "ok, this card paid 1.4 (or 2.9)% in fees" with a good degree of reliability.
If the card implies a curr.conv, yes, I would be able to figure out that comparing BT curr to the original one.
But how could I figure out how much that 2% is equal to?
if fee details is in yyy, does that include that 2% as well? or just the 1.4/2.9% + 0.25?

fiery wasp
#

you can't figure this out

#

I'm sorry I don't understand why you want/need to

#

all you should be looking out is how much Stripe took as a fee.

#

I really think you should talk to our support team now, this is unfortunately about pricing and not about code

whole plank
#

So, my goal would be to figure out the whole fees amount packet (so the 1.4/2.9% + 0.25eur + 2%conv.fees(those are part of Stripe fees as well)) that a specific card has to pay for payments, before letting the card be able to transact in my platform. This way I can take that fees amount and charge it in the price the buyer pays, making it X+Y, so the seller would receive X, which is the amount he would like to be paid of for the product buyer's purchasing

#

Does it make sense?

fiery wasp
#

I don't think it does unfortunately

whole plank
#

let me make it super clear with an example

fiery wasp
#

I'm really sorry, pricing is not something we help with, and you're asking about the intricacies of the 2% FX fee, you really need to chat with our support team and work through concrete examples

#

this is not about code right now

whole plank
#

So fee_details = payment_intent.charges.data[0].balance_transaction.fee_details
equals to just the 1.4/2.9% + 0.25 always in EUR?

fiery wasp
#

yes

#

at least that is my understanding

#

but we're back to "this is about pricing" 🙂

#

I'm sorry, my team really never looks at this

whole plank
#

Ok that's fine, i'll make up an example and text it over to the Support

#

Thanks anyways