Skip to main content
Conto checks whether an agent is authorized to proceed with a purchase. Stripe Link handles the buyer’s payment experience at checkout. To combine them, the agent’s payment tool must route the purchase through Conto before taking the payment action. Conto does not change the buyer’s Link wallet or govern purchases outside that connected flow. Connecting a card to Conto is not the same as connecting a Link wallet. The connected-card guide describes secure card entry, verified purchase authorizations, and requests for single-use checkout credentials. Those steps do not import cards saved in Link or authorize access to a Link account. In a Link checkout flow, Conto evaluates the proposed purchase before the connected executor proceeds to Link. Link authentication and any required buyer consent remain separate from Conto’s spending decision. A Conto approval does not log the buyer in to Link or replace that consent.

​
Where the policy check belongs

The intended sequence is:
  1. The agent prepares a purchase with its merchant, amount, currency, cart, and purpose.
  2. Conto evaluates the owner’s policies and returns an approval, denial, or request for review.
  3. The trusted executor stops denied requests and holds requests awaiting review. It rechecks approved purchase details immediately before the payment action.
  4. The approved flow proceeds to checkout, where the buyer can use Link when it is offered.
  5. The integration records the observed payment outcome against the original Conto decision.
Your application supplies the shopping agent, cart preparation, and checkout executor. For an existing third-party checkout, the control belongs in that executor before the payment-sensitive action. Merely recognizing a Link button or asking the model to check policy does not enforce a spending limit.

​
Make the check enforceable

A policy precheck is advisory if the agent can still pay through another tool. The trusted runtime must enforce these requirements:
  • Require authorization before a payment-capable action or credential use. Denied and pending requests must not proceed.
  • Bind authorization to the buyer, agent, merchant, amount, currency, material cart details, and relevant browser session or execution target.
  • Reject expired or revoked authority and recheck changed purchase details. An earlier approval cannot authorize a different cart.
  • Keep credentials and privileged browser controls outside model-visible tools. Inventory alternate click, keyboard, script, network, and payment tools that could bypass the guarded action.
  • Prevent approval replay and duplicate submission. Preserve the original request identity across review and recovery.
Conto’s browser runtime provides a guarded execution path, but an integrating platform must verify its complete tool configuration. A connected path is not proof that every action available to an agent is controlled. See buyer-side control for the wider architecture.

​
Confirm the outcome

Opening checkout, completing authentication, and returning to a success page are not settlement evidence. Record authoritative provider evidence and the actual payment method. A successful card fallback must not be labeled a Link payment. Keep decision and payment references together without logging credentials or checkout capability URLs. When submission is ambiguous, reconcile the existing attempt before retrying. See the payment lifecycle.

​
Availability and verified coverage

The controlled Stripe Checkout integration has been verified in Stripe test mode: an over-limit request was blocked before Checkout creation, a separate allowed purchase completed with Link, and Conto recorded payment-method evidence. The stablecoin comparison in that demonstration is simulated and does not prove a second live payment rail. That result does not establish general third-party checkout support, self-service Link wallet connection, or unattended production spending. The controlled Checkout adapter is gated and uses a configured merchant account. A buyer-runtime integration at a third-party merchant requires separate validation of its checkout, authentication, payment controls, and reconciliation. Before enabling a customer integration, verify an allowed purchase, a denial with zero payment action, a pending review, changed purchase details, approval replay, alternate payment paths, and an uncertain submission that does not automatically retry. Record the exact executor and checkout coverage tested. Contact Conto to confirm the available integration path before committing to a production rollout.