Hand the deposit back on return

At pickup, the renter pays the security deposit on-chain to your Paymos deposit address — a real transfer in the amount your rental agreement specifies, not a card-network hold against a credit limit. The handover paperwork records the pickup odometer, condition photos, and the deposit transaction reference. On return, you inspect the vehicle and either refund the full deposit on a clean return or refund the balance after deducting documented charges (damage, overage, fuel). The refund transaction lives alongside the inspection record as the audit trail, and the deposit cycle closes the moment you sign off — to an address you've already whitelisted the refund lands in minutes (a new address takes a one-time 2FA step to add first), not the 1–2 weeks a card pre-auth takes to age off.

You issue a follow-up Paymos invoice for the additional amount. The renter pays it voluntarily under the rental agreement, or you pursue collection through your normal damage process — insurance subrogation, small-claims, or a collection partner. The deposit you already hold documents the original agreement; it doesn't substitute for the legal process of pursuing damages above the deposit amount.

Yes, via the server-side API. You wire Paymos in through the server-side API as the payment layer. Your integration creates a Paymos invoice on reservation, listens for HMAC-SHA256 confirmation webhooks, and triggers the deposit payment-and-refund lifecycle via standard API endpoints. Paymos can run alongside Stripe in the same PMS, so the renter picks at checkout.

Two flows run separately. Rental-amount refunds (cancellation, early return, no-show inside your policy window) are outbound transfers from your Paymos balance to the renter's wallet, amount per your cancellation policy. The security deposit is handled on its own: the renter paid it on-chain, so on a clean return you send it back in full in one transfer — minutes to an address you've already whitelisted, with a one-time 2FA step to add a new one. Paymos only charges its percentage on a settled rental — there is no extra platform fee layered onto either refund.

That is exactly the segment the wallet rail opens. Card processors decline cross-border transactions on fraud heuristics (a German card at a Costa Rica counter, a Russian card almost anywhere), while USDT and USDC work in any jurisdiction with internet. For exotic-car fleets, RV operators in tourism hotspots, and destination-market operators, this is real booking-conversion upside without changing your risk posture. Let the renter pick the network and stablecoin they already hold — commonly USDC on Polygon or USDT on Tron.

Paymos settles each booking in full to your Paymos balance, and your platform then distributes the host and cleaning-crew shares on its own schedule using your back-office automation. Paymos doesn't split one payment across multiple destination wallets or run Connect-style sub-merchant payouts — it is the inbound collection rail, and the host-and-crew distribution stays in your settlement logic. This is the standard pattern for P2P platforms with their own payout rules.