Payments & Stripe

Last updated: October 18, 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 both payouts_enabled and charges_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.

Both capabilities are required, for two separate reasons. payouts_enabled means we know where the lender's money is going before we take any of it. charges_enabled is what lets us name that lender as the business of record on the charge itself. There is deliberately no fallback to a platform-only charge: a lender still finishing their setup is asked to complete it, and the rental is simply not collected until they have. The rule lives in a single function used by every path that charges for a lender's sale — the initial acceptance and both mid-rental re-pricing paths — and is enforced again inside the charge helper itself, so no future code path can bypass it.

Rentals priced at $0 with no security hold — items a member lends for free, often between friends — require no connected account, because no money is collected.

A rental that carries a security hold requires the lender's connected account even when it is free, because a hold that is captured (the item was not returned) is paid to that lender. The hold's PaymentIntent therefore names the lender as on_behalf_of from the moment it is placed.

3. Money flow, per rental

1. Collection. When the lender accepts the request, one PaymentIntent is created and captured on the borrower's saved card for the rent plus Lendumine's service fee. Any security hold is a separate PaymentIntent with capture_method=manual — an authorization only. Both carry transfer_group = rental_<rental_id>, binding them to that single rental, and on_behalf_of = <lender's connected account>, making the lender the business of record. Every PaymentIntent and charge is 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 full rent — the lender's price, with nothing deducted. The service fee stays with the platform. The hold's authorization is cancelled. Stripe then pays the lender out to their bank on its normal schedule.
4. Settlement on cancellation. The rent and the service fee are refunded to the card that paid them, and the hold's authorization is cancelled. No transfer is created and no fee is kept.

4. Refundable security holds

Each listing carries a hold policy (a hold for every borrower by default; optionally none for the lender's friends, or none at all). When a borrower sends a request, the server decides the hold from that policy and from how the two members know each other — a flat community hold, 25% of the item's value (floored at $25 and capped at $100), or the item's full value — and the borrower is shown the exact amount before sending. When accepting, the lender may lower it, never raise it.

The hold is an authorization, not a charge: nothing is captured, and it is released (the PaymentIntent is cancelled) when the rental closes. Because an off-session card authorization expires after as little as 4 days 18 hours (Visa), a rental with a hold is limited to 5 days, and any hold close to expiring while the rental is still open is replaced by a fresh authorization before the old one is released.

If an item is not returned, the lender reports it from the booking. The borrower is notified and has 48 hours to return it or reply; if they do neither, the hold is captured and transferred to the lender with source_transaction set to that capture. A reply postpones the capture to five days after the report; a dispute where the borrower says it was returned is decided by our support team. These are the only paths by which a hold is ever captured.

5. Our service fee

Lendumine's revenue is a 10% service fee paid by the borrower, on top of the rent. It is collected in the same captured charge as the rent, recorded as its own part of that charge, and booked to a dedicated ledger account; it is refunded with the rent on a cancellation. It is disclosed to the borrower on the listing page and itemised in the total before they send a request, and the request records the rate the borrower was shown — the server refuses one sent at a rate that is no longer current. The lender is paid their full price.

A paid request from an app version released before this fee existed is refused with a message that states the fee and the total, because that version cannot show the borrower the fee. No booking withholds anything from the lender's transfer. Stripe's processing fee is paid by Lendumine out of its service fee. Prepaid and gift cards are not accepted.

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.