#linus_best-practices

1 messages · Page 1 of 1 (latest)

dense mountainBOT
#

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

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

undone knot
#

There are four parties involved in the transaction:

  1. Platform

    • Extends the partner API with payment capabilities. A fee is collected for each charge.

  2. Platform partner (Connected account)

    • Should be liable for the transaction and must be the statement descriptor. Uses the platform (External API, not Stripe API’s directly) to perform payments in their application. A fee is collected for each charge.

  3. Partner customer (Connected account)

    • Customers to the partner sells products in the partner application. The remaining charge amount after above fees (platform + partner) should be transferred to this account.

  4. End user

    • The end user buys the products in the partner application and is the source of the transaction.

Currently Im using Separate charges and transfers with the on_behalf_of parameter set to the Platform partner account. After a successful payment two transfers are created to the 2. Platform partner and 3. Partner customer. The Stripe transaction fees are removed from the amount in the transfer to either of the accounts. Me as a platform should not pay the Stripe fees.

Is this best practice?

nimble fox
#

For the result you describe, there's really no other way to achieve this than separate charge & transfer

#

Whether using OBO is appropriate depends on which entity your customer (purchaser, end user) expects to be interacting with.

#

Note that using OBO does not change liability, your platform remains liable for disputes etc.

undone knot
#

The end user expects to interact with the platform partner and is unaware of my platform existence.

nimble fox
#

In that case OBO makes sense

undone knot
#

So OBO should be the platform partner. But I wish not to be liable for the transaction though...

#

I have thought about using the stripe_account parameter (platform partner), and transfer from the platform partner to me and the partner customer, but doesn't feel right.

nimble fox
nimble fox
#

(If using express or custom connected accounts, negative balance on your connected accounts remain a platform liability if funds can't be debited from the external accounts used for payouts)

undone knot
#

Hmm yes, maybe that's a better option. All the "Use when" applies to me.

#

for Direct charge

#

All my connected accounts are Standard Accounts

nimble fox
#

Gotcha, then they would be liable for disputes etc.

#

That might be the better pattern, but i'd recommend testing it out in a test mode config first to make sure you get the flow you want

dense mountainBOT
undone knot
#

Already tested both methods, except I haven't added the partner customer amount the the application_fee_amount

#

I will ty that flow also

#

Thank you for your input!

vale burrow
#

Hello! I'm taking over and catching up...

#

Ah, sounds like you're all set, but if there's anything else you need just let me know!

undone knot
#

I hope so, thank you! 🙂

#

One questions that popped up; If I create the payment intent on the #3 Partner Customer, could I still have the #2 Platform Partner as the statement descriptor?

vale burrow
#

When you say create it on #3, you mean a direct charge on that account? If so, no, that's not possible.

undone knot
#

Yes, using the #3 account Id for the stripe_account parameter

#

Well, ok