Loading
AI SALES CHANNEL FOR MERCHANTS
Make your store sellable to AI.
SELLABLE gives your business an AI sales agent that can discover products, negotiate within your rules, recommend relevant add-ons, and help complete purchases safely.
Live · ledger trace
trace01/08
Real catalog · Real transactions · Razorpay-powered checkout
Payments currently run through Razorpay Test Mode — no real money is moved.
Policy enginedeterministicLedgerrecordingRailsrazorpay · test
catalog.search3 products indexedquote.created₹1,948 · groundednegotiation.counteredfloor protectedpolicy.checkedALLOWconsent.issuedsingle-usewebhook.reconciledsignature verifiedorder.paidsettled
01
0
POLICY CHECKS
deterministic — grounding → floor → HITL
02
0
AGENT TOOLS
search · get · quote · negotiate · upsell · policy
03
0%
LEDGER COVERAGE
every money action explained
04
···
PAYMENT RAIL
razorpay test · signed webhooks
02 — THE PROBLEM
AI can recommend. But can AI actually buy?
An AI assistant can recommend a product in seconds. But a real purchase is a chain of dependent steps — and most stores can't serve any of them to software.
On the merchant's side it's worse: nobody can safely hand an AI unrestricted control over prices, discounts, inventory, orders, and payments.
SELLABLE connects these two sides. It gives merchants an AI seller — and gives AI buyers a way to transact with real merchants.
What a real purchase requires
- 01Find the right merchant
- 02Find the right product
- 03Check availability
- 04Get a price
- 05Negotiate
- 06Respect the buyer's budget
- 07Get authorization
- 08Pay
- 09Verify the payment
03 — TWO AGENTS
One platform. Two agents.
The Seller Agent represents the merchant. The Buyer Agent represents the customer.
Your AI Seller
Your AI sales representative.
- Understands what a buyer wants
- Searches the real store catalog
- Recommends products and creates quotes
- Negotiates within merchant-defined limits
- Suggests relevant add-ons
- Guides the buyer toward checkout
It cannot override merchant rules or directly decide payment outcomes.
The AI Buyer
An AI acting on behalf of a customer.
- Discovers stores
- Researches products
- Requests quotes
- Negotiates and compares options
- Requests authorization
- Purchases and verifies the result
Humans buy through the same seller — chat checkout uses the same catalog, rules, and consent. The Seller Agent is the merchant's sales layer, not just a chatbot.
CUSTOMER
AI BUYER
“I need 10 chairs under ₹60,000”
SELLABLE
AI SELLER
“I can offer these within store rules”
MERCHANT
AI Buyer wants the best purchase. AI Seller wants the best sale. SELLABLE makes the transaction safe and controllable.
You set the boundaries. Your AI sells within them.
SELLABLE lets the AI handle the conversation while you remain in control of the business rules.
Productswhat the store actually sells
Pricesnormal selling prices
Minimum priceshow low the AI can negotiate
Selling ruleswhat the AI can and cannot do
Approval limitswhen a human must approve a purchase
Your catalog is the source of truth — the AI Seller recommends, quotes, and negotiates from the products you actually stock. The AI does not invent products or prices.
04 — HOW IT WORKS
From “I need something” to a completed purchase
Six steps. Every one is checked against your rules, authorized by consent, and written to the ledger.
01
Discover
An AI buyer finds your store. Your store exposes information that AI agents can understand — no HTML rendering required.
02
Understand
The AI Seller understands what the buyer needs and searches your real products — never invented ones.
03
Negotiate
The agents can negotiate. The Seller Agent may offer a better price, but it can never go below the minimum you set.
04
Recommend
The Seller Agent suggests useful add-ons — a laptop plus a compatible sleeve — within price, category, and budget.
05
Protect
Rules and authorization control the transaction. High-value purchases can require human approval, and payment needs explicit consent.
06
Pay & verify
Razorpay processes the payment and a signed webhook confirms the result. The full transaction can then be replayed.
05 — MERCHANT VALUE
Turn AI conversations into revenue.
No staged numbers below. Each lever runs on data you already own — your catalog, your floors, your ledger — and every outcome links back to a transaction you can replay.
Contextual upsells
catalog.upsell_skuThe add-on you linked, offered at the right moment
When you add a product, you link its natural add-on. The Seller Agent may offer that add-on — and only that add-on — when it fits the buyer's budget and category mandate. It cannot invent one.
Buyer approvesLaptop · ₹52,000
Agent offers, linkedSleeve · ₹1,299
Budget check₹53,299 ≤ ₹55,000 — passes
Order becomes₹53,299
+₹1,299 the buyer was already willing to spend — captured because the link was yours.
Margin-protected negotiation
POLICY.floor_priceConcede a little to save the whole order
A buyer pushing for ₹4,500 on a ₹6,000 item walks away from a static store. Your agent counters inside your floor — and the floor itself never moves.
List price₹6,000
Buyer offers₹4,500
Below floor — blockedno order created
Agent counters₹5,700
Deal closes₹5,400
Your floor, untouched₹5,000
₹600 conceded to save a ₹5,400 order. A walk-away would have earned ₹0.
Transaction insights
GET /console/insightsComputed from ledger events — never self-reported.
Upsell attach rateorders where the offered add-on was accepted
Negotiation successhaggling that ended in a paid order, not a walk-away
Discount concededhow much margin each closed deal actually cost
Walk-away reasonswhy lost deals died — price, stock, or budget
Saved dealsorders that exist only because the agent countered
Skeptical? Open Growth in the console — every metric expands into the transactions behind it.
Open Growth →06 — TRUST & SAFETY
Every money action is explainable, bounded, and gated
The core safety principle: agents propose, deterministic policy disposes, consent authorizes, and the ledger explains every material action.
01AGENT DISCOVERY
Machine-readable manifest at /.well-known/agents.json makes your store findable by autonomous AI buyers.
02POLICY ENGINE
Deterministic guardrails enforce max order value, floor prices, discount limits, and human-in-the-loop thresholds.
03CONSENT GATES
Single-use, time-bound, amount-bound consent tokens ensure no payment proceeds without explicit authorization.
04XAI LEDGER
Every material action creates a structured audit event with actor, reasoning, policy references, and outcome.
05NEGOTIATION
Bounded agent-to-agent negotiation within merchant policy — the LLM proposes, deterministic systems dispose.
PUBLIC API SURFACE
live
MERCHANT STORE
GET/.well-known/agents.json
GET/catalog.ai.json
GET/llms.txt
POST/agent/quotes.negotiate
POST/agent/orders.create
POST/webhooks/razorpay
ARCHITECTURE STATUS
AUDIT-READY
LATENCY target p95
< 200ms
AUDIT
100%
Every route above is served by the deployed backend at api.sellable.shop — discovery is public, transactions are HMAC-signed, settlement is webhook-verified.
07 — AI-NATIVE STORE
Your store, ready for the AI economy.
Your store isn't only a website anymore. It becomes a place that AI agents can understand, interact with, and transact with — no SEO games, no rendered pixels required.
/.well-known/agents.json
FETCHING…08 — EXPLAINABILITY
Every transaction has a story.
Don't just see that a sale happened. See why it happened. This is one trace, exactly as the ledger recorded it — actor, action, and reasoning for each step.
Actorwho acted — agent, engine, service, or human
Reasoningwhy the step was taken, in plain language
Policy refswhich deterministic rules were consulted
SAMPLE TRACE REPLAY
REPLAYING01catalog.search
3 catalog matches for the buyer's mission.
02quote.created
Grounded quote — 1 × coffee setup, ₹1,948, inside budget.
03negotiation.countered
Buyer offered ₹1,700 — countered at the policy floor, ₹1,899.
04policy.checked
ALLOW — offer above floor, within order limits, category permitted.
05consent.issued
Single-use token bound to amount, payee, and 10-minute window.
06order.created
Order created in AWAITING_CONSENT — payment still impossible.
07webhook.reconciled
payment.captured verified by HMAC signature — the only path to PAID.
08order.paid
Settled. Eight events on one trace — replayable line by line.
next: catalog.search
trc_9ede1020…0/8 EVENTS
ANIMATED ILLUSTRATION · REAL EVENT SCHEMA — the console replays live traces from the database in this format.
09 — LIVE STORY
Watch a sale happen, start to finish.
You sell office furniture. Nobody visits your site — yet at 09:47, ten chairs sell themselves:
Incoming message
“I need 10 ergonomic chairs for my office. My budget is ₹60,000.”
customer → her AI assistant
SELLABLE turns your store into an always-available AI sales channel.
Live story · 10 chairs
1/7CUSTOMER
“I need 10 ergonomic chairs. Budget ₹60,000.”
A facilities manager tells her AI assistant what the office needs. No website visit, no search bar.
09:41 · mission startedPLAYING
HOVER TO PAUSE · TAP A SEGMENT TO JUMP — the same shape as every real order in your ledger.
POLICY ENGINE · EVALUATING
✓
Catalog grounding
only SKUs the merchant actually stocks
··
Buyer categories
cart fits the buyer's mandate
··
Merchant categories
cart fits what the store sells
··
Floor price
offers below the merchant floor are countered
··
Buyer budget
cart fits the agent's spending mandate
··
Max order value
hard cap on every order
··
HITL threshold
above the line, a human decides
EVALUATING…Standard mission
DETERMINISTIC · NO LLM IN THIS PATH — the same cart always gets the same verdict.
10 — POLICY ENGINE
The gauntlet between intent and money
Before any order exists, the candidate cart crosses the deterministic policy engine — the same code path for every buyer, every time. The AI never sees this layer; it cannot argue, retry, or negotiate with it.
Groundeda SKU that isn't in your catalog cannot be bought
Boundedfloors, caps, and discounts are hard limits
Gatedabove your threshold, only a human can proceed
10 — MERCHANT CONSOLE
Mission control for your AI sales channel
Everything the backend does is observable and controllable from the console — scoped to your store, authenticated with your session, and honest about every failure.
What is happening in your store, right now
Revenue, agent-driven share, and pending approvals — plus a live event feed streamed from the ledger over SSE. Every number is derived from real orders; nothing is cached or faked.
Live SSE feedMerchant-scoped metricsSystem health from the backend
Real endpoints behind this surface
›GET /console/insights
›GET /activity/stream
10 — SECURITY MODEL
The security model is the product
Autonomous agents spending real money is a threat model before it is a feature list. Each control below is implemented in this codebase — with the file or mechanism named, not vibes.
THREAT CLASS
CONTROL
MECHANISM
Forged sessions
CONTROLES256 + JWKS
Supabase issues asymmetric access tokens. The backend verifies signatures locally against the project's JWKS — kid-matched, cached, rotation-aware — with strict issuer and audience checks.
sellable/supabase_jwt.pymerchant_users lookup
Privilege escalation
CONTROLSeparate auth from authorization
A verified identity says nothing about access. The user id is resolved through merchant_users to their own store; a user with no mapping gets onboarding, never demo data. Cross-merchant IDs are 404s.
merchant_usersper-merchant cores
Public database abuse
CONTROLRLS + zero anon grants
The anon key ships in browser bundles — so application tables carry row-level security and zero grants for anon/authenticated. Only the backend's service role touches data.
supabase/migrationsREVOKE + ENABLE RLS
Agent key leakage
CONTROLHash-only storage + replay guard
Buyer agents authenticate with API keys stored as SHA-256 hashes, or HMAC-SHA256 request signatures bound to timestamp, nonce, path, and body — with server-side replay protection.
BUYER_AGENT_API_KEY_HASHX-Signature + X-Nonce
Forged payment success
CONTROLWebhook-only settlement
No browser, agent, or admin endpoint can mark an order PAID. Only a signature-verified Razorpay webhook settles it — and duplicate deliveries are idempotent.
POST /webhooks/razorpayHMAC verification
Unbounded agent behavior
CONTROLDeterministic policy + consent
The LLM proposes; the policy engine disposes. Grounding, floors, caps, and thresholds are hard code. Payment requires a single-use, amount-bound consent token consumed exactly once.
sellable/policy.pysellable/consent.py
FULL AUDIT TRAIL: EVERY CONTROL ABOVE IS COVERED BY TESTS IN tests/ AND EXERCISED IN THE CASE STUDY.
10 — DEVELOPER API
One call makes your store agent-readable
A single search call gives AI buyers your full catalog — with real-time pricing, stock, and negotiation policy. Signed API keys keep every request authenticated.
Machine-readable catalog at /catalog.ai.json
Agent-to-agent negotiation within policy bounds
Single-use consent tokens for every payment
Append-only audit ledger with reasoning traces
zsh — catalog.search
EXAMPLE
$
ILLUSTRATED EXAMPLE — run it with your own key against api.sellable.shop.
Live on Razorpay test mode— webhooks verified
Ready to make your store sellable to AI?
Connect your products, define your selling rules, and let your AI seller handle the conversation.
Consent-gated Policy-bounded Ledger-audited