Payments & Stripe

Last updated: August 12, 2026

Lendumine is a peer-to-peer marketplace for borrowing equipment. Members list items they already own; other members borrow them for a period of days. Lendumine does not own, hold, inspect, ship, or price any of the items, and it is not a party to the rental itself. Every payment described below is a payment between two members, processed by Stripe Connect.

1. The Stripe model we use

Stripe Connect, Express connected accounts, separate charges and transfers.

We use separate charges and transfers rather than destination charges deliberately, because the recipient of the money is genuinely not known at the time the payment is taken. A rental may complete — in which case the lender is paid; be cancelled — in which case the borrower is refunded; or be re-priced mid-rental by mutual agreement of both members. Funds are therefore collected against one specific rental and settled once its outcome is known.

Every lender is a connected account requesting both transfers and card_payments capabilities, so a lender is a genuine seller on the platform rather than a remittance destination.

2. Lender onboarding

A lender cannot accept a paid rental until their Express account exists and is payouts_enabled. That check is a live call to Stripe on the accept path, cached for 15 minutes and refreshed by the account.updated webhook; a lender who has never onboarded always reaches Stripe live. If the check fails, the acceptance is rejected and the borrower's card is never touched.

Rentals priced at $0 — items a member lends for free — require no connected account, because no money is collected.

3. Money flow, per rental

1. Collection. When the lender accepts the request, one PaymentIntent is created on the borrower's saved card for the rent plus any refundable security hold. It carries transfer_group = rental_<rental_id>, binding the payment to that single rental, and on_behalf_of = <lender's connected account>, making the lender the business of record. The PaymentIntent and its charge are both recorded against the rental.
2. Escrow. The funds sit in the platform balance, allocated in our ledger to that one rental and to no one else. This is the period during which the outcome is still unknown — the item has not yet been handed back.
3. Settlement on completion. A Stripe Transfer is created to the lender's connected account with source_transaction set to the charge that funded it, so the payout is the settlement of one identified payment rather than a withdrawal from a pooled balance. It carries the same transfer_group, and its amount is the rent less our commission. Stripe then pays the lender out to their bank on its normal schedule.
4. Settlement on cancellation. The rent and any hold are refunded to the card that paid them. No transfer is created and no commission is taken.

4. Refundable security holds

A lender may attach a refundable security hold when they accept, sized to the item's value and to how well they know the borrower: nothing, a flat community hold, 25% of the item's value (floored at $25 and capped at $100), or the item's full value. The amount is computed server-side from the listing's declared value — the app only ever submits the chosen tier.

The hold is collected in the same PaymentIntent as the rent, so rent and hold can never half-land, and it is refunded to the borrower's original card when the lender confirms the item is back. It is never paid out to the lender as part of settlement.

5. Our commission

Lendumine retains an 8% commission on the rental amount. It is taken at settlement, deducted from the transfer to the lender, and booked to a dedicated ledger account. The rate is server-authoritative and is disclosed to the lender, in dollars, on the screen where they accept the rental — before they commit.

6. What we deliberately don't do

• No stored value. There is no member balance to load, spend, or withdraw. The functionality that once allowed it was removed and every legacy balance was written off through the ledger. A rental is always card-funded.
• No manual remittance. We never collect proceeds and later pay members by hand. Every payout is a Stripe Transfer sourced from a specific charge.
• No holding of consumer funds. Refunds return to the original payment method. Lender earnings live in the lender's own Stripe balance, not ours.
• No sales, no inventory, no shipping. Items are handed over in person between members. See Our Marketplace.

7. Controls and reconciliation

• Disputes. charge.dispute.created freezes the charge, so settlement cannot pay a lender out of money that is being clawed back.
• Reversals. transfer.reversed posts a compensating ledger entry and notifies the lender.
• Capability changes. account.updated refreshes the cached payout status, so a lender who loses payouts immediately stops being able to accept paid rentals.
• Payout failures. payout.failed notifies the lender to correct their bank details.
• Retries. If Stripe is slow at the moment a rental closes, settlement is deferred and retried hourly. Every Stripe call carries a deterministic idempotency key, so a retry can never double-pay.
• Double-entry accounting. Every movement of money is a balanced ledger transaction, enforced by database constraints rather than by convention, and reconciled against Stripe's own records.

8. Card data

Lendumine never sees or stores a card number. Card details are entered directly into Stripe's payment sheet and are held by Stripe. We keep only a Stripe customer reference and the brand and last four digits Stripe reports back, so a member can recognize their own saved card. Our Stripe secret key is held in an encrypted server-side vault and is never present in the mobile app.

Questions about any of the above: hello@lendumine.com.