Skip to main content
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.

​
Transaction path

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. 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 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.

​
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, architecture patterns, or wallet ownership and custody.