Design an Airbnb-Style Wallet (OOD + Runnable Code)

Context

You are asked to design an in-app wallet system that supports both guests and hosts. The wallet must support wallet balances, payments (guest to escrow at booking time), refunds (escrow to guest), and payouts (escrow to host after stay). The system should record transactions and handle errors robustly. Implement an in-memory, runnable reference in a programming language of your choice.

Assume:

• Single currency (e.g., USD) and integer amounts in cents to avoid floating point issues.
• Funds are held in a platform escrow account between payment and payout/refund.
• In-memory storage is fine; concurrency control can be simple.

Requirements

1. Roles and Accounts
   • Guest and Host users, each with one wallet.
   • A platform escrow account to hold funds between payment and payout/refund.
2. Operations
   • Deposit (external → guest wallet)
   • Payment for a booking (guest wallet → escrow), tagged by booking_id
   • Refund (escrow → guest wallet), by booking_id
   • Payout (escrow → host wallet), by booking_id
   • Balance lookup for any wallet and escrow
3. Transaction Recording
   • Record every operation as an immutable transaction with: id, kind, amount (cents), currency, from_account, to_account, booking_id (optional), timestamp, and idempotency_key (optional).
   • Ability to list or query transactions by booking_id.
4. Error Handling
   • Insufficient funds
   • Over-refund/over-payout beyond the booking's escrowed amount
   • Currency mismatch
   • Invalid operation (negative/zero amount, unknown user/booking)
   • Idempotency: duplicate requests with the same idempotency_key must not double-spend; if parameters differ, raise an error.
5. Runnable Code and Demo
   • Provide runnable code (e.g., Python/Java).
   • Include a main function that demonstrates and asserts:
     • Creating a guest and host
     • Deposit $100 to the guest
     • Pay $60 for booking b1
     • Refund $10 for b1
     • Payout $50 for b1 to the host
     • Idempotent duplicate request does not double-apply
     • An error case (e.g., over-refund) is raised
   • Print final balances and a transaction log.

Notes

• Keep the design clean and extensible (OOD focus), then provide a concise in-memory implementation.
• Clarity and correctness of invariants (double-entry-style transfers, booking escrow accounting) are more important than advanced infrastructure.