Optional Damage or Loss Deposit Feature

[mcull]

User Feedback

Type: Feature
Submitted by: Justin M. (SLFB:v1:cmfvebswm0002le047ys6goom:092b21f9)
Priority: P1

---

Optional damage or loss deposit: with high value and/or delicate items, even if the lender feels okay, I might not feel comfortable borrowing it without demonstrating my intent & ability to compensate the lender if they don't get it back in similar condition. A wet tile saw (Claude's example) is reasonably expensive, somewhat high theft risk, and can be damaged from misuse, but how else are you going to finish your tile project?

---

Thank you for this valuable suggestion! We will explore adding an optional damage or loss deposit feature for high value and delicate items to ensure peace of mind for all users.

Internal Notes:

• Auto-generated from feedback form
• User should receive email updates on this issue

[mcull]

Decision (Status: Deferred)

• We’re not adopting the “optional damage/loss deposit” feature right now. We want to avoid introducing money flows until we better understand natural borrowing habits and friction points. Once we have real usage patterns, we’ll revisit with clearer defaults and guardrails.

Proposed Approach (for future implementation)

• Core idea: Optional, per‑item deposit that borrowers accept during checkout. Prefer saving a card with explicit consent and only charging in case of damage/loss, to minimize friction and fees.
• Payments strategy (hybrid):
  • Primary: Save card via Stripe SetupIntent with explicit consent for off_session charge “up to $X” if damage/loss is reported.
  • Opportunistic auth hold: If loan duration ≤ 6–7 days and the card supports it, place a manual‑capture auth hold for the deposit on checkout; release on return. If the hold expires mid‑loan, fall back to saved‑card consent.
  • Adaptive deposit: Scale deposit by item value and borrower trustScore; high‑trust borrowers/low‑value items may require little/no deposit.

Data Model

• Item: depositAmountCents (int|null), depositPolicy ('none' | 'optional' | 'required').
• Borrow/BorrowRequest: depositStatus ('none'|'required'|'consented'|'hold_active'|'hold_released'|'charged'|'charge_failed'), depositCapCents, paymentMethodId, paymentIntentId (for holds), holdExpiresAt.
• Audit/Events: consent artifacts (timestamp, IP, UA, terms version), claim events, outcomes.

API & Flows

• Borrow request: if deposit applies, return depositRequired=true + depositCapCents.
• Checkout:
  • If no saved card, create SetupIntent; present clear consent text: “You may be charged up to $X for damage/loss.”
  • If short loan and eligible card, create PaymentIntent (manual_capture) for auth hold. Persist depositStatus.
• Return/damage claim:
  • Owner files claim with reason + photos. System charges off_session up to cap; if hold is valid, capture instead. Notify both parties.
  • Handle partial claims; cap cumulative charges at depositCap.
• Notifications: consent confirmation, hold placed/released, claim opened/approved/failed, charge succeeded/failed.

Compliance & Risk

• Terms: add clear off_session charge authorization up to deposit cap; store consent evidence.
• 3DS: allow/require 3DS during card save when needed; expect some off_session failures → provide retry flow/link.
• Marketplace/Connect: if needed, platform collects and transfers to lender or credits internally; document fee handling and dispute path.

UX Notes

• Item detail: badge “Deposit may be required,” tooltip explains amount/policy.
• Borrow flow: dedicated consent step with amount, saved card display, and add card path.
• Owner tools: per‑item toggle/amount, claim submission with evidence upload, status tracking.

Rollout Plan

• v1: Save card + explicit consent; no auth holds. Manual owner claim with off_session charge (up to cap).
• v1.1: Add short‑term holds for ≤7‑day loans; auto‑release on return.
• v1.2: Adaptive deposits (trustScore + item value), with owner overrides and per‑library defaults.
• v2: Admin dispute tooling, reporting, and automated claimant guidance.

Open Questions (to validate later)

• Default deposit cap (flat vs. tiered by item value)?
• Who receives claim funds (owner vs. platform wallet) and fee impacts?
• Evidence requirements and timelines for owner claims? Borrower dispute process?

Summary

• We’ll defer implementation to avoid complicating the product with payments too early. This plan documents a path that keeps UX light (no funds captured by default), leverages SetupIntents and short auth holds where appropriate, and provides a compliant consent trail and claim flow when/if we introduce deposits.