#nerdyroger_best-practices

1 messages · Page 1 of 1 (latest)

gilded flickerBOT
#

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

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

quartz meteor
#

hi there!

fickle atlas
#

Thanks! One point we are struggling with is that the pre-payment may be partly returned to Customer (X days after pay-in when being held "in transit" at Stripe) and partly paid-out to Supplier, and also handling the % cut (to the marketplace) in such transaction. Any advice on best practice for this?

quartz meteor
#

can you explain in more details how this works? a concrete example would help.

gilded flickerBOT
fickle atlas
#

I tried to make a quick sketch of the outcome flows of a service booking - the tricky part is when the prepaid (and held) amount is to be reduced due to service not 100% completed (ref. 70%-outcome in sketch). Suggestions for best implementation?

image.png
acoustic lion
#

👋 taking over for my colleague. Let me catch up.

fickle atlas
acoustic lion
#

I'm not sure I understand

#

so in your use-case, you've already captured the full amount from the customer, but now since the outcome is 70% you want to get the 30% back from the connected account to refund it to the customer?

fickle atlas
#

Yes - maybe I don't fully understand - what is your suggestion for using the capture mechanism?

gilded flickerBOT
fickle atlas
#

My concern is the timespan - that the capture/pre-payment may happen several weeks before the service is delivered. Only after it is delivered, we will know if the service is good or if it has issues and the customer is entitled to a reduced price or get a full refund... Can this be handled by the "capture" strategy?

#

We've looked at "manual payouts" as this seems to handle delayed payout up till 90 days (2 years in US). However, we are not sure that Stripe Connect transactions can handle our use-case with "refund" or "reduced" payment after first collecting the pre-payment. And also our marketplace cut (apprx. 5%) is complicating the transaction.

#

Some advice for a good strategy for handling this in Stripe would be very useful.

naive leaf
#

manual payout seems like an option. Ultimately you process the payment on your platform and you can send any amount of that payment to the connected account, and you can take those amounts back, and so on. Those are the building blocks for taking fees/handling refunds etc

fickle atlas
#

Thank you very much! The initial post describes the context and what we overall want to do. Just to be sure before we invest too much time in Stripe Connect: Do you see anything in the full scope that can not be done within Stripe Connect and "custom accounts"? Or that disqualifies for using the "low code" approach (stripe hosted) with a few direct API-calls?

naive leaf
#

all of this is not suitable for low code I would say, you're building a complex bespoke Connect integration that will involve webhooks and careful balance tracking and onboarding of accounts and internal dashboards and so on

fickle atlas
#

Ok - we'll need to be aware of this and plan for it accordingly. We expect to manually control the flow of funds via the API/webhooks etc., but will our concept disqualify for linking to the standard GUIs for Stripe onboarding, dashboard for "connected account" etc? And are there any code samples that does something similar, like an "escrow" implementation etc? Thanks again 🙂

naive leaf
#

no you can still use Checkout and the hosted onboardings, it's just that there's a ton of bespoke logic for deciding when to do the transfers/reversals/calculate amounts etc , the actual business logic. That all has to be built.
No specific examples beyond what's in the docs no

fickle atlas
#

👍 What are a good examples in the docs of such logic? (Your API calls are well documented - but not always easy to capture the best way for putting everything together...)

naive leaf
#

there aren't really any examples of this since it's not really part of our product or integration, it's business logic

#

like for example if you process a charge for $100, you can then choose that you are going to transfer $40 of that to one connected account, $20 to another, and keep the rest on your platform(effectively your fee). All we can document is how to make the API call passing a specific amount https://docs.stripe.com/connect/separate-charges-and-transfers?platform=web&ui=stripe-hosted#create-transfer and tell you the constraints on what the amount can be (https://docs.stripe.com/connect/separate-charges-and-transfers?platform=web&ui=stripe-hosted#transfer-availability). The logic for deciding that you were going to pass that specific amount is your own business logic. That's the marketplace platform you're building, that's what I'm setting expectations that it's very much a bespoke platform you develop using the building blocks of our API/products, not a plug-and-play configurable platform we provide

pale leaf
#

Hello. Second developer of this marketplace. Thank you for your answers. It shows we have understanding of what we should use for our integration. I have related question to the flow.

#

We want to be able to support refunds in our flow.
We create a connected account (CA) with payment schedule set to "manual". We create a payment for Customer, which goes partly to CA (directly, main payment for Item) and partly to our organization account (fee).
In this case is it possible to authorize a refund from the connected account back to Customer within the specified period (https://docs.stripe.com/connect/manual-payouts)?
Or in this case we are obliged by law to authorize payout?
If latter is the case, then from my understanding we must use our organization account as a "buffer" for all transactions, am i right?

naive leaf
#

are you using Destination Charges/Separate Charges and Transfers as the charge model?

#

I assume yes. In which case : refunds are issued by you, the platform, you are liable for them. The connected account is just a recipient of funds, they're not the merchant and the PaymentIntent/charge objects are on your platform.
You can reverse transfers previously transferred to connected accounts, to pull funds into your platform balance to help cover the cost of the refund.

#

and as regards manual payouts, that lets you hold funds on the connected account and wait until you pay them out(which then dovetails with the ability to do a transfer reversal to reduce their held balance); if the funds are already paid out then the connected account can have a negative balance from the transfer reversal, and then the system described in https://docs.stripe.com/connect/account-balances#accounting-for-negative-balances apply and things like holding a reserve on your platform apply, there's a lot to this.

pale leaf
#

That's exactly what we've been looking into. I just assumed Connected account had more control over funds, but I see that's not the case. Thank you for the answer, you've been great help! Then i guess we are working in the right direction.