habib_best-practices

[tidal blade]

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

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

[burnt ice]

What does 'accepting a first sale' look like exactly? I'd assume there's no Stripe objects at this point it's just a 'sale' in your app

[bronze vault]

correct. it's purely an in-app event.

seller owns a calendar date, a buyer makes an offer, the seller clicks Accept. At that moment we'd trigger Account creation + Account Link onboarding for the seller, hold the in-app sale in a pending state, and only create the PaymentIntent (direct charge with on_behalf_of) once onboarding completes and capabilities activate. The buyer's card was saved earlier when they made the offer (off-session SetupIntent) but isn't charged until the seller is fully onboarded.
The question is whether this pattern is sound — particularly the gap between Accept and capability activation. Is there a recommended way to handle that wait? And is there a risk the seller abandons onboarding mid-flow, leaving the buyer's offer in limbo?

[burnt ice]

Theoretically that would work fine. The risk you run however is that the 'seller' is not actually onboarded with Stripe – we reject them for whatever reason

direct charge with on_behalf_of
Not sure why you'd want to set o_b_o with a direct charge?

But yeah I mean it's all possible on Stripe, you'd just need to manage that risk of the seller not completing or failing onboarding

[bronze vault]

it comes down to 2 things: I want my platform to be shown on the statements (i.e. OTD - and connected account's name) and I don't believe I could use destination charges because of UK FCA compliance. My platform should not be merchant of record.

On the abandoned/rejected onboarding risk: what's the recommended UX pattern? Hold the sale in a pending state with a deadline (e.g. 7 days to complete onboarding, otherwise auto-cancel and refund the buyer's authorisation)? Or is there a Stripe-recommended timeout/retry flow for this?

[burnt ice]

No specific recommendation really. The account onboarding window doesn't expire – the links do after a single use/click so you'd need to account for that. Otherwise you can listen for account.updated events to be notified when the onbaording is complete: https://docs.stripe.com/connect/handle-verification-updates

[bronze vault]

ok, thanks , understood.

for the direct / destination charges with obo , does what I said make sense ?

[burnt ice]

I don't really know what FCA compliance you're referring to. But it'd be kind of weird for your seller to be the MoR and yet all customer facing artefacts to have the platform naming

We also strongly recommend against direct charges with Express accounts for a number of reasons – mostly because they don't have full Dashboard access to handle refunds, disputes, etc

[bronze vault]

The FCA reference is PSR 2017 — UK Payment Services Regulations. Per our legal counsel, if OTD is the merchant of record, we're at risk of being deemed a payment service provider (PSP), which would require FCA authorisation (SPI/API/EMI — 6-12 month process). To stay outside the perimeter, the seller must be the MoR. Hence direct charges.
On the branding point — fair, but eBay/Etsy/Vinted all show platform branding alongside seller identity on statements, and they operate under similar marketplace facilitator frameworks. The statement descriptor prefix is for buyer recognition and dispute prevention, not a claim of MoR status (that's defined by funds flow and contractual terms in our T&Cs).
On the Express concern — would Standard accounts solve the refund/dispute objection (full dashboard access for sellers)? Or is there another pattern you'd recommend that keeps the seller as MoR while giving sellers self-service capabilities?

[tawny iris]

hi! I'm taking over this thread.

On the Express concern — would Standard accounts solve the refund/dispute objection (full dashboard access for sellers)? Or is there another pattern you'd recommend that keeps the seller as MoR while giving sellers self-service capabilities?
Yes Standard seems the best option here: they are the merchant of record, and have access to Refund/Disputes capability in the Stripe Dashboard.