How paid calls work

JiesdaPay controls paid agent calls before, during, and after execution.

1. The agent requests a paid capability

An agent runtime decides that it needs a paid MCP, API, or hosted skill to complete a task.

The request should include enough context for authorization:

• Current task.
• User or organization.
• Agent identity.
• Requested tool or skill.
• Declared reason.
• Estimated price or pricing rule.

The agent should not directly receive unrestricted payment authority.

2. JiesdaPay evaluates policy

The policy engine checks whether the call is allowed in principle.

Typical checks:

• Is this tool approved?
• Is this agent allowed to spend?
• Is this service allowed for the current organization or project?
• Is the request sensitive?
• Is this a new vendor or a previously approved one?

If policy fails, the call is blocked before payment.

3. JiesdaPay evaluates budget

The budget guard checks whether the call fits inside the current scope.

Examples:

• The task budget still has room.
• The per-call limit is not exceeded.
• The user or team monthly limit is not exceeded.
• The service-specific free tier or rate limit is still available.

If the call would exceed a boundary, it can be blocked or routed to approval.

4. JiesdaPay routes approval when needed

Some calls are safe to run automatically. Others should stop for confirmation.

Approval is useful for:

• First paid call in a task.
• First use of a new service.
• High-price call.
• Sensitive category.
• Budget overrun.
• Enterprise policy exception.

The goal is not to interrupt the user on every tool call. The goal is to make the important decisions explicit.

5. The payment rail or paid service executes

After policy, budget, and approval pass, the call can execute.

Depending on the integration, JiesdaPay may:

• Forward the request to an MCP/API provider.
• Run a hosted skill.
• Attach a payment token or rail-specific signal.
• Record the payment event returned by the provider.

JiesdaPay does not need to become the payment institution to provide value. Its value is the control and explanation layer around the paid work.

6. The audit ledger records the result

After execution, JiesdaPay records the event.

The record should connect:

• The task that caused the call.
• The agent that requested it.
• The tool or skill that ran.
• The reason for the call.
• The amount and rail.
• The result summary.
• The approval and policy decision.

This is what lets users, developers, and finance teams understand paid agent workflows after the fact.