Aug 2026 - Sep 2026
MerchantAgent
A shop assistant for payments, orders and daily records in Hindi, English or Hinglish. Merchants manage stock and expenses, while customers browse products and request checkout links. The two agents have separate permissions, and payment links use Razorpay test mode.
- CONTEXT
- Razorpay Buildathon
- FOCUS
- Agent workflows and backend
- STACK
- FastAPI, PydanticAI, Next.js
- DATA & PAYMENTS
- PostgreSQL, pgvector, Redis, Razorpay
Overview
MerchantAgent lets a small shop manage routine work through a conversation. A merchant can ask for a customer's payment link, update a product or check the day's collections without moving through separate forms.
I built the merchant and customer interfaces, agent workflows and backend around a shared set of store records. Each agent has different permissions. Payment links use Razorpay test mode, and campaigns require the merchant's approval before sending.
Why I built it
A payment request often starts with a name and an amount in a conversation. Turning that request into a checkout link, an order and an entry in the books can still mean several manual steps. I built MerchantAgent around that ordinary interaction.
The Razorpay Buildathon gave the project a practical scope: connect conversational requests to store operations in English, Hindi and Hinglish. The customer side matters too. Someone browsing a shop should be able to ask about stock and place an order using the same catalog the merchant maintains.
The problem
An agent can misunderstand a name, repeat a tool call or produce a confident answer from incomplete information. In a shop, those mistakes can create duplicate orders or give a customer the wrong price.
There is also a permissions boundary. A customer needs retail prices and their own checkout flow. They should not receive supplier details, cost prices or another customer's records simply because they are chatting with the same application.
Prices, stock and payment totals come from database queries. Semantic retrieval is reserved for contextual material such as store policies.
The solution
The merchant agent uses tools for catalog changes, expenses, customer lookup, orders and financial reports. It resolves people and products from stored records, so the merchant can use familiar names instead of database identifiers.
The customer agent has a smaller set of tools for browsing products, placing an order and requesting a payment link. A shop owner can join the customer's chat thread directly. On the merchant side, tool results become cards with actions such as copying a payment link or approving a campaign.
Approval belongs to the merchant
A campaign tool creates a draft. A separate approval endpoint handles the merchant's decision; the agent cannot approve its own campaign.
Repeated actions are checked within a turn
Payment, order and message tools compare request fingerprints with prior actions and reuse an existing result when the same action repeats.
Actions leave a record
Audit entries record the action, affected entity and timestamp, giving the merchant a way to inspect what happened.
From a request to a store action
Merchant or customer
A chat request reaches the appropriate agent.
Tool boundary
The agent selects a tool within its permitted role.
Store records
SQL supplies prices, stock and customer information.
Action and record
The tool performs the operation and writes an audit entry. Campaigns require approval.
Engineering decisions
FastAPI and PydanticAI coordinate the tools. PostgreSQL holds the business records, while pgvector supports retrieval over contextual knowledge. Keeping both kinds of data in one database avoids maintaining a separate vector service for this prototype.
Merchant replies stream through server-sent events. Customer conversations use WebSockets because the customer, merchant and agent can all send messages into the same thread. Redis supports session handling, and Razorpay secrets are encrypted before storage.
Voice input and read-aloud replies make the conversational interface usable without typing every request. They sit around the same tool-backed workflow, so changing the input method does not change how an order or payment link is created.
Outcome and next direction
The implemented flow connects onboarding, catalog management, agent chat, order records and test checkout. It demonstrates how a conversational request can become an inspectable operation with a visible result.
The next direction is WhatsApp access through its messaging API, so merchants can check stock, record expenses and request payment links from a familiar chat. The integration would use the existing agent tools and keep merchant approval for outgoing campaigns.
Demo
MerchantAgent walkthrough
MerchantAgent gallery
A closer look at the product and its workflows.
