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

# Buyer-side control

> The agent owner sets spending authority. Conto checks it between the agent and transaction execution. Merchants do not install Conto.

Conto is a buyer-side control layer between an agent and transaction execution. The agent's
owner or budget holder decides how much it may spend, who it may pay, and when it must ask for
approval. The buyer's application integrates Conto in its runtime, payment tools, or signing
environment. Merchants receive payment through their existing supported payment methods without
installing Conto.

## Authority follows the budget

The owner may be a person delegating a purchase, a team funding a procurement agent, or a business
operating agents for its customers. An agent platform can integrate Conto on their behalf, but
must preserve each customer's spending authority and workspace isolation. Owning a storefront
does not give a merchant authority over a buyer's funds.

| Participant                  | Responsibility                                                                                                          |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Agent owner or budget holder | Configure budgets, permitted recipients, payment-source access, and approvers through authorized administrative access. |
| Buyer agent                  | Propose the transaction with amount, currency, recipient, and purpose using its own runtime credential.                 |
| Conto                        | Evaluate the paying agent's effective policies, return allow/deny/review, and record decisions and payment outcomes.    |
| Owner-authorized approver    | Resolve a review within the payer's permissions and applicable hard limits.                                             |
| Buyer executor               | Require authorization before signing or using payment credentials, and report the execution result.                     |
| Merchant or recipient        | Supply an offer and payment details, accept payment, and fulfill the purchase. No Conto installation is required.       |

## Transaction path

```mermaid theme={null}
flowchart LR
  Owner[Agent owner or budget holder] -->|Sets policy and approvers| Conto[Conto buyer authorization]
  Agent[Buyer agent] -->|Proposes transaction| Conto
  Conto -->|Denied| Stop[Stop before execution]
  Conto -->|Review required| Review[Owner-authorized approver]
  Review -->|Resolve and recheck| Conto
  Conto -->|Approved| Executor[Buyer payment executor]
  Executor -->|Supported payment method| Merchant[Merchant or recipient]
  Executor -->|Payment result| Record[Budget and audit record]
```

An offer, invoice, checkout page, or Conto Pay request supplies transaction details. It cannot
authorize payment, select the buyer's approvers, or relax the buyer's policy. Conto Pay handles and
request links are optional ways to identify a recipient and prepare a payment; ordinary supported
wallet payments do not require the recipient to have a Conto account.

## Put the check at the buyer's execution boundary

Integrating in the agent application does not mean giving the model unrestricted payment keys
and asking it to remember the rules. The executor must require authorization before it signs or
uses credentials. Denied or unresolved requests must not reach payment execution, and a changed
amount, recipient, currency, or material purchase detail needs a fresh check.

| Path                    | Where the buyer integrates                                                        | Enforcement boundary                                                                                                        |
| ----------------------- | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Managed wallet          | Agent calls Conto's request and execution APIs.                                   | Conto checks its signing path; root-owner authority and export rights still matter.                                         |
| External wallet         | Buyer tools call approve, then sign and transfer, then confirm.                   | The buyer must gate the external signer. Conto cannot stop transfers signed outside this path.                              |
| x402 or MPP             | Buyer client checks Conto before signing a payment or funding a session.          | Pre-authorization evaluates policy; the buyer client performs payment. It is not a reservation of funds by itself.          |
| Connected external card | Buyer runtime requests a card-policy grant and uses its own provider integration. | Conto governs that integration; it cannot revoke an unrestricted external credential or infer issuer-enforced restrictions. |

The connected external-card overlay is an integration path for an existing card provider, not
Conto-issued cards or universal browser checkout. Internal commerce adapters also do not establish
a connected production payment account. Check [payment prerequisites](/docs/reference/payment-support)
and the specific integration's available capabilities before enabling funds.

Authorization is not settlement. Preserve the payment identity across review, execution, and
recovery. Only confirmed outcomes should be reported as paid; reconcile ambiguous submissions
before retrying. See [the payment lifecycle](/docs/guides/payment-lifecycle).

## Verify the integration

Use a recipient with no Conto SDK, API key, grant verification, or policy webhook. From the buyer
runtime, verify an allowed payment, an over-budget refusal, a prohibited recipient, and a request
that waits for owner approval. Refused requests must not sign or submit credentials. Change the
transaction after approval and confirm that the executor refuses the old authorization.

Also verify that another workspace's policies or approvals cannot authorize this buyer's payment,
and that merchant-supplied instructions cannot modify policy. Record the tested payment methods
and merchant coverage. Requiring no merchant installation does not mean every payment method or
website is supported.

Continue with [integration choices](/docs/guides/choose-your-integration),
[architecture patterns](/docs/guides/architecture-patterns), or
[wallet ownership and custody](/docs/guides/custody-modes).