Stripe Connect can support a bike, e-bike, scooter, or micromobility rental marketplace, but it won't run the rental operation for you. Your platform still needs to manage vehicle availability, reservations, unlock status, returns, cancellations, and damage workflows.
Use a connected account for each rental operator or vehicle owner. Then choose the charge type, connect payment confirmation to your booking record, and reconcile transfers with payouts. Stripe handles much of the payment and onboarding infrastructure; your application remains responsible for the business rules.
Your booking system should own rental state. Stripe should own payment state and connected-account money movement. Stable IDs should join the two.
The safest build order is:
- Choose the payment flow.
- Create and onboard connected accounts.
- Collect the rider payment.
- Confirm the payment through webhooks.
- Transfer or release the operator's share.
- Reconcile refunds, disputes, and payouts.
Stripe's end-to-end marketplace documentation is the best reference for API behavior that can change over time.
Choose the Connect charge type first
A marketplace can use direct charges, destination charges, or separate charges and transfers. The right choice depends on who should make the charge and whether you know the payee when the rider checks out.
| Charge type | Fits a micromobility marketplace when | Money movement | Main tradeoff |
|---|---|---|---|
| Direct charges | The operator should make the payment directly through its connected account. | The charge is created on the connected account, with the platform collecting an application fee when configured. | Each connected account has a stronger role in the payment flow, which can make platform-wide reporting less uniform. |
| Destination charges | One booking has one clear operator or vehicle owner. | The platform creates the charge and sends the operator's share to a destination connected account using transfer_data[destination]. |
It is less suitable when one rider payment must fund several payees or when the final payee is not known at checkout. |
| Separate charges and transfers | A booking may involve multiple operators, owners, or service partners, or payment should be transferred later. | The platform charges the rider first, then creates one or more transfers. | Your platform takes on more reconciliation, balance, refund, and transfer timing work. |
For a simple rental, destination charges are often easier to reason about. The rider pays once, the platform records its fee, and one operator receives the remaining amount.
Thing is, the easiest API call isn't necessarily the easiest accounting model. Choose the flow your support team and finance process can explain six months later.
Use separate charges and transfers only when you need that flexibility. A booking that pays a scooter owner, a local operator, and a service partner may justify it. A single-operator rental usually doesn't need the extra moving parts.
Stripe also describes these models in its Connect guidance for SaaS platforms and marketplaces. Country availability, account configuration, and platform responsibilities can vary.
Create connected accounts for rental operators
Start with an internal operator record before calling Stripe. Store your own operator ID, business details, country, contact email, and the Stripe connected account ID in separate fields.
Stripe Express can suit a marketplace that wants Stripe to host seller onboarding and provide a connected-account dashboard. It isn't automatically the right choice for every business. Check the available account types, capabilities, countries, and responsibilities for your operating model before committing to the design.
For integrations using Accounts v2, create the connected account through the current Accounts API, including /v2/core/accounts where that API applies. Prefill information such as a verified email or business name when the API permits it. Prefilled data can still require Stripe verification.
Create the account on your server. Never accept a connected account ID from a browser and trust it without checking that it belongs to the logged-in operator.
Next, create an Account Link for hosted onboarding. The link is temporary and intended for one onboarding session. Your refresh URL should generate a new link, while your return URL should take the operator to a status page in your application.
Account creation is not the same as payment readiness. Save and display the requirements and payout status Stripe returns. An operator may have an account record but still lack a capability required to accept payments or receive transfers.
Deferred onboarding needs extra care. If an operator can list a vehicle before finishing verification, keep the listing, booking, payment, and payout states separate. Confirm that the charge model allows the transaction and never promise an operator a payout before the connected account is eligible.
Build the rider payment workflow
Keep the rental workflow on your server. A rider's browser can request a vehicle and begin checkout, but it should not decide the final price, platform fee, operator account, or payout amount.
-
Create a pending booking. Reserve the bike, e-bike, or scooter for a short checkout window. Give the booking a stable ID before creating the payment.
-
Calculate the amount server-side. Recalculate rental time, delivery charges, taxes, discounts, platform fees, and any deposit or authorization amount from trusted records.
-
Check the operator account. Confirm that the connected account belongs to the booking and that its payment or payout requirements do not block your selected flow.
-
Create the payment. Use a PaymentIntent for a custom rider experience or a Checkout Session for Stripe-hosted checkout. For a destination charge, pass the destination account and application fee through the supported payment fields. Never take these values directly from client input.
-
Use an idempotency key. A network retry should not create two charges for one rental attempt. Tie the key to the booking and payment attempt, not just to the rider.
-
Confirm payment on the server. A return from Checkout only tells you that the rider reached your return page. Check the payment status and process the relevant webhook before marking the rental paid or unlocking a vehicle.
-
Transfer funds at the intended point. A destination charge handles the transfer as part of the charge flow. With separate charges and transfers, wait for the business event you selected, such as a completed rental, then create the transfer according to your ledger.
-
Reconcile the result. Record the Stripe payment, fee, transfer, refund, dispute, and payout references against the booking and operator records.
Checkout can simplify the rider-facing payment page. It does not remove the need for server-side pricing, webhook handling, refund logic, or rental-state management.
Treat webhooks as part of the rental state machine
A successful redirect is not enough. Your webhook endpoint should verify Stripe's signature, reject malformed events, save the event ID, and make each handler idempotent. Stripe can retry delivery, so processing the same event twice must not unlock a scooter twice or issue two operator notifications.
| Event | Use it for |
|---|---|
checkout.session.completed |
Link a completed Checkout flow to the booking, then verify the payment status and amount. |
payment_intent.succeeded |
Confirm a successful PaymentIntent when your custom payment flow uses that object. |
payment_intent.payment_failed |
Mark the attempt as failed and release or reprice the reservation according to your checkout rules. |
account.updated |
Refresh onboarding requirements, capability information, and payout readiness. |
charge.refunded |
Update the booking ledger and begin the operator-fee or transfer reversal path your policy requires. |
charge.dispute.created |
Open a dispute case, preserve the rental evidence, and apply the correct balance treatment. |
payout.paid and payout.failed |
Show whether money reached the operator's bank account and alert support when it did not. |
Save enough information to investigate a payment without searching manually through the Stripe Dashboard. That normally includes your booking ID, connected account ID, payment object ID, transfer ID, refund ID, and event IDs.
Do not assume events arrive in the business order you imagined. Your handler should read current state, compare it with the event, and apply a safe transition.
Separate transfers from payouts
These terms describe different movements:
- A transfer moves funds from the platform's Stripe balance to a connected account.
- A payout moves an eligible connected-account balance to the operator's external bank account.
A destination charge can create the transfer during the payment flow. The connected account's payout schedule is a separate question.
Payout timing can depend on account requirements, risk review, bank processing, country, currency, and the account's payout settings. Do not advertise instant operator payouts unless your exact setup supports that promise.
Before writing refund code, decide how the money should move back. A full refund may need a corresponding transfer reversal or application-fee treatment. A partial refund may require a proportional or policy-based adjustment. The connected account may not have enough available balance when you attempt the reversal.
Write these rules before launch:
- Who absorbs payment processing costs after a cancellation?
- When does the operator earn the rental proceeds?
- Does a full refund reverse the platform fee?
- What happens if a dispute arrives after the operator has been paid?
- Is a damage deposit a separate payment, an authorization, or not part of the flow?
The answer should appear in your customer terms, operator agreement, ledger, and support tools. A payment API cannot choose the policy for you.
Calculate platform fees with real costs in mind
Avoid hard-coding a universal Stripe rate into your margin model. Payment processing and payout costs can vary by country, payment method, currency, account arrangement, and other Stripe products. Check the current pricing that applies to your platform and connected accounts before publishing an operator calculator.
Here is a simple destination-charge example. A rider pays $100 for a rental, and your platform sets a 5% application fee. The application fee amount would be $5, or 500 cents in a USD request. Under that simple one-operator setup, the operator's gross share is $95 before other adjustments.
That does not mean the platform's net revenue is $5. Processing fees, currency conversion, refunds, disputes, taxes, and payout costs can change the result. The party that bears each cost also depends on your charge model and Connect configuration.
Track at least these values separately:
- Rider amount charged
- Platform application fee
- Payment processing cost
- Operator transfer
- Refund and reversal amounts
- Dispute losses
- Payout amount
- Tax collected or withheld
Do not call the application fee profit until the rest of the ledger has been reconciled.
Plan U.S. tax records early
U.S. marketplace operators should decide early how they will collect tax information, respond to seller questions, and handle reporting responsibilities. Stripe onboarding can collect information required for payment operations, but it does not turn every marketplace into the same tax arrangement.
The IRS explains that Form 1099-K reports payment transactions and can show gross amounts rather than a seller's profit after platform fees, shipping, refunds, or operating costs. A seller may also receive forms from more than one platform. See the IRS guidance on Form 1099-K and the IRS Form 1099-K instructions.
Reporting thresholds and state rules can change. Whether a particular seller or service arrangement creates another reporting obligation needs tax advice based on your structure, not a copied number from a marketplace blog.
Keep tax records connected to the same operator and payout ledger used for payment reconciliation. Gross rider payments, platform fees, and operator proceeds should not be mixed into one unexplained total.
Test rental edge cases before going live
Use Stripe test mode to exercise the complete path, not only one successful card payment. A payment test is incomplete if it never reaches your booking, fleet, notification, refund, and accounting systems.
| Test case | Expected result |
|---|---|
| Successful card payment | One booking becomes paid, one operator allocation is recorded, and the vehicle remains tied to that booking. |
| Declined payment | The booking stays unpaid and the vehicle becomes available again under your reservation timeout. |
| 3-D Secure or redirect flow | No vehicle unlock occurs before the server receives confirmed payment state. |
| Asynchronous payment method | The booking waits for the appropriate success or failure event instead of relying on the browser return. |
| Duplicate webhook delivery | The database does not create a second transfer, refund, notification, or unlock action. |
| Full refund | Rider, operator, platform fee, and ledger balances follow the written refund policy. |
| Partial refund | The system records the exact amount and does not assume the original split still applies. |
| Dispute | Support receives a case with booking details, rental records, and the correct financial status. |
| Incomplete onboarding | The operator sees the next required action and the platform does not promise an unavailable payout. |
| Failed payout | The operator and support team see the failure, while the booking ledger remains intact. |
| Cancellation before and after pickup | Each point in the rental timeline follows the correct fee and refund rule. |
| Multiple payees | Separate transfers reconcile to the one rider payment without exceeding available funds. |
Test webhook retries and out-of-order events too. They are easy to ignore and expensive to discover during a busy rental weekend.
Questions operators usually ask
Is Stripe Express suitable for a bike or scooter marketplace?
It can be a practical fit when you want Stripe-hosted onboarding and a connected-account dashboard. Confirm regional availability, capabilities, payout controls, and your platform's responsibilities before choosing it.
Can sellers finish onboarding after receiving a booking?
Sometimes a platform can delay parts of onboarding, but you should not assume that an unverified seller can receive a payout. Check the current Stripe requirements for your country and charge model, then keep the booking and payout states separate.
Do I need separate charges and transfers for every marketplace fee?
No. A destination charge can handle a single operator and a platform application fee. Separate charges and transfers make more sense when you need multiple payees or control over when transfers occur.
Can I prefill seller information?
Yes, where the relevant Accounts API supports it. Prefill only data you have validated, and expect Stripe to request additional information or verification.
Does checkout.session.completed prove that a rental is ready to start?
It is an important event, not a substitute for server-side verification. Check the payment status, amount, currency, booking ID, and any asynchronous payment events before unlocking a vehicle.
Start with one traceable rental path
Build one test path first: one operator, one vehicle, one currency, and one charge type. Create the connected account, run a rider payment, process the webhook, record the transfer, issue a refund, and follow the payout status using the same booking ID.
Once that trace is reliable, add multiple operators, deposits, partial refunds, and more complex fee rules one at a time. That sequence keeps payment problems from being confused with fleet or reservation problems.