​

Choose Your Integration

If you are deciding between the Conto SDK, the OpenClaw skill, the Hermes skill, x402, and MPP, start here. The right path usually comes down to three questions:

1. Where does your agent run?
2. Who holds the wallet keys?
3. Are you making one-off payments or repeated protocol-native API payments?

​

Quick Decision Matrix

​

Choose the Control Surface First

​

Conto SDK / REST API

Choose the SDK or REST API when you own the agent runtime and want the most direct integration.

• Best for custom backends, agent orchestration services, LangChain/OpenAI wrappers, and custom tools.
• Works well with both managed wallets and agent-held external wallets.
• Gives you the cleanest path to custom approval handling, policy creation, analytics, and audit automation.

​

Conto Card Access (maintenance reference)

Do not choose Conto Card Access for a new deployment. It is a maintenance-only private fallback for existing pilots whose customer-owned card path needs recovery or reconciliation. New connected-card work should use the shared Cards product surface instead. Existing Card Access pilots still run in a customer-hosted payment service, use the external-card policy overlay, claim an approved intent before the customer executor can run, and reject card credentials and secrets from purchase context. The path remains canBypass: true because the card can still be used outside the controlled path. Conto Card Access is separate from issuer integration and credential-gated checkout relay work. It does not store PAN or CVC and cannot decline at the card network. See Card Management for the forward Cards surface.

​

OpenClaw Skill

Choose OpenClaw when your agent already lives inside OpenClaw and typically uses an external wallet or wallet MCP tools.

• Install is fast through ClawHub (npx clawhub install conto), which installs the helper script with the skill.
• The most common pattern is approve -> transfer -> confirm.
• Requires curl, jq, and python3 on PATH for the helper; invoke it with bash skills/conto/conto-check.sh.
• Best when you want Conto to be the policy gate while your existing OpenClaw wallet stack keeps execution.
• Enforces the same agent environment, risk-tier, owner-role, identity-tag, and attestation rules as direct SDK integrations.
• Lets the assigned human owner list, approve, or deny pending payment reviews in the OpenClaw conversation. A new decision requires the matching one-time token from the owner’s independently delivered approval notification. Final approvals auto-send managed wallets; external wallets return a constrained send-and-confirm handoff.

​

Hermes Skill

Choose the Nous Hermes skill when your agent is already running on Hermes and you want Conto policy enforcement to feel native in that workflow.

• Installs through Hermes well-known skill discovery (hermes skills install well-known:... --force) after you review the install scan.
• Good fit for natural-language policy management and wallet-aware agent operations.
• Requires curl, jq, and python3 on PATH for the helper; invoke it with bash ~/.hermes/skills/conto/conto-check.sh.
• Supports the same underlying Conto approval and policy engine as the SDK flow, including agent environment, risk-tier, owner-role, identity-tag, and attestation rules.
• New approve or deny decisions require the matching one-time token from the assigned owner’s independently delivered approval notification; the Hermes agent key cannot decide by itself.

​

MCP Server

Choose MCP when a human operator, analyst, or assistant needs to inspect trust, policies, alerts, and agent state alongside the runtime integrations above.

• Good fit for finance, ops, and security teams.
• Complements SDK, OpenClaw, and Hermes rather than replacing them.

​

Then Choose the Payment Rail

For x402 and MPP record calls, send aggregate settlement fields at the top level and per-call details in batchItems. Use stable paymentId values for x402 and stable credentialId values for MPP so an ambiguous record attempt can be reconciled safely. Carry payment-challenge context into pre-authorization when you use context-dependent controls: x402 accepts facilitator, scheme, and paymentId; MPP accepts scheme, credentialId, challengeId, and paymentMethod. An MPP session intent must use the same non-empty sessionId during pre-authorization and recording. x402 records require a confirmed txHash; MPP records reject unsuccessful receipts, challenge mismatches, and receipt amounts that disagree with the recorded amount. Because an MPP receipt is caller supplied, a receipt-only record remains pending. Conto marks an MPP record confirmed only after its txHash matches the expected wallet sender, recipient, amount, and currency. For x402, send the actual signing wallet’s payerAddress and the selected CAIP-2 network together during both pre-authorization and recording. Keep the same pair across the flow so Conto evaluates policy and verifies settlement against the exact wallet and chain. This binding is required when an agent has multiple active wallets; partial bindings are rejected.

​

Wallet Model: Managed vs External

If your agent already has wallet tools in OpenClaw or Hermes, the external model is often the fastest adoption path. If you want fewer moving parts, managed wallets are usually the cleanest production setup.

​

Canonical Examples

​

1. Custom agent with managed execution

• Runtime: custom backend
• Wallet model: managed
• Rail: standard onchain payment
• Flow: POST /api/sdk/payments/request with autoExecute: true
• Best for: vendor payments, infra spend, low-latency production flows

​

2. OpenClaw agent with external wallet controls

• Runtime: OpenClaw
• Wallet model: external
• Rail: standard onchain payment
• Flow: POST /api/sdk/payments/approve -> transfer -> POST /api/sdk/payments/{id}/confirm
• Best for: teams that already have wallet MCP tools and want to add guardrails without re-architecting

​

3. Hermes agent paying APIs with x402

• Runtime: Hermes
• Wallet model: usually external
• Rail: x402
• Flow: 402 challenge -> /api/sdk/x402/pre-authorize -> pay -> retry -> /api/sdk/x402/record
• Best for: controlled pay-per-call API buying

​

4. SDK integration for high-frequency MPP sessions

• Runtime: custom backend
• Wallet model: integrated or external
• Rail: MPP
• Flow: pre-authorize deposit -> open session -> repeated charges -> close session -> record settlement
• Best for: repeated calls to the same service where per-call onchain settlement would be wasteful

​

5. Merchant checkout with a required user action

• Runtime: custom backend or skill-driven agent
• Wallet model: usually integrated
• Rail: standard onchain payment
• Flow: request -> ACTION_REQUIRED (if needed) -> user follows actionUrl -> check status -> execute
• Best for: agent purchases that may require the user to complete an additional checkout step

​

Decision Tree

​

Related Guides