Merchant Infrastructure
The execution layer is here. The merchant layer is missing.
Across 2026 the card networks, PSPs, and clouds shipped the rails for agents to discover, authenticate, and pay. Every one of them still runs on merchant truth that lives outside the rail.
Obenan governs that merchant layer for physical-location businesses: identity, hours, categories, services, menus, reviews, and availability, kept current and safe to act on before an agent or a payment ever reaches the merchant.
Le Petit Quartier, 200m away. Butter croissant listed at 3.20 euros.
Warning: hours were last updated 47 days ago. Menu pricing not confirmed by merchant. Cannot verify current availability.
An AI agent receives a simple request: book a table for two at a nearby restaurant for Tuesday at 7pm.
The agent finds three restaurants. One has strong reviews and looks available. The agent proceeds to book.
The booking fails. The restaurant closed on Tuesdays three weeks ago. The hours shown were scraped from an outdated listing. The agent had no way to know.
The rail could execute the payment. Nothing made the merchant side true first. That is the layer the agent never had.
Infrastructure significance
Where the cascade starts
Every downstream system in the commerce stack, from discovery to settlement, assumes merchant identity, availability, and current business truth are correct before it acts. When those facts drift, the failure does not surface at payment. It surfaces as a payment that should never have been made.
Discovery
Agents find fragmented listings, stale hours, and unconfirmed details. They cannot distinguish current truth from outdated guesswork.
Booking
The booking attempt reaches a merchant whose availability has changed. The slot no longer exists. The customer experience fails.
Checkout
Cart and pricing data are built on unverified merchant inputs. Corrections arrive after the customer commits.
Payment
The transaction processes against merchant details that were never confirmed. Disputes and failures follow.
For commerce platforms, PSPs, acquirers, and payment networks: your rails can authenticate the agent and move the money. They cannot author whether the merchant can actually honor what was bought or booked. Obenan sits upstream with governed merchant truth, approval-aware corrections, and a safe-to-act boundary, so the merchant side is current before your stack engages.
The difference
What changes when merchant truth exists
Without the Merchant Layer
Fragmented listings across dozens of directories
Hours, menus, and availability scraped from the open web
No way to confirm what is current right now
The agent can guess, but cannot act safely
With the Merchant Layer
Structured merchant identity and location truth from a governed source
Freshness context across hours, services, menus, and contact details
Merchant-confirmed corrections and approvals before the agent proceeds
Agents and downstream systems move forward with bounded confidence
How it works
Three states. One clear path.
From discovery to action, each merchant moves through three simple states.
Mon-Sat 9:00-18:00
Tue 15:00
Haircut, Color, Styling
€35 - €120
The agent can find the merchant and understand the core facts: identity, location, category, hours, services, and public contact details.
Two systems, one truth
How the Merchant Layer works
The Merchant Layer operates through two connected systems. One keeps merchant truth, reviews, and discovery signals current. The other makes that truth available to agents and downstream systems with confidence boundaries.
The Discovery Layer
AI agents and platforms query structured merchant data, including identity, hours, categories, services, menus, contact details, and freshness context. The layer returns what is known and what still needs confirmation.
- Structured business identity, location, category, and contact data
- Hours, services, menus, attributes, and availability context with freshness signals
- Explicit uncertainty flags and safe-to-act boundaries when information cannot be confirmed
Read-only. Always available.
The Merchant Management Layer
When a detail needs correction, the management layer reaches the merchant or operator through dashboard, MCP, or lightweight confirmation workflows. The same approval rules and governance stay in place.
- Field-level validation for hours, categories, services, descriptions, contact details, and other business facts
- Lightweight operator interaction: confirm, correct, delegate, or hold for review
- Approved changes update connected discovery surfaces and machine-readable merchant publishing
Merchant-controlled. Action-ready.
The merchant side
One message. One decision.
No app to download. No system to learn. The merchant stays in control.
A customer is asking about Tuesday at 3pm. Is this time available?
Just now
No new workflow to manage. One message arrives. The merchant confirms, corrects, or pauses. That is it.
Clear boundaries
What Obenan does not do
Does not process payments
Does not host checkout
Does not handle card data
Does not replace the booking system
Does not replace the POS
Obenan sits before booking systems, checkout flows, PSPs, acquirers, and payment networks. It makes the merchant side current before any downstream system has to act.
For commerce platforms, PSPs, acquirers, and payment networks, the Merchant Layer makes physical merchants usable by AI before booking, checkout, and payment. When merchant truth is wrong, the flow breaks before a payment can succeed, or worse, after. Obenan does not replace the payment stack. It makes the merchant side true before the payment stack engages.
By industry
Merchant infrastructure, vertical by vertical.
The same governed merchant truth, shaped for the way each industry is booked and paid. Dining leads, with more verticals following.