Core concepts

JiesdaPay works because it separates a paid agent workflow into a few explicit concepts.

Paid call

A paid call is any agent-initiated request that may create cost.

Examples:

• Calling a paid MCP tool.
• Querying a commercial data API.
• Running a hosted skill that uses protected references, templates, or workflows.
• Requesting a specialized analysis report from a paid service.

A paid call is not just a payment event. It includes the task context, the agent, the tool, the reason, the price, and the result summary.

Scope

A scope defines where the agent is allowed to spend.

Common scope dimensions:

• Current task.
• Current user.
• Organization.
• Team or department.
• Project or cost center.
• Named MCP/API/Skill.
• Time window.

The most important first scope is the task scope. A user should be able to say: "For this task, the agent may spend up to this amount and may only use these services."

Budget

A budget is the numeric spending boundary for a scope.

JiesdaPay supports the product logic for:

• Task-level maximum spend.
• Per-call maximum spend.
• Tool-level limits.
• User-level or team-level limits.
• Free trial or free-tier usage.
• Over-budget routing into approval.

The budget should be checked before every paid call, not only at checkout.

Policy

A policy decides whether a paid call is allowed.

Policy can answer questions such as:

• Is this service approved for the organization?
• Is this agent allowed to call paid tools?
• Is this tool allowed for this project?
• Is the request sensitive or high-risk?
• Is this call likely to leak protected skill assets?

Policy is intentionally broader than payment. A payment rail can move money, but it usually cannot explain whether an agent should have been allowed to request the paid work.

Approval

Approval is a decision point before execution.

Not every paid call needs approval. Frequent low-cost calls inside an existing task budget should be automatic. New services, high prices, sensitive actions, or budget overruns should be routed to the right approval path.

Approval can be:

• A user approving a task budget.
• A reviewer approving a high-risk call.
• A team lead approving a project limit.
• An automated policy approving a low-risk call.

Payment rail

A payment rail is the underlying mechanism that moves money or confirms payment.

JiesdaPay is rail-agnostic. A developer may bind a traditional payment provider, a wallet-based flow, an x402-compatible flow, or another payment mechanism. JiesdaPay records and explains the paid agent call around that rail.

Audit ledger

The audit ledger is the record that makes agent spend understandable.

It should show:

• Task.
• Agent.
• Tool or skill.
• Reason for the call.
• Price.
• Rail or payment event.
• Result summary.
• Approval state.
• Revocation and export status.

The ledger is the difference between "a payment happened" and "the user understands why the agent spent money."