Skip to main content
4Mica can prove that a buyer signed a payment guarantee for a request and that your server settled it. Your application should also prove what work was delivered. For your agent service, this matters because the product may be probabilistic, generated, long-running, or assembled from other services.

​
What payment proves

A valid 4Mica payment flow can show who authorized payment, which seller address was paid, which guarantee and request were used, what amount, network, and asset were accepted, whether verification and settlement succeeded, and how the obligation resolved. That answers the payment question. It does not automatically answer whether the generated result was good, useful, or compliant with the buyer’s expectations.

​
What delivery evidence proves

Delivery evidence connects the paid request to the result. Store enough information to reconstruct what happened without guessing. For privacy-sensitive payloads, store hashes and metadata instead of full content.
Hashes are useful when you need proof without retaining sensitive content. Keep enough metadata to explain the request, but avoid storing data you do not need for support, audit, or compliance.
Attach delivery evidence to the payment activity visible in 4mica dashboard.

​
Proving completion

Define completion before launch. The right rule depends on what your product sells. If a task can fail after payment validation, define whether the buyer receives retry, refund, credit, partial result, or no refund.
Do not wait for the first dispute to decide what “complete” means. If completion is unclear, payment facts and delivery facts will not settle the disagreement by themselves.

​
Disputes for AI-generated work

AI output can be subjective. Reduce ambiguity by making the contract concrete before the buyer pays. Describe what the route does and does not promise, separate payment for effort from payment for a guaranteed outcome, return structured result statuses, and log tool calls and model versions. Your refund rules should cover technical failure, timeout, duplicate charge, and errors on your side. Avoid promising correctness where the agent only provides generated assistance. 4Mica supplies enforceable payment records. Your support policy decides how to handle quality complaints and refunds. When a dispute turns on output quality, share the payment record, delivery evidence, and your policy with support.

​
Refunds and tiny payments

For small payments, manual refunds can cost more than the payment itself. Prefer automated rules that a buyer agent can understand.
  • no charge if verification fails
  • retry or credit if your handler errors before delivery
  • automatic credit for duplicate paid requests
  • minimum refund threshold where appropriate
  • batch refunds or credits for tiny amounts
Publish the rule. Agents can reason about clear policies. Use payment history to decide whether refunds should be direct, credited, or batched.
For very small amounts, crediting the buyer can be more practical than sending a standalone refund. The important part is that the rule is visible before payment.

​
Reputation and ratings

Reputation can be built around your agent by linking identity, payment records, and delivery outcomes. A marketplace, registry, or application can track successful paid requests, failure rate, latency, refund rate, dispute rate, repeat buyers, and verified seller address or domain. 4Mica gives the payment evidence. Reputation systems can use that evidence as one input.