Agent Payment Policy

Validate paid output before agents accept it

epistemedeus

@epistemedeus

Install

$ openclaw skills install @epistemedeus/agent-payment-policy

Agent payment policy

Treat payment success and delivery validity as separate decisions. Use this workflow before an agent accepts a paid JSON response.

Keep the trust boundary explicit

  • Let the seller's OpenAPI or marketplace schema establish what it claims to return and whether the request is constructible.
  • Define a separate buyer-owned JSON Schema for the minimum acceptable result.
  • Compile and inspect that schema before network, credential, balance, signer, or wallet work.
  • Bind the canonical schema digest into the immutable intent and signed authorization. Never authorize from a mutable file path alone.
  • Validate the exact settled response body against the bound schema before treating delivery as successful.
  • Preserve payment settlement and output validation as independent receipt fields. A paid response can still be invalid.

This skill complements wallet, budget, x402, and MPP execution tools. It does not create a wallet, sign a payment, choose a facilitator, or authorize spend.

Speak the package as decide, bind, and classify

A foreign agent can use this package without Pilot private buyer code, a wallet, or a facilitator. Official clients can still pay a SameDayDesk 402 without it. Durable Ed25519 policy signing stays library-only.

VerbUse it toCLILibrary
decideInspect constructibility and plan viabilityconstruct-request, plan-check, inspect-url, output-schema-checkconstructRequest, createPlan, normalizeRequest, inspectOutputSchema
bindBind a finished request or verify a signed planconstruct-request, verify-authorization, verify-executionconstructRequest, verifyAuthorization, verifyExecutionAuthorization
classifyAccept a local body or classify caller-verified factsoutput-accept, receipt-completeness-checkinspectOutputSchema → prepareOutputValidator → validateOutput, evaluateReceiptCompleteness

Refuse unfinished URLs. Bare /extract is not_constructible. A finished example such as https://agents.samedaydesk.com/extract?url=https://example.com binds. requirePurchaseEvidence stays opt-in. receipt-completeness-check exits 0 by default; pass --fail-on conflict only when CI must halt on conflict.

Build the buyer contract

Write a bounded JSON Schema 2020-12 document that expresses only the fields the buyer's decision actually needs. Require types and formats, not only field presence. Prefer additionalProperties: false where the response contract is closed. Avoid remote $ref, executable extensions, and unbounded recursion.

Example:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "required": ["data"],
  "properties": {
    "data": {
      "type": "object",
      "additionalProperties": false,
      "required": ["source", "value", "observedAt"],
      "properties": {
        "source": { "type": "string", "format": "uri" },
        "value": { "type": "number", "minimum": 0 },
        "observedAt": { "type": "string", "format": "date-time" }
      }
    }
  }
}

Inspect the schema locally with an exact package version:

npm install --save-exact agent-payment-policy@0.15.0
npx agent-payment-policy output-schema-check \
  ./output-schema.json \
  data.source,data.value,data.observedAt

Record the returned schemaDigest, canonical byte count, and required paths. Stop before wallet access if inspection or compilation fails.

Carry the contract through authorization

Build the immutable purchase intent with:

  • exact method and normalized target;
  • maximum atomic amount, asset, network, and protocol constraints;
  • required media type and response byte ceiling;
  • required JSON paths;
  • the inspected schemaDigest;
  • freshness or content-hash constraints when the decision needs them.

Select one exact offer, freeze it in a route lock, and authorize the plan with a separate policy identity. Reinspect the local schema immediately before execution and require its digest to equal the authorized digest. A changed schema requires a new authorization.

Validate delivery

After the paid response is received:

  1. enforce the authorized media type and byte ceiling;
  2. parse JSON without coercion;
  3. validate the whole body against the prepared buyer schema;
  4. enforce freshness or content-hash constraints;
  5. create a receipt that reports payment settlement and output validation separately;
  6. release the body to downstream reasoning only when validation passes.

For library use:

import {
  inspectOutputSchema,
  prepareOutputValidator,
  validateOutput,
} from "agent-payment-policy";

const requiredFields = ["data.source", "data.value", "data.observedAt"];
const inspected = inspectOutputSchema({
  schema,
  requiredFields,
});

const contract = {
  mediaType: "application/json",
  maxResponseBytes: 65536,
  requiredFields,
  schemaDigest: inspected.schemaDigest,
};

const schemaValidator = prepareOutputValidator({
  schema,
  contract,
});

const parsedBody = JSON.parse(responseText);
const result = validateOutput(parsedBody, contract, { schemaValidator });

inspectOutputSchema returns requiredPaths, schemaDigest, and canonicalBytes. It does not return requiredFields. Repeat the same required-path list in the output contract. maxResponseBytes is the byte ceiling; maxBytes is ignored. validateOutput takes the parsed JSON value, not raw response bytes.

Use the package README for the complete intent, planning, authorization, and receipt APIs.

Reconcile incomplete receipt evidence

After the rail adapter has independently verified the provider receipt, transaction, and buyer balance, normalize only controlled match states into evaluateReceiptCompleteness. Do not pass raw headers, signatures, transaction bodies, credentials, wallet secrets, or paid output. Treat any mismatch as a conflict. Preserve missing facts honestly and use transaction or exact balance evidence only to supplement the dimension it actually proves.

The completeness report does not replace output validation. A payment can be reconciled while delivery is invalid, and valid delivery does not prove settlement.

Fail closed at the right stage

  • Missing or invalid buyer schema: stop before network and wallet work.
  • Seller schema cannot guarantee required paths: reject during procurement.
  • Authorized schema digest differs from local schema: require reauthorization.
  • Paid body fails schema validation: record settlement accurately, mark delivery invalid, and do not pass the body downstream.
  • Binary or streaming response: use a separate bounded contract or leave this JSON workflow rather than silently weakening it.

Do not claim that seller conformance proves truth, freshness, or business quality. The schema proves only that the delivered bytes satisfy the buyer's declared structural acceptance contract.

Top skills in this category

Stripe

@byungkyu

Stripe API integration with managed OAuth. This is a write-capable financial integration for customers, subscriptions, invoices, products, prices, and payments. Install only if you need Stripe administration. Connect with the least-privileged Stripe account and OAuth scopes available, verify the intended connection ID before each request, and revoke unused connections promptly. All write operations require explicit user approval showing the exact endpoint, target resource, object IDs, amounts, and test/live mode before execution. For other third party apps, use the api-gateway skill (https://clawhub.ai/byungkyu/api-gateway). Calls run through the `maton` CLI after `maton login`; the Stripe credential stays in the gateway and is never handled locally. Only your own Maton credential is used locally — held by the CLI, or supplied as `MATON_API_KEY` in the appendix fallback. Default to read and list calls, stay on the endpoints this skill documents, and confirm every write or new connection with the user. This file also documents the three constructs that turn a Stripe connection into automation, in the order they are used: the connection (the first step), a hosted function that runs a Stripe action through the Maton SDK, and a trigger that calls that function on a schedule or on an event. Those sections are the platform's own reference text, shared with the api-gateway skill, with Stripe examples; they add no Stripe capability - Stripe is itself an event source, so its own events are in `references/stripe/triggers.md`, and the files under `references/<source>/triggers.md` are the platform's event catalogues for the sources Maton offers (time, Calendly, GitHub, Gmail, HubSpot, Linear, Notion, Slack, Stripe).

2923k

百度网盘

@wscats

百度网盘(Baidu Drive, pan.baidu.com)文件管理 — 上传、下载、转存、分享、搜索、移动、复制、重命名、创建文件夹、删除(高风险,需用户确认)。 同时支持 Agent 记忆备份/恢复(kimiclaw/maxclaw/qclaw/openclaw)。 TRIGGER: 用户消息明确提及"百...

1923k

xero

@byungkyu

Xero API integration with managed OAuth. Manage contacts, invoices, payments, accounts, and run financial reports. Use this skill when users want to interact with Xero accounting data. For other third party apps, use the api-gateway skill (https://clawhub.ai/byungkyu/api-gateway). Calls run through the `maton` CLI with OAuth login, or over raw HTTP with a Maton API key where the CLI cannot be installed. Every call is authenticated as the user's connection and reaches only what that connection's authorization allows, which the provider enforces on every request; the endpoints documented here are the ones this skill uses, and any other endpoint of this app needs the user to ask for it by name. Default to read and list calls, and confirm every write or new connection with the user. This file also documents the three constructs that turn a Xero connection into automation, in the order they are used: the connection (the first step), a hosted function that runs a Xero action through the Maton SDK, and a trigger that calls that function on a schedule or on an event. Those sections are the platform's own reference text, shared with the api-gateway skill, with Xero examples; they add no Xero capability - Xero is not an event source, a trigger cannot read Xero data, and the files under `references/<source>/triggers.md` are the platform's event catalogues for the sources Maton offers (time, Calendly, GitHub, Gmail, HubSpot, Linear, Notion, Slack, Stripe).

1220k

polymarket-agent

@andretuta

Research Polymarket markets, whale flow and smart money; optionally trade a Polygon wallet behind deterministic risk guard-rails.

279.3k

Weiyun Skills

@wscats

微云网盘 MCP 接口完整技能。包含 weiyun.list、weiyun.list_by_category、weiyun.download、weiyun.delete、weiyun.upload、weiyun.gen_share_link、weiyun.rename_file、weiyun.rename_dir...

921k