nehm116_api

[normal isle]

👋 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/1328692431679651933

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

• nehm116_docs, 3 days ago, 9 messages

[rugged tiger]

we're also already on IC+ pricing with STripe

additonally this is all true for us:

• The pricing scheme is enabled.
• Stripe charges fees on the payment to your platform rather than the connected account.
• Your platform is permitted to charge app fees in the connected account’s country.
• The payment doesn’t explicitly apply application_fee or transfer_data[amount] parameters that override managed application fees.
• The payment doesn’t use multi-capture.

[woven hazel]

How do we achieve this as we want to earn revenue on PI created via the API as well since they are our customers that we are passing to Stripe?
You can only collect fees through our APIs on payments created/initiated on their account by your platform

If they create payments on their account separate to your platform then there's no way to take a fee from the payment amount

[rugged tiger]

got it so if expose any stripe product to them including the API, we make $0

even if we disable stripe dashboard and use the components on our app to build our own dashboard + expose the API key

[woven hazel]

Unless you have some kind of arrangement with them to bill them separately for 'fees' from those payments, yes. But the only way you can use application_fee_* is if your platform is involved in the payment

[rugged tiger]

as in charge additional fees ontop of the stripe processing fees?

[woven hazel]

That is what you're asking about right?

[rugged tiger]

we currently make a % of the processing fees since stripe charges us IC+ pricing and we charge our customers 2.9%

if our customer uses the API, stripe charges them 2.9% and we make 0%. so i am assuming what youre describing is we'd have to charge ontop of the 2.9% to make fees?

[rugged tiger]

or are you saying setup a revenue share agreement with stripe for payments that were created off platform?

[woven hazel]

Sorry I'm lost

[rugged tiger]

current state: we allow customers to accept credit card payments through our app but still have access to stripe dashboard for chargebacks / refunds. stripe charges us IC+ fees and we charge our customer 2.9%, therefore we make 0.1%-0.7% on transactions

future state: we want to give our connect accounts (our app users) access to their stripe api keys (we can cofigure this on stripe dashboard) -- but if we cannot collect any fees, it makes no sense for us

you're mentioning "Unless you have some kind of arrangement with them to bill them separately for 'fees' from those payments"

but for API transactions they initiated, theyre already getting charge 2.9% by stripe automatically...so im not sure what you mean we bill them separately

theyd get charge 2.9% from Stripe and then an addition 0.5% from us (the 0.5% is a random example)?

[wary coyote]

hi! I'm taking over this thread.

but for API transactions they initiated, theyre already getting charge 2.9% by stripe automatically...so im not sure what you mean we bill them separately
you could ask the connected account for their payment information. and charge that payment method every time you see they make a payment on their end.

[rugged tiger]

im referring to this specifically

sorry not sure what you mean. if theyre using the API keys to charge their own customers, how would we know the payment information?

[wary coyote]

which payment information? like the amount of the payment? you can get it by listening to webhook events, like payment_intent.suceeded

[rugged tiger]

so if we look at an example: pi_3QgpqYPvUJwFZfxD1RzNvmqg

this customer used their Stripe API key to generate this PI

im not sure what you mean where we charge that payment method every time you see they make a payment on their end

like every time we see them POST /v1/payment_intents we create the same charge somehow?

here is a req_IXLt8oClQ1ol3A

[wary coyote]

no. every time you see a payment_intent.suceeded, you keep track of the amount of the payment. then once per week or per month, you compute your "application fee", like 5% of the total amount, and you create a new PaymentIntent to charge the connected account of that amount.

[rugged tiger]

but stripe already charged this customer 2.9%

[wary coyote]

correct, you can't change the Stripe fee.

[rugged tiger]

ok so this fee is ontop

this is a different agreement from what we currently signed with stripe

we get charged IC + as a platform

so technically the fee can be 2.1% because internchagne is low on a card and then we mark it up to 2.9% making 0.8%

thats what we're trying to replicate on the API side

which seems not possible

TLDR: its only possible if we're creating the PI, not our customer

[wary coyote]

like mentioned before:

the only way you can use application_fee is if your platform is involved in the payment
so here we are discussing a workardound, which is not a perfect solution

[rugged tiger]

hmm ok ya thats not a good solution then, all godo