Hi everyone,
I’m building a short-term rental marketplace and struggling to find the right Stripe Connect configuration for handling long-term advance bookings. I’ve read this excellent guide on delayed marketplace payments which outlines 3 main approaches (manual payouts, separate charges and transfers, authorize and capture), but each has limitations that seem incompatible with our constraints.
Looking for advice from anyone who has solved this problem!
Our Use Case
Marketplace type: Vacation rentals / short-term stays
Key constraints:
- Platform registered in France, but hosts and properties across multiple countries
- Bookings up to 12 months in advance (sometimes longer)
- Ideal: Charge immediately at booking to secure reservation
- Reality according to our research so far: Stripe 90-day payout limit prevents immediate charge for long-term bookings
- Host payout: 2 days after check-in (traveler protection)
- No ACPR license required (ACPR = French financial regulator; platforms holding customer funds for extended periods need a payment institution license, which is complex and expensive to obtain)
The Problem
As mentioned in this guide, there are 3 main Stripe Connect approaches for delayed payments, but each has limitations for long-term bookings:
1. Manual Payouts
- 90-day payout limit: Can’t charge at booking if check-in is 12 months away
2. Separate Charges and Transfers
- Holding funds 12 months on platform balance = likely triggers ACPR licensing in France
3. Authorize and Capture
- Authorization expires after 7-30 days maximum
- Can’t hold authorization for 12 months
→ None of the standard approaches seem to work for advance bookings beyond 90 days.
Our Current Workaround (but not ideal)
After extensive research and Stripe support discussions, here’s what we’re considering:
Step 1: At booking (can be 12 months before check-in)
Stripe Checkout Session (mode: “setup”)
→ Creates SetupIntent automatically
→ Customer enters card + 3DS authentication
→ Save payment_method_id from completed SetupIntent
→ No charge made
Bubble implementation:
- Create Checkout Session via API Connector
- On success redirect: retrieve setup_intent_id from session
- Get SetupIntent details to extract payment_method_id
- Store in database (Booking table)
Step 2: At check-in -80 days
Create Invoice API with:
- auto_advance: true (Smart Retries)
- on_behalf_of: host_express_account
- transfer_data: { destination: host_express_account }
- application_fee_amount: commission
- default_payment_method: saved_payment_method (from SetupIntent)
→ Charge card automatically
→ Funds to host Express account (manual payouts)
(80-day delay respects Stripe’s 90-day payout limit)
Step 3: At check-in +2 days
Trigger Payout via API
→ Release funds to host bank account
Why this isn’t ideal:
- High risk of expired/invalid cards at D-80 (bookings made 6-12 months prior)
- Complex recovery workflows (retries, card updates)
- Poor UX (“Your card expired” emails months after booking)
- Lost bookings if customers don’t update cards
My Questions
- Better Stripe Connect configuration?
Is there a way to use Stripe Connect for immediate charge at booking with delayed payout after 90+ days that I’m missing?
- Similar marketplace implementations?
Has anyone built a vacation rental, event ticketing, or travel marketplace with long advance bookings in Bubble? What payment flow did you use?
- Escrow services?
Should we consider escrow services alternatives like MangoPay or Lemonway (they seem to allow unlimited fund holding duration) instead of Stripe Connect?
Any Bubble integrations or experiences with these?
- EU/France regulatory compliance?
For EU-based Bubble developers: How do you handle the “fund custody” regulatory aspect without triggering payment institution licensing requirements?
What I’m Looking For
- Alternative Stripe Connect configurations I haven’t considered
- Escrow/payment providers better suited for long-term bookings
- Bubble plugins or API connector setups you’ve used successfully
- Regulatory insights (especially French/EU ACPR compliance)
- Trade-offs and lessons learned from similar implementations
Any help would be greatly appreciated!
Thanks for your precious help 