JiesdaPay Docs
JiesdaPay Docs
Homepage

Start here

OverviewCore conceptsHow paid calls work

Build and monetize

Monetize MCPs and APIsHosted skillsIntegration flow

User and finance control

Scoped budgetsAudit ledgerPayment rails

Enterprise

Enterprise governanceTrust boundariesMVP scope

MVP scope

The first version should prove the paid-agent control loop without becoming a full payment platform.

The first version of JiesdaPay should stay focused.

In scope

The MVP should prove one complete loop:

  1. A developer connects one MCP/API endpoint or hosted skill.
  2. The developer configures name, tool description, pricing, and rail binding.
  3. JiesdaPay publishes a paid endpoint.
  4. A user calls the service through an agent.
  5. The first paid call asks for a scoped task budget.
  6. The agent runs calls inside that budget.
  7. JiesdaPay records call, reason, price, result, approval, and payment event.
  8. The user sees a readable spend summary.
  9. The developer sees usage and revenue-related events.

Out of scope for the first version

Avoid building too much too early.

The first version should not include:

  • Platform-owned wallet.
  • Stored user balance.
  • Funds custody.
  • Recharge and withdrawal.
  • Invoice system.
  • Complex revenue sharing.
  • Large marketplace.
  • Arbitrary script execution.
  • Consumer mobile app.
  • Full enterprise procurement suite.

Why the scope matters

The core product risk is not whether a generic SaaS dashboard can be built. The core risk is whether paid agent calls can be made safe, explainable, and monetizable with less friction than building a custom payment and audit stack.

The MVP should test that exact risk.

Table of Contents

In scope
Out of scope for the first version
Why the scope matters