> ## Documentation Index
> Fetch the complete documentation index at: https://docs.4mica.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Go Live

> Prepare your agent integration for production.

Going live means your payment rules, monitoring, pricing, and claim process are ready for real buyers, real agents, and real collateral.

Do not treat a protected route as production-ready just because the happy path works. Agent traffic is automated, fast, and sometimes adversarial. The production surface needs clear pricing, strong logs, and controls for suspicious usage.

## Production requirements

Before you expose a route to production traffic, confirm the basics that protect buyers and your revenue.

| Requirement        | What to confirm                                                                                    |
| ------------------ | -------------------------------------------------------------------------------------------------- |
| HTTPS              | All protected routes use HTTPS.                                                                    |
| Production wallet  | `payTo` points to the seller wallet you intend to use in production.                               |
| Pricing            | Routes have stable prices or a clear quote-before-pay flow.                                        |
| Payment validation | Your server verifies and settles before serving paid work.                                         |
| Logs               | Request IDs, guarantee IDs, payer addresses, route, price, and settlement result are recorded.     |
| Monitoring         | Pending guarantees, clearing cycles, failed settlements, and invalid payment attempts are visible. |
| Rate limits        | Unpaid requests and failed payment retries are controlled.                                         |
| Support path       | Buyers have a way to raise disputes, refunds, and delivery questions.                              |

Use [4mica dashboard](https://app.4mica.io) for the final review of route pricing, your `payTo` address, settlement monitoring, and claim readiness.

<Warning>
  Do not move a sandbox route to production by only changing the network. Review the wallet, price, claim behavior, logging, and support path together.
</Warning>

## Launch checklist

### Trust and legitimacy

Buyers should be able to verify that they are paying the real service. Show your `payTo` address where buyers check payment destination, keep your public API domain and payment requirements consistent, and document what the route does, what it costs, and what counts as delivery.

If you use a marketplace, registry, verified profile, or ratings system, bind that identity to your payment address and domain. After launch, monitor for copied agent names, wrong domains, wrong `payTo` addresses, and fake payment requirements.

### Pricing and monetization

Each route should have a pricing model before traffic arrives. Decide whether it is fixed-price, metered, tiered, subscription-gated, or quote-based, then publish accepted networks and assets. Minimum payment amounts should still make sense after infrastructure, support, fraud, and downstream costs.

Keep dynamic pricing explainable before the buyer signs. If humans and agents should see different prices, use separate routes, policies, or metadata instead of hidden behavior.

### Microtransactions

For high-frequency traffic, use clearing cycles instead of trying to settle every tiny request on-chain. Signed guarantees and deferred settlement keep small payments practical, but you still need to require payment or a valid guarantee before expensive work starts.

Test sub-cent and small-dollar prices in sandbox with realistic traffic volume before you rely on them in production.

### Agent-to-agent controls

Treat other agents as normal x402 buyers unless your product needs extra identity checks. You can accept, reject, or price requests based on route, payer, metadata, policy, reputation, or your own allowlist.

Your agent should decline work that would cost more to fulfill than the payment covers. If your agent buys from another agent and resells the result, log each downstream paid call.

### Risk and abuse

Keep abuse controls close to the route. Limit unpaid pre-work, cap spend or request volume per buyer, agent, guarantee, API key, or wallet, and block suspicious payers or repeated invalid payment attempts.

Refund rules should be explicit before launch. Store delivery evidence for disputes and alert on missed settlement deadlines and defaults.

<Tip>
  Launch one production route first if you can. A narrow first route makes pricing, logs, claims, and support much easier to validate with real traffic.
</Tip>

## Production flow

1. The buyer or buyer agent calls your protected route.
2. Your API returns HTTP 402 with payment requirements.
3. The buyer creates a unique request ID and signs a payment guarantee.
4. The buyer retries with the signed payment guarantee.
5. Your middleware verifies and settles through the facilitator.
6. Your paid handler runs and returns the result.
7. You monitor the guarantee through clearing and final settlement.

## Go-live decision

Launch when you can operate the route without guessing. For every paid request, your team should know who paid, what they paid for, which result was delivered, whether settlement succeeded, and what recovery path exists if the payer does not settle.