Build a Simplified Venmo-Style Peer-to-Peer Payments App with AI Tools

In a coding round where any AI coding assistant was allowed, the task was, roughly, to build a simplified Venmo: a peer-to-peer payments app in which users hold a balance and send money to one another. The report gives no more detail than that, so agree on the scope before generating any code. Unless the interviewer says otherwise, assume this core:

• create a user;
• add funds to a user's balance (a simulated deposit from a bank account or card);
• send a payment from one user to another, with an optional note, and reject a payment that would overdraw the sender;
• show a user's balance and transaction history, newest first.

create_user("alice"); create_user("bob")
deposit("alice", "50.00")
pay("alice", "bob", "20.00", note="dinner") -> ok
pay("bob", "alice", "30.00") -> rejected: insufficient funds
balance("alice") -> 30.00 balance("bob") -> 20.00
history("bob") -> [received 20.00 from alice, note "dinner"]

Clarifying Questions

• What should be delivered: a library with tests, a REST API, a user interface, or several of these? Is any language or framework acceptable?
• Must data survive a restart, or is in-memory storage acceptable for the round?
• Can a balance go negative, and is there a limit on a single payment?
• Can a user pay someone who has no account yet, or only existing users? Is there a friends list?
• Is the history private, or should there be a social feed of friends' payments with visibility settings?
• Is there only one currency?

Part 1 — Users, balances and payments

Implement the core: users, deposits, payments with an overdraft check, balances, and each user's history, with tests.

What This Part Should Cover

• An exact money representation, with validation of amounts and users
• A payment that updates both balances and the history together or not at all
• Tests for the overdraft rule, invalid input and the history order

Part 2 — A payments service that is safe under retries and concurrency

Expose the core as a small service, for example REST endpoints over a database, and make it safe when two payments from the same user arrive at the same moment and when a client retries a payment after a timeout.

What This Part Should Cover

• The endpoints, and where the sender's identity comes from
• An atomic check-and-debit that cannot overdraw under concurrent requests
• Idempotent retries that never apply a payment twice
• A data model from which every balance can be audited