Rental marketplaces put a physical asset in a stranger's hands. That's not the same as shipping a sweater. If the card is stolen, you can still lose the bike. If the account is fake, a banned rider walks back in under a new name.
Which checks belong at signup, and which can wait until someone actually tries to take a scooter?
You don't need a wall of forms. You need a sequence that stays quiet for normal people and gets louder when the signals stack up.
Fraud that actually shows up on these platforms
Marketplace fraud here clusters around identity, payment, and the listing.
A renter opens an account with a throwaway email, a VPN, and a prepaid card, then disappears with an e-bike. Another finishes a weekend ride and disputes a valid charge as unauthorized. Banned users create fresh profiles from the same phone. Underage riders borrow someone else's ID, or they never get asked.
Hosts cheat differently. A listing advertises a cargo bike that does not exist, takes a deposit, and stalls. Two accounts that know each other fake damage or reviews to move money, or to tank a competitor.
Payment trouble hits cash flow first. Stolen cards. The platform used as a middleman on a card the renter does not own. Friendly fraud after the vehicle is already back. Account takeover is quieter: stolen credentials on a real account, then a booking that looks clean until the real owner writes in.
A renter who looks fine at 9 a.m. can still be a problem at 9:15 if the device, the card, and the pickup neighborhood don't line up, and if you only check the card you miss the rest of it, which is how people keep losing scooters they thought were paid for.
You will not catch that mix with one checkbox. Watch the whole path: browse, signup, first rental, return, payout.
Put the cheapest check first
One rental-tech vendor lays out a friction ladder that matches impulse rentals. Cheap, invisible filters before checkout. Stronger proof only when money and a vehicle are both on the line. Their signup fraud notes for rentals are a workflow sketch, not a promise.
You can adapt that order on a platform like Greenmoov.app.
- Browse and account creation. Filter disposable email domains and obvious datacenter or VPN traffic before a renter ever sees inventory. Most people never notice.
- Signup. Add a phone check. Confirm it is a real mobile line, not a VoIP or burner, and that the name roughly matches. You are testing reachability, not building a government file.
- First rental. When an asset and a payment method are both in play, authenticate the card and cross-check email, phone, device, and card against each other. Step up only if those disagree.
- Repeat rentals. After a clean return, keep the path short. Re-challenge on a new device, a new card, or a sudden location jump.
Turns out the point is not more verification. It's matching the check to the loss you would actually take.
Low-value city bikes may only need email filters and card authentication. High-value e-bikes and mopeds can justify ID at first unlock. Copying another operator's stack without looking at your own loss file is how you annoy tourists for no reason.
Payments, disputes, and 3-D Secure
A screenshot of a transfer is not money. Treat a rental as unpaid until funds show in the account you control. People still get pushed into refunds off an emailed "confirmation" before the original charge settles. Don't.
3-D Secure (3DS) has the cardholder authenticate with their bank at payment time. On many authenticated charges, liability for an "I didn't authorize this" claim can shift toward the issuer instead of you. Keep a signed rental agreement. If you collect ID, tie it to that booking.
If Greenmoov.app or your processor handles the card, stay in their checkout. Don't ask anyone to text numbers. PCI still applies to anyone who touches card data. If your processor can place an authorization hold and capture later, use that on first-time renters so you are not taking the full amount before the bike has even moved.
Friendly fraud is the awkward one. The ride happened. The renter files a dispute anyway. Your defense is dull: unlock timestamps, return logs, GPS if you have it, photos at handoff, the terms they accepted.
Banks ignore a story with no trail. 3DS does not kill every chargeback. It changes who holds certain fraud claims. It will not help you on "the brakes felt weird" disputes.
Identity, age, and rules that change by city
Micromobility carries a legal overlay a typical product listing does not. Some cities want a driver's license for certain scooters or mopeds. Age floors differ. Confirming a rider is real, and old enough, is fraud control and a compliance step at the same time.
Veriff's work with Joyride is a public shared-micromobility example: verify riders so accounts map to people, and look for the same person opening account after account. That's vendor-reported. Use it as a pattern, not as your policy.
Thing is, none of this is national. Age might be 16, 18, or 21 depending on the vehicle and the city. E-scooter license rules in the U.S. are a patchwork. If you operate in more than one place, store the jurisdiction next to the listing and collect what that place requires. Don't invent a single ID rule for every bike in every town.
For the proofing model itself, NIST SP 800-63-4 is the U.S. reference for identity proofing and authentication in defined levels. You will not implement the full government stack. You can still separate "I can reach this person" from "I have evidence of who they are."
An email is not an ID. A phone that rings is not a license.
If you do collect ID images, keep them only as long as a dispute window reasonably needs, and follow the privacy rules that apply where you operate. Extra files you never look at are still a liability.
Signals worth watching
You don't need every data point a payments blog lists. A few correlated signals beat a dashboard full of red.
Same device or IP behind many new accounts. Phones that don't match names. Cards that fail 3DS, then succeed on a retry with a different email. Listings that take deposits before any photo of a real bike exists.
Run this weekly:
- [ ] New accounts booking high-value vehicles in the first hour
- [ ] Damage claims with no checkout photos
- [ ] Payout details changed right after a surge of bookings
- [ ] Message threads that read like two people coordinating a refund
- [ ] Repeat "lost" vehicles tied to the same cluster of accounts
Tell the renter why a check fired when you can. Silence makes honest people abandon the booking, and then you only see the fraudsters who were willing to argue.
Hosts, listings, and the other half of the book
Renter fraud is only half of a marketplace. A host who never had the vehicle can collect a deposit and stall. A host can also claim damage that was not there.
Proof the asset exists before the listing goes public. Recent photos. A frame or serial number if you collect one. A pickup pin that is a real address, not a pin in a parking garage two towns over. For first-time hosts, cap or delay payouts until after a clean return.
That's float. It is not a moral judgment.
When a dispute lands, compare the checkout photo to the return photo before you move money. If you never required those photos, you are arguing from memory, and memory is a terrible ledger, and you will settle claims you should have won because nobody took a picture of the scuff that was already on the downtube.
Collusion is uglier because both sides can look verified. Shared devices. Shared Wi-Fi. The same two accounts booking each other. Refunds with no real trip. Automation is weak at "these two people know each other." That is still a human review job.
To be honest, a lot of fleets skip host checks until the first fake listing. Then they tighten everything at once and wonder why good hosts leave.
Choosing a tool without a fake leaderboard
Vendor roundups love checkmark tables. Plenty of those tables are empty. Don't pick software from a grid you cannot verify.
Ask what job is leaking. Scripted signups point to bot and disposable-email controls. Stolen cards point to 3DS and a processor that will actually fight disputes. Banned riders coming back point to device graphs and identity crosslinking. Local age or license rules point to ID verification, not another risk score on a cart.
A checkout-only engine built for online carts will miss the hours the scooter is gone. Ask whether the product sees signup, payment, unlock, return, and host payout, or just the charge.
Can you set different rules for a first rental and a repeat renter? Can a person review edge cases without freezing the fleet? What data leaves your platform?
Skip consortium-data claims unless they show how shared signals apply to micromobility, not generic ecommerce.
Tighten the hole you actually have
Don't flip every rule on Monday. You'll block foreign cards and call it security.
Start with last month's mess. Pull failed payments, open disputes, no-return cases, and listing complaints. Tag each one: stolen card, friendly fraud, fake account, underage or ID gap, or listing issue.
The tallest pile is the layer to tighten first.
Turn on quiet filters (email, obvious VPN or datacenter, duplicate device) and watch false positives for a week. Add card authentication on first rentals and on high-value categories. Add ID or age checks only where the vehicle class or the city requires them, or where your loss file already says you need them.
Review a sample of blocked and allowed sessions. Then stop retuning every afternoon.
Buy a vendor after that list exists. Not before.
FAQ
Do I need photo ID for every city-bike rental? No. Match the check to the vehicle and the local rule. A cheap dockless bike and a high-value cargo e-bike should not share the same gate.
Are foreign cards and roaming IPs automatic fraud? No. Tourists look noisy. Pair those signals with device reuse, burner phones, and failed 3DS, then decide. A roaming IP alone is a weak reason to kill a booking.
What should I save if a chargeback arrives? Keep the accepted terms, payment authentication record, unlock and return timestamps, handoff photos, and the message thread. If you collected ID, keep the record tied to that booking, not in a random folder.