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

# Machine Payments for AI Agents

> Decide when an AI agent should purchase API capabilities programmatically and which budget, confirmation, and audit controls are required.

A machine-payment flow allows software to pay for a supported capability at runtime. For an AI agent, this can reduce the need to maintain a separate subscription or provider account for every API it may use.

Payment automation should not be treated as unlimited spending authority. It is an execution capability with financial side effects and should be governed like any other privileged action.

## When programmatic payment is useful

Consider it when:

* An agent needs occasional access to a paid API that is not worth a dedicated subscription.
* Usage varies by task and per-call billing is easier to control than separate provider accounts.
* The application needs a common wallet or usage balance across supported capabilities.
* The task can define a clear maximum spend before execution.

A prepaid account or normal API key may be simpler when usage is predictable and the application does not need runtime purchasing decisions.

## Controls to define first

Before enabling an autonomous payment path, define:

| Control             | Question                                                           |
| ------------------- | ------------------------------------------------------------------ |
| Per-request limit   | What is the maximum amount for one call?                           |
| Per-task limit      | How much may the complete workflow spend?                          |
| Time-based limit    | What daily or monthly ceiling applies?                             |
| Confirmation policy | Which amounts or capability types require user approval?           |
| Retry policy        | Can a failed request be retried without a duplicate charge?        |
| Audit record        | Which request, amount, capability, and result fields are retained? |
| Failure behavior    | What happens when payment settles but the upstream result fails?   |

## Separate selection from authorization

An agent may determine that a paid API is useful without being authorized to buy it. Keep these decisions separate:

1. **Capability selection:** identify the API or service that could complete the task.
2. **Cost estimation:** determine the expected amount and uncertainty.
3. **Authorization:** compare the cost with policy and request confirmation if needed.
4. **Execution:** submit the paid request once.
5. **Verification:** confirm both settlement and the API result.
6. **Audit:** record the decision and outcome without exposing secrets.

## AIsa billing context

AIsa uses usage-based billing for model and API consumption. The [Wallet and Payments](/docs/guides/pricing/wallet) guide explains account funding, supported top-up methods, balance deductions, and usage logs.

The existence of a wallet does not imply that every AIsa capability is available through an autonomous payment protocol. Check the specific API documentation and authentication requirements before designing the flow.

## Safety rules for agents

* Never infer spending permission from possession of an API key or wallet connection.
* Do not expose wallet credentials, API keys, signatures, or authorization tokens.
* Avoid open-ended retry loops for billable calls.
* Prefer a read-only preview or quote before a paid side effect when available.
* Verify the final response instead of treating successful settlement as successful task completion.

## Related guidance

* [Capabilities by Interface](/docs/by-interface)
* [Pricing and Billing](/docs/guides/pricing)
* [AIsa Wallet and Payments](/docs/guides/pricing/wallet)
* [Authentication](/docs/guides/authentication)
* [Security](/docs/guides/security)