Inspiration
The customer is ready to buy. The sale is still stuck in a DM.
Small shops sell through conversations: answering questions, checking prices, arranging delivery and chasing payment. I built Sales Desk to help with those conversations. Sales Desk Pay connects the order to PayPal checkout, while keeping the seller in control.
It also tackles a dangerous shortcut: treating "I've paid" or a receipt screenshot as proof that money arrived.
What it does
Sales Desk Pay helps a shop turn a customer conversation into a paid order.
The assistant answers questions and prepares quotes using the shop's catalogue. When the buyer agrees, the order waits for the owner's approval. Only then does the assistant create a PayPal order and send the checkout link.
After payment, PayPal sends a webhook. The app verifies it through PayPal's verification API and checks the order, amount, currency and capture status. Only a matching, verified completed payment can mark the order Paid. The assistant then tells the buyer.
The owner manages orders in an AG Grid Community board. A second grid shows the PayPal events and how the app handled them.
How I built it
The backend uses Python, aiohttp and SQLite. PayPal Orders v2 creates checkout links, Capture collects approved payments, and webhook verification controls payment confirmation.
The chat layer supports Meta Muse Spark, Claude and Gemini. Models interpret messages and propose actions; application code checks those actions. Prices come from the catalogue, and the model has no action that can confirm payment. Receipt-reading AI can help inspect a screenshot, but its interpretation cannot mark an order Paid.
The demo uses a phone simulator and Zuri Cloth, a fictional UK fabric shop. This lets judges try the conversation without connecting a WhatsApp account.
I extended my existing MIT-licensed Sales Desk prototype for this entry. The PayPal integration, approval gate, webhook checks, forged-payment evaluation, AG Grid board and UK demo shop were added for this hackathon. The README documents the changes.
Challenges
My first sandbox seller account could not receive the test payment. I created a UK Business sandbox seller, connected a new Merchant app and registered its webhook.
Another challenge was separating conversation from payment authority. A buyer, screenshot or model response must never be able to bypass PayPal's confirmation.
What I tested
An actual GBP 28 sandbox payment completed successfully. Its verified webhook marked order ZC-11 Paid, and the assistant sent the buyer a confirmation.
The offline evaluation tried 30 forged messages, receipt screenshots and webhook cases. Zero marked an order Paid. The valid-payment control passed.
The project also passes 45 automated tests, including signature failures, duplicate events and mismatched payment details. These are measured test results, not a claim that every possible attack has been solved.
What I learned
A useful sales agent needs clear limits on its authority. It can prepare an order and request payment, while the owner approves checkout and PayPal confirms receipt of funds.
What's next
Refund and dispute handling, a persistent hosted demo, and trials with real sellers. The current payment flow is a sandbox prototype.
