Merchant Onboarding

A2B is designed so that the merchant does not need to understand blockchains. The on-chain layer lives entirely between the user's smart account and the A2B contract. From the merchant's side, the integration looks like any other modern payments-plus-delivery API.

Who Can Integrate

Any merchant that provides:

• A public API for listing items and creating invoices, and
• A delivery confirmation mechanism — webhook, polling endpoint, or any way to inform the Platform that the order has been fulfilled.

That's the minimum surface. The merchant does not need wallets, DIDs, smart contracts, signing keys, or an on-chain presence.

We have researched integration paths across many categories — digital top-ups, ride-hailing, travel, e-commerce, SaaS, long-tail commerce, agent virtual card infrastructure. The protocol does not privilege any particular category.

What the Integration Looks Like

The merchant exposes, at minimum:

1. A catalog / search endpoint. The agent queries for available items.
2. An invoice endpoint. Given a selection, the merchant returns:
   • A payment destination (address, or routing information the Platform can convert)
   • A payment amount (in the merchant's accepted settlement currency)
   • A unique invoice id
3. A delivery signal. When the order is fulfilled, the merchant emits the deliverable (code, URL, confirmation number, receipt) and marks the order as delivered.

Everything else — fund custody, policy enforcement, user consent, audit trail — is handled by ATEL Platform on the protocol side. The merchant receives settlement the same way they would from any other payment processor.

What the Merchant Gets

• Access to agent-driven demand. Users talking to AI agents can buy from you without leaving the conversation. You become part of the agent ecosystem without building an agent stack.
• Cryptographic proof of delivery. Every order the merchant fulfills produces an on-chain record of the fulfillment hash. Chargebacks and post-hoc disputes can be resolved with data rather than narrative.
• Stable settlement behavior. Funds arrive only after the contract sees a committed invoice matching the merchant's quote. The on-chain flow does not allow partial drainage or silent redirection.
• A simpler surface area than crypto-native integrations. The merchant does not need to manage wallets, signing keys, or chain-specific fees. The on-chain complexity is absorbed by the Platform.

What the Merchant Has To Agree To

• Idempotent delivery confirmation. The contract and the audit trail assume a given order either reaches DELIVERED or FAILED — flickering between states will cause the Platform to flag the audit.
• Honest deadlines. If you quote a delivery window, the Intent's deadlineUnix will respect it. Orders that miss the window auto-refund; the merchant does not get paid on expired orders.
• Sealed deliverables. Sensitive deliverables (gift card codes, credentials) are returned through the Platform's delivery endpoint and get sealed to the user's public key. The merchant does not have to implement the encryption — the Platform handles it — but must return the plaintext deliverable so the envelope can be constructed.

Integration Model Variants

Different merchant APIs lend themselves to different integration patterns. We typically recognize:

• Direct Platform-merchant integration. The Platform calls the merchant's API and receives webhooks. Simplest, covers the common case.
• Third-party aggregator integration. When the merchant is reached through an aggregator API (e.g. an aggregator that covers many gift card brands), the aggregator plays the same role as the merchant from the protocol's perspective.
• Agent virtual card integration (infrastructure variant). An agent-issued virtual card can be accepted at any merchant that accepts that card network; the on-chain side governs the card's top-up and per-spend authorization.

Starting an Integration Conversation

If you run a merchant or aggregator that wants to plug into A2B, get in touch through the channels listed in Resources · Changelog. Technical specifics — webhook shape, authentication, currency handling, chargeback semantics — are sorted out jointly; the protocol does not prescribe them beyond what this page describes.