If your platform connects riders with independent bike, e-bike, or scooter operators, payment integration is part of the rental engine. It decides who can list a vehicle, when a rider's card is charged, how an operator earns money, and what your team can do after a dispute.
A useful starting architecture combines connected operator accounts, hosted verification, server-side checkout, and webhooks that update one internal ledger. Stripe Connect fits that pattern for many marketplaces. MANGOPAY deserves a close look if your model needs wallets or staged captures. The provider is only half the decision.
Turns out, the hard part isn't the card form. It's deciding what a completed ride means financially.
Choose the payment flow before choosing the API
Rental marketplaces usually use one of three payment patterns. Each solves a different operating problem.
| Payment flow | Useful when | Decision to make first |
|---|---|---|
| Connected-account payment | Independent operators need to receive their share of each booking | Decide who handles refunds, processing fees, and negative balances |
| Preauthorization followed by capture | The final charge depends on ride time, mileage, damage, or a deposit | Confirm the provider's authorization window and rules for extra captures |
| Prepaid wallet or ride balance | Riders take repeated short trips or need a stored balance | Define top-ups, refunds, unused funds, disputes, and account closure |
These patterns can work together. A platform might authorize a deposit, capture the rental price after the ride, and then send the operator's share to a connected account. That combined flow only works if the payment provider, card network, and commercial terms support it.
Do not start with a checkout button. Start with a money map.
Map the rental lifecycle
Write down every financial state before building the user interface. Your booking system and payment system should share stable IDs, but neither should rely on a browser redirect as proof that money moved.
| Rental stage | What the platform should record | Typical failure to handle |
|---|---|---|
| Quote and booking | Price snapshot, currency, taxes, deposit, cancellation terms, operator ID | The price changes before payment |
| Payment method | Provider customer ID, payment method reference, and consent status | Card is declined or authentication is required |
| Authorization or top-up | Payment ID, amount, status, and expiration where relevant | Authorization expires or wallet funding fails |
| Unlock | Booking ID, vehicle ID, unlock time, and payment state | Vehicle unlocks before payment becomes final |
| Ride close | End time, ride amount, extra charges, and evidence | Final amount exceeds the authorized amount |
| Refund or dispute | Refund ID, reason, dispute status, and support record | Rider challenges the charge after payout |
| Operator settlement | Gross amount, platform fee, processing allocation, payout status | Payout is delayed, rejected, or reversed |
This structure prevents a common mistake: treating a successful authorization as revenue. It isn't settled money yet.
A practical Stripe Connect implementation
Stripe Connect is a marketplace account model, not just a card form. It lets a platform associate an operator with a connected account, collect payment according to the chosen charge structure, and calculate an application fee or other platform commission.
Stripe generally offers Standard, Express, and Custom connected account approaches. Standard gives the operator a more direct relationship with Stripe. Express uses more hosted account management and onboarding. Custom gives the platform more control over the experience, along with more implementation and support responsibility.
Express is often a reasonable starting point for a rental marketplace that wants hosted verification without building every account-management screen. Country availability, account requirements, payout support, and liability still need checking for your actual business model. Sharetribe's Stripe Connect overview is useful for understanding the connected-account pattern, but build against the provider's current documentation rather than copying an old tutorial.
Use this sequence:
- Define the commercial model. Decide who sells the rental to the rider, who issues refunds, who pays the processing cost, and whether the platform or operator carries a negative balance. This decision affects contracts and payment configuration.
- Create an operator account on the server. Store the provider account ID alongside your internal operator ID. Never expose secret API credentials in the mobile app or browser.
- Send the operator through hosted onboarding. Collect the required identity, business, bank, and tax information through the provider's supported flow. Deferred onboarding can reduce initial friction, but an account object is not the same as payout eligibility.
- Store verification state and requirements. Your dashboard should show whether an operator can accept charges, receive transfers, or needs more information. Make the blocked state understandable.
- Create the rider payment on the server. Use the provider's current payment object or checkout flow. Attach a booking ID, rental ID, operator ID, and internal order reference so support staff can trace the charge later.
- Calculate the platform fee explicitly. An application fee is not automatically the same as your commission, and the processor's fee is not automatically the operator's cost. Record the gross charge, platform fee, processor fee, operator share, and payout amount as separate values.
- Reconcile through webhooks. Listen for payment success, failure, refund, dispute, account requirement, transfer, and payout changes. Make handlers idempotent so a repeated webhook cannot unlock a vehicle or pay an operator twice.
The redirect can confirm that a customer returned to your app. It cannot replace a verified server-side payment status.
Build for rental charges, not ordinary ecommerce orders
An online store can often charge the full order immediately. A rental may need to reserve funds, wait for the vehicle to return, and calculate the final amount afterward.
Fixed-price reservations
For a fixed one-day bike rental, a normal payment at booking may be enough. Show the price, deposit, cancellation policy, and refund timing before the rider confirms. Keep the operator settlement pending until your stated rental event occurs.
The event might be pickup, unlock, return, or the end of a cancellation window. Pick one. Then use it consistently.
Variable final charges
A scooter trip with time-based pricing, mileage, late fees, or damage review may need authorization first and capture later. A preauthorization reserves funds; it does not guarantee that the money will remain available until the ride ends.
MANGOPAY's card processing documentation describes card tokenization, 3DS authentication, and reserving funds for later capture. Its preauthorization reference states that the documented authorized funds can be captured within 6.5 days of a successful authorization, with multi-capture support for listed card types.
Treat that window as provider- and card-flow-specific. It is not a universal rule for every processor. If a rental lasts longer, plan a new authorization or another agreed billing method instead of assuming the original hold will remain valid.
Thing is, a preauthorization also does not guarantee collection. The issuer can decline, the available balance can change, or the authorization can expire.
Wallets and ride balances
A prepaid rider wallet can reduce the need to charge a card after every short trip. The ride engine deducts from the balance, while the payment service records the top-up that funded it.
That convenience moves complexity into accounting. Decide how riders receive refunds, whether unused funds expire, what happens after a chargeback, and whether the balance can be transferred or withdrawn. A wallet may also create additional regulatory and safeguarding questions, especially if the platform holds customer funds before paying operators.
Use a wallet because it fits the rental experience. Don't use one simply to hide a weak settlement design.
Model fees in separate ledger columns
A marketplace has at least three different numbers:
- the rider's gross payment
- the platform's commission or application fee
- the operator's net settlement
The processor's fee, payout cost, currency conversion, refunds, and chargebacks sit around those numbers. They should not be collapsed into one percentage.
For rough U.S. planning, a card example of 2.9% plus $0.30 produces a $3.20 processing cost on a $100 charge. That is a budgeting placeholder, not a universal price. Your actual rate depends on the country, payment method, account structure, volume, contract, and provider pricing schedule.
Suppose a rider pays $100 and the platform commission is 10%. If the operator bears a modeled $3.20 processing cost, the operator-side amount is $86.80 before any payout or currency fee. If the platform absorbs processing, the operator-side transfer could instead be $90, while the platform retains $6.80 after the modeled processing cost and before other expenses. The provider's charge type and settlement rules determine how that appears in the ledger.
Keep the columns separate:
| Ledger line | What it answers |
|---|---|
| Gross merchandise volume | How much riders paid |
| Processing cost | What the payment provider charged |
| Platform revenue | What the marketplace earned |
| Operator payable | What the operator is owed |
| Payout cost | What it cost to send funds |
| Refunds and chargebacks | What reduced or reversed revenue |
| Currency conversion | What was lost or added through exchange |
Do not copy a payout percentage from another platform into your forecast. Daily, instant, and cross-border payouts can have different pricing, and some providers include payout costs in a broader contract.
A 5% or 15% marketplace commission is a business decision, not a standard payment-processing rate. Test several commission levels against support, insurance, fleet operations, refunds, and expected chargebacks.
Plan for failed payments and chargebacks
A failed payment and a chargeback are different events. A failed payment stops collection. A chargeback reverses a disputed payment while the issuing bank reviews the cardholder's claim.
The issuer decides the outcome. Budget for some loss instead of assuming every dispute can be won.
Keep a dispute record that your support team can assemble quickly:
- booking confirmation, price, cancellation terms, and accepted rental agreement
- payment, authorization, capture, refund, and dispute identifiers
- verification and authentication results that you are allowed to retain
- unlock, return, ride, and timestamp records
- vehicle condition photos or damage reports where relevant
- rider support messages and any refund offered
- the operator settlement state when the dispute arrived
Store only the personal and location data you need, and apply your retention policy and applicable privacy rules. A large data dump is not automatically better evidence.
3DS authentication may affect dispute liability in some cases, but it is not a guarantee against every claim. Your terms should explain deposits, late returns, damage review, cancellation, and the timing of final charges in language a rider can understand.
For balances that fail after a ride, use retry and dunning rules where the provider supports them. Set a clear stop point. Repeated retries or external collections should follow your contract, privacy policy, and legal advice.
Treat onboarding as an operating workflow
Hosted KYC or KYB forms reduce the amount of verification logic you must build. They do not make your marketplace compliant by themselves.
Your team still needs to decide:
| Area | Practical question |
|---|---|
| Operator identity | What information is required before listing, accepting a booking, or receiving a payout? |
| Bank details | How will a changed or rejected payout account be reviewed? |
| Payment data | Can you use hosted fields or tokenization instead of handling raw card numbers? |
| Customer terms | Are final charges, deposits, cancellation, and damage rules visible before payment? |
| Money movement | Who controls customer funds, and what happens if an operator is suspended? |
| Privacy | Are identity, ride, and location records limited to a clear purpose? |
| Reconciliation | Can finance match every provider transaction to a booking and operator? |
EU operations need jurisdiction-specific review. The European Commission's PSD2 information provides the regulatory background, while the European Banking Authority's Q&A on the commercial agent exclusion illustrates why a platform cannot assume one exemption covers every marketplace model.
The same principle applies in the United States. Ask counsel to assess the platform's custody, payout, tax, consumer-protection, and state-level obligations before launch.
Compare payment providers by rental workflow
Use this as a shortlist, not a league table. A provider that handles card checkout well may not be the right provider for operator onboarding, wallet balances, or cross-border payouts.
| Provider or option | Consider it when | Questions to answer before signing |
|---|---|---|
| Stripe Connect | You want a conventional card and wallet checkout with connected operator accounts and hosted onboarding | Which account type, countries, payment methods, dispute responsibilities, and payout schedules fit your model? |
| MANGOPAY | A wallet-based ledger, tokenized cards, preauthorization, or staged capture is central to the product | What are the capture limits, wallet rules, verification requirements, refund process, and country restrictions? |
| PayPal or Hyperwallet | Some operators specifically need PayPal-related collection or payout access | Does the marketplace flow support your checkout, split settlement, refunds, and operator geography? |
| Nium | Cross-border payouts are a major requirement | Is it your acquiring provider, your payout layer, or both for the intended markets? |
| Fondy | Local payment methods and broad regional coverage matter | Does the marketplace contract cover rental disputes, operator onboarding, and settlement timing? |
| NOWPayments | Crypto payments are a deliberate product requirement | How will you handle volatility, refunds, identity checks, accounting, and rider adoption? |
To be honest, the lowest transaction rate is rarely the whole answer. A slightly higher rate may be easier to reconcile, while a cheap payout layer may leave your team building the missing checkout and dispute workflow.
Ask each provider for a written answer to these points:
- Can the platform onboard operators in every launch market?
- Who is responsible for the rider charge and refund?
- Can the system authorize, capture, refund, and dispute a rental payment?
- What happens when an operator is not verified?
- How are negative balances recovered?
- What happens when an operator has already been paid?
- Which fees apply to international cards, currency conversion, and payouts?
- Can the provider export transaction-level reconciliation data?
Test the unhappy paths before launch
A sandbox happy path proves very little. Test the cases that affect vehicles, riders, and operator balances.
| Scenario | Expected result |
|---|---|
| Operator has missing verification information | Listing or payout access follows your stated rules |
| Rider abandons 3DS authentication | Booking remains unpaid and the vehicle stays unavailable only for the intended hold period |
| Payment succeeds but the app loses connection | Webhook processing completes the booking without a duplicate charge |
| Rider taps Pay twice | Idempotency prevents two charges |
| Ride ends above the original authorization | The system follows a documented additional-capture or approval path |
| Booking is canceled before pickup | Refund and operator ledger entries match the cancellation policy |
| Refund arrives after operator payout | The platform records who carries the resulting negative balance |
| Chargeback arrives after settlement | Support can assemble evidence and finance can track the reversal |
| Payout fails | Operator sees an actionable status and the funds remain accounted for |
| Provider sends the same webhook twice | The internal ledger changes only once |
Run these tests with a real booking identifier, operator identifier, and vehicle identifier connected through every system. Reconciliation should work without opening three dashboards and guessing which transaction belongs to which ride.
Questions operators usually ask
Can I use Stripe Connect for a scooter rental marketplace?
Often, yes, if your country, account structure, payment methods, and rental terms fit Stripe's current requirements. You still need to decide who handles refunds, disputes, processing costs, and operator balances.
Should the rider pay at booking or after the ride?
Use a full charge when the price is fixed and the cancellation terms are clear. Consider authorization, a wallet, or another staged method when the final amount depends on time, mileage, damage, or return conditions.
Is 2.9% plus $0.30 the actual marketplace cost?
No. It is a rough U.S. card example. Add platform fees, payouts, refunds, currency conversion, disputes, and any method-specific charges, then confirm the provider's current pricing for your account.
Does hosted seller onboarding remove compliance work?
No. It can reduce custom verification development, but the platform still needs clear terms, status handling, privacy controls, records, and a lawful approach to receiving and sending funds.
Can a preauthorization cover a long rental?
Not automatically. Authorization windows and capture rules vary by provider, card network, country, and transaction type. Check the exact flow before promising a long hold or a later damage charge.
Start with one controlled rental flow
Prototype one operator, one rider payment, one refund, and one payout in the provider's test environment. Map every webhook into the ledger, then test a failed verification, an expired authorization, a duplicate payment, and a post-payout dispute before you connect real vehicles.