#Peter Boyd
cinder girder
amber dew
Hi there
Feel free to add details in this thread
Ah I see you edited
Is it an international card here?
slender gyro
nope
amber dew
Can you share the PaymentIntent ID?
slender gyro
ah wait let me check
pi_3LraI4JYMOMTx4nT1gKibgCB
US payment method
oh nvm I see the issue
sorry, I'll fix on my end
slender gyro
oh sorry
I see the issue
I might need your help
we calculate the transaction fee on our end before charging the customer (creating the payment intent)
so the customer knows how much the fee is for their selected payment method
however, we calcuate this amount based on the subtotal, then when creating the payment intent, we set the total amount as (subtotal + transaction fee)
however that causes stripe to calculate a different transaction fee
amber dew
Sounds like you want https://support.stripe.com/questions/passing-the-stripe-fee-on-to-customers
amber dew
🙂
subtle steeple
You may want to check with laws and regulations in your area. Some jurisdictions do not allow processing fees to be added to a charge in that way (you can separately calculate your prices to reflect the cost-of-doing-business - but in jurisdictions with restrictions, you should not explicitly add the fees).
This applies more when/if the fees are dependent on the payment method - but I recommend checking regardless.
slender gyro
yup good call
hm so this is not going to change the amount we pass to the payment_intent?
it's only going to be shown to the customer, correct?
subtle steeple
Well, if you calculate your "price" to cover the Stripe fees, only the calculated price would be shown to the customer
slender gyro
because if I charge the customer 100 and they use a CC, I'd show them a fee of around $3. then pass in the payment intent amount as $103
subtle steeple
That's specifically what I would not recommend
slender gyro
hmm, what would you recommend?
subtle steeple
I would set my price to $103, and charge the customer $103. After fees (assume they are $3) , you would net $100
price is $103; paymentIntent is $103
As a business, your prices must cover your costs. Some jurisdictions consider charging differently for different payment methods to be discriminatory
slender gyro
that's what we're doing, but the problem is that the transaction fee is calculated differently
if we calculate the transaction fee as $3, we send stripe $103, but then stripe calculated the transaction fee based on $103, which is a bit over $3
subtle steeple
That's a bit of algebra. Stripe has a page that shows the formula
slender gyro
this is a marketplace, so we show the customer what the seller has their item listed for, then we show them the estimated transaction fees associataed with the purchase
subtle steeple
As I said, in some jurisdictions the extra fees are not allowed. So you would want to work with your sellers to set their prices accordingly.
Another "approach" is to set your application fee so that it covers the Stripe fee (again, algebra), and net-net the seller absorbs the fees. Then you tell them how to set their prices to cover that.
slender gyro
yeah I'm thinking the application fee is the way to go
subtle steeple
I don't know your jurisdiction, so I can't be absolute here. Ticket markets in the US, for example, seem to be allowed to explicitly charge "service/handling fees" - but they do not scale them depending on the payment method.
(BTW, none of this is legal advice, and is NOT Stripe making recommendations - I don't work for Stripe)
slender gyro
I can't wrap my head around the difference, it seems we would always have to show the customer a slightly larger transaction fee than the one we're tacking on to the payment intent
I'm guessing the formula is calculating this amount, so it'd be like:
show to customer: $100 + $3.10
charge in payment_intent: $100 + $3.00
transaction fee calculated by stripe: $3.10
where $3.10 is the amount calculated by the formula
and $3.00 is the amount calculated by the simple CC fee amount shown in the stripe fees page
subtle steeple
give me a minute; I'll write out the formula I use
slender gyro
ok, but that is correct, in that we will show the customer a slightly larger transaction fee than we one we're passing to the payment_intent?
subtle steeple
IF you show it as a separate fee, you still only pass the full amount you are charging (Price + surcharge) to the payment intent. The calculations are to tell you the price and/or surcharge that nets out to the final amount you want to collect. Customer doesn't need to know, or want to know, the details going on "behind the scenes"
There are many approaches possible to take - you could simply show a single price to the customer,and calculate the application fee you need to cover the Stripe fee and your profit. You could calculate a service fee such that after the system (behinbd the scenes) makes it's charges you net the amount you want. You have to decide the approach first, then calculate what you need
For example, I have a formula to calculate a "fixed" (as far as the customer is concerned) service fee that covers Stripe charges & my profit, so that the "face value"goes to the seller. Based on payment methods and other expenses, the net profit may vary - but the fee is large enough to cover the worst case.
slender gyro
yup, I was thinking about the service fee as well
subtle steeple
So when using a "service" or "handling" charge, a fixed amount would likely (IANAL) not run into jurisdictional issues.
What I show the customer on my payment page is the line items (face value and service charge) and total, and create the paymentIntent for the total. Customer doesn't know anything about paymentIntents or confirmations - they just know they're being charged the total
I do not try to be "too smart for my own good" and attempt to charge precisely the exact amount to make the minimal profit - that's a "race to the bottom".
Yes, in my system, customer ultimately pays the fees and my profits. That may not work for your business model.
slender gyro
ok success, thank you