# inite.shop — Full Content Dump

> Agentic commerce — connect your catalog once, sell everywhere AI talks

inite.shop is an e-commerce platform for the agent era: products, orders, inventory, analytics, finance, plus AI sales via ChatGPT, WhatsApp, Telegram and voice. Multi-tenant, multi-currency, multi-language.

Source URL: https://inite.shop
Locale: en
Generated: 2026-06-05T00:48:24.398Z

---

# Agentic Commerce: What Changes When the Buyer Is an LLM

URL: https://inite.shop/en/blog/agentic-commerce-protocol
Date: 2026-05-05
Author: INITE
Category: strategy
Tags: agentic-commerce, ai, checkout


A retail website is a UI optimised for a human in a hurry: hero banner, search box, faceted filters, cart drawer, three-step checkout. Every pixel assumes a pair of eyes. The new buyer doesn't have eyes. It has a prompt and a tool registry.

## What "agentic commerce" actually means

When a customer asks ChatGPT for "a black wool coat under €300, ships to Germany," and the LLM calls a tool that lists matching SKUs from your catalog, you're already in agentic commerce. The website never opens. The customer never sees your stock photography. They see one paragraph the model wrote and a buy button.

<Note title="What this is not">
"AI helps customer find product on website" is still plain web traffic — not agentic commerce. Agentic commerce is when the entire transaction — discovery, cart, payment, fulfilment update — happens inside an AI conversation, and your website is one of N data sources behind a model.
</Note>

## The merchant-side shift

Three things change for the merchant:

1. **Catalog goes from HTML to structured data.** The model doesn't read your product description copy; it reads the schema. Title, brand, attributes, stock, price, currency, return policy — every field that used to be optional is now load-bearing. Missing `availability` and your SKU is invisible.
2. **Storefront-as-Tool.** Your store ships an MCP server (or ACP endpoint) exposing `search_products`, `get_product_details`, `add_to_cart`, `create_checkout_session`. The customer's AI calls those tools. You don't run the conversation; you run the inventory of the conversation.
3. **Brand happens earlier.** The customer doesn't browse your storefront, so you can't recover with great photography or microcopy. Whatever the model says about your brand at the moment of comparison is what your brand is. That signal lives in the structured data + the model's training, not your website.

## What still works

- **Real-world fulfilment.** AI picks the SKU; humans still pack the box. Anything tied to physical reality (warehouses, shipping speed, return windows) is unchanged.
- **The merchant of record.** Payment processing, tax calculation, refund policy — these stay where they were. The model is a discovery and decision layer; settlement is identical.

## What stops working

- **Funnels.** "Visitor → cart abandoner → email retarget" assumes a website session. AI sessions don't return; the customer asked about coats once, the model answered once. You either won at the moment of comparison or you didn't.
- **Discount codes as marketing.** A code makes sense when a human can type it. An LLM that sees `BLACKFRIDAY30` in your sitemap will use it for everyone, every time. Discount logic moves into rules the model evaluates: "for repeat buyers, X; otherwise Y."

## The two-year forecast

A chatbot bolted onto your existing site doesn't win agentic commerce. The catalog wins it — when you treat it as a programmable surface (versioned, schema-typed, idempotent on writes) and demote the storefront UI to a separate read view.


---

# One Stock Number, Six Sales Channels: How Multi-Channel Inventory Actually Breaks

URL: https://inite.shop/en/blog/multi-channel-inventory-truth
Date: 2026-04-22
Author: INITE
Category: operations
Tags: inventory, operations, multi-channel


The dream is: one product table, six sales surfaces, and the stock count just works. The real problem is the unit of consistency, not the surfaces.

## The race condition every multi-channel store hits

Two customers, two channels, last unit in stock.

- **00:00.000** — Customer A on the website opens the PDP. Server reads `stock = 1`.
- **00:00.040** — Customer B in Telegram asks the bot, "is this still available?". Bot reads `stock = 1`. Replies "yes."
- **00:00.180** — Customer A clicks Buy.
- **00:00.220** — Customer B says "I'll take it." Bot calls `add_to_cart`.
- **00:00.310** — Customer A's checkout writes `stock -= 1` (now 0).
- **00:00.350** — Customer B's checkout writes `stock -= 1` (now -1).

You have an oversold inventory and one of them is going to get an apology email.

<Warning title="The seductive non-fix">
Adding a `if (stock > 0)` check before the decrement doesn't fix it. The check and the write aren't atomic across channels — both reads happen before either write. The fix is at the database layer, not the application layer.
</Warning>

## What works: pessimistic write at the SKU row

Every cart-add or checkout that wants to consume stock takes a row-level lock on the SKU row, reads the current count inside the lock, decides, writes, releases. The website blocks for 50ms while the Telegram bot finishes its decrement; the second one sees the truth and bails. Both customers get the right answer.

In Prisma:

```ts
await prisma.$transaction(async (tx) => {
  const product = await tx.product.findUnique({ where: { id }, select: { stock: true, trackStock: true } });
  if (product?.trackStock && product.stock < qty) throw new Error("OUT_OF_STOCK");
  await tx.product.update({ where: { id }, data: { stock: { decrement: qty } } });
});
```

SQLite serialises by file lock; Postgres serialises by row lock; either way the second transaction blocks until the first commits.

## What doesn't work: caching

Read replicas, Redis caches, denormalised stock-counts-per-channel — all of these win latency on the read side and lose correctness on the write side. The inventory write must be authoritative; read paths can be cached, but the cache must be invalidated synchronously on every write or it lies to the next channel that asks.

## What goes wrong with reservations

Many platforms try to "reserve" stock when the cart starts and "commit" at checkout. This works until the cart is abandoned and nobody clears the reservation. After three months, your authoritative stock and your displayed stock have drifted by 40%. The fix is a reservation TTL — reserved stock auto-releases after N minutes of cart inactivity.

## What the AI channels add

Each AI channel — ChatGPT, Telegram, voice — is a tool consumer talking to your store. The race-condition surface multiplies, but the fix doesn't change. Tool calls hit the same atomic decrement. The AI doesn't know it's in a race; the database does.

The merchants who never have an oversold incident treat inventory as a bank account: every withdrawal locks first, reads inside the lock, decides, writes. Boring, fast, correct.


---

# Checkout Without the Page: How AI Conversations Replace the Cart Drawer

URL: https://inite.shop/en/blog/checkout-without-the-page
Date: 2026-03-30
Author: INITE
Category: engineering
Tags: checkout, agentic-commerce, payments


The classic e-commerce checkout is a sequence of pages. Cart, address, shipping method, payment, confirmation. Every page transition is an opportunity for the customer to drop. Every form field is friction.

## The new shape

In an agentic checkout, none of those pages render. The customer's AI assistant has been collecting information across the conversation — name, default shipping address from prior orders, preferred payment method — and it submits a single tool call:

```jsonc
// LLM tool call
{
  "tool": "create_checkout_session",
  "params": {
    "items": [{ "sku": "TSHIRT-BLK-M", "qty": 1 }],
    "shipping_address_id": "addr_default",
    "payment_method_id": "pm_default",
    "currency": "EUR"
  }
}
```

Your storefront returns either a `payment_link` (delegated payment — customer confirms in Stripe / Apple Pay / a wallet) or a `committed_order` (passwordless one-tap path, where the customer's AI has already authenticated payment for routine purchases).

## What the merchant has to expose

For this to work, the storefront ships:

1. **An MCP / ACP server** with read tools (`search_products`, `get_product_details`) and write tools (`add_to_cart`, `create_checkout_session`).
2. **Idempotent writes.** The model retries failed tool calls. If `create_checkout_session` runs twice, you create one order, not two.
3. **Stable customer identity across channels.** A customer who has bought from your web store should be recognisable to your AI tool calls — same `customer_id`, same address book, same payment methods.

<Tip title="Idempotency in 1 line">
Have the model pass an `idempotency_key` (a stable hash of "this is the same intent"). Server stores `(merchant, key) → result` for 10 minutes. Second call with the same key returns the cached result instead of a second order.
</Tip>

## Where the friction moved

Friction didn't disappear; it moved to authentication. The first time a customer's AI buys from your store, somebody has to authorise payment + shipping. After that, the friction is zero — every subsequent purchase is one tool call.

The website checkout page isn't dead. It's just become the fallback path for the first-time customer or the customer who isn't using an AI assistant. The aspirational path is "no page loads at all."


---