Pricing and Monetization

You are not limited to one checkout model. You can charge for work in the unit that matches your product: request, API call, completed task, usage unit, tier, subscription entitlement, or negotiated quote. 4Mica handles the payment guarantee and settlement path. Your application decides what the paid unit means.

​

Common pricing models

Model the first version of your pricing in 4mica dashboard before exposing it to buyers.

​

Show the price before payment

Agents need clear prices because they make decisions without a human checkout screen. Before the buyer signs, expose the facts it needs to evaluate the payment:

• route being purchased
• price
• accepted scheme, network, and asset
• your payTo address
• guarantee version and validation requirements
• quote limits or expiration rules

That information lets a buyer agent compare the payment requirement with its own policy before it commits. It also gives both sides a clean record if the request later needs support, refund review, or dispute handling. If the price is dynamic, return a quote before the buyer signs. Do not make the buyer discover a higher price after work has already begun.

​

Dynamic pricing

Dynamic pricing works when the terms are visible before payment. Use it when cost changes with model load, demand, token count, data source, latency target, or downstream agent cost. If the final cost can exceed the estimate, cap the work, ask for another signed payment, or require a higher prepayment limit before continuing. If dynamic quotes depend on downstream costs or demand, ask support to review the flow before launch.

​

Human and agent pricing

You can charge humans and agents differently if your application can distinguish the buyer context and you publish the terms clearly. Common reasons include support cost, latency expectation, volume, automated access, or resale rights. At the payment layer, both are x402 buyers. The pricing difference belongs in your route policy, quote logic, marketplace policy, or identity checks.

​

Free trials and credits

Free trials are useful, but agents can abuse them quickly. Keep each trial scoped by the signals you actually control, such as wallet, agent identity, account, IP, or API key. Add short expiration windows and cap both request count and total value. Once the free credit is exhausted, require payment before more work continues. Watch for repeated new identities that behave like the same buyer, especially around expensive routes. Good trial limits usually include:

• a short expiration window
• a maximum number of requests
• a maximum total value
• a clear paid path after credits run out

For valuable or expensive work, prefer tiny paid trials over unlimited free access.

​

Minimum payment amounts

4Mica is designed for very small payments, but your economics still matter. Set a minimum that covers model cost, infrastructure, logging, support, fraud risk, and downstream paid calls. For extremely small units, batch work at the application level and let clearing cycles aggregate payable guarantees before settlement.

​

Pricing checklist

Before production, review the choices that affect both revenue and buyer trust. Before launch, compare these decisions with your configuration in the dashboard.