How to Add Payments to Your AI Agent

Prerequisites

Before you start, make sure you have these three things ready:

• A MoltPe account. Sign up free at moltpe.com/dashboard. No credit card required, no approval process. You get access immediately.
• An AI agent or LLM environment. This can be Claude Desktop, Cursor, Windsurf, a custom agent built with any framework, or any software that makes HTTP requests. If it can call an API, it can make payments.
• USDC for funding. You need USDC on Polygon PoS, Base, or Tempo to fund your agent's wallet. Even $1 is enough to test the full flow. MoltPe charges zero gas fees on all supported chains, so every dollar you deposit goes toward actual transactions.

That is it. No blockchain experience required. No smart contract deployment. No SDK installation for the MCP path. MoltPe handles wallet creation, key management, transaction signing, and on-chain settlement behind the scenes. You focus on what your agent does; MoltPe handles how it pays.

Step 1: Create an Agent Wallet

Every AI agent that makes payments needs its own isolated wallet. This is not a shared account or a sub-balance on your personal wallet. It is a separate on-chain address with its own private key, its own balance, and its own transaction history. Isolation matters because it limits blast radius: if an agent misbehaves, only that agent's funds are at risk.

Here is how to create one:

1. Go to moltpe.com/dashboard and sign in. If you do not have an account yet, the signup takes about 30 seconds.
2. Click "Create Wallet" in the dashboard. Give your wallet a descriptive name like "research-agent" or "api-buyer" so you can identify it later.
3. Select a network. Choose Polygon PoS, Base, or Tempo depending on which chain your payment recipients accept. If you are unsure, Polygon PoS is the most widely supported.
4. Copy your wallet details. You will receive two important values:
   • Wallet address — the on-chain address where you send USDC to fund the wallet.
   • Wallet ID — the MoltPe identifier you use in API calls and configuration.

The wallet is non-custodial. MoltPe uses Shamir secret sharing to split the private key so that no single party, including MoltPe, ever holds the complete key. This means you maintain control of your funds without managing raw private keys yourself.

You can create as many wallets as you need. One wallet per agent is the recommended pattern. This gives you clean separation of funds, independent spending policies, and per-agent audit trails.

Step 2: Fund Your Wallet and Set Policies

With your wallet created, you need to fund it and define the rules your agent must follow when spending.

Deposit USDC

Send USDC to your agent's wallet address on the chain you selected. You can do this from any exchange, another wallet, or the MoltPe dashboard. There is no minimum deposit. The balance appears in your dashboard within seconds once the transaction confirms on-chain.

Since MoltPe covers gas fees on Polygon PoS, Base, and Tempo, your agent does not need native chain tokens (MATIC, ETH, or TEMPO) for transaction fees. Every USDC you deposit is available for payments.

Configure Spending Policies

Spending policies are the guardrails that make autonomous payments safe. They are enforced at the infrastructure level, not in your agent's code, which means a bug or prompt injection cannot override them. Set these in the dashboard under your wallet's settings.

Here is an example policy configuration:

{
  "daily_limit_usdc": 50.00,
  "per_transaction_cap_usdc": 10.00,
  "cooldown_seconds": 5,
  "allowed_recipients": [
    "0x1234...abcd",
    "0x5678...efgh"
  ]
}

What each field does:

• daily_limit_usdc — Maximum total USDC the agent can spend in a rolling 24-hour window. Once the limit is reached, all further transactions are rejected until the window resets.
• per_transaction_cap_usdc — Maximum amount for any single transaction. Prevents the agent from draining the wallet in one payment.
• cooldown_seconds — Minimum time between consecutive transactions. Stops runaway loops where the agent retries a failed purchase hundreds of times in rapid succession.
• allowed_recipients — Optional allowlist of wallet addresses the agent can pay. Leave empty to allow payments to any address, or lock it down to only known service providers.

Start conservative. A daily limit of $50 and a per-transaction cap of $10 is reasonable for testing. You can increase these at any time through the dashboard as you build confidence in your agent's payment behavior. The agent itself cannot modify its own policies. Only the wallet owner can change them.

Step 3: Connect Your Agent

MoltPe supports three integration methods. Choose the one that matches your agent's architecture. All three provide the same core capabilities: check balance, send payment, and view transaction history.

Option A: MCP Server (Claude Desktop, Cursor, Windsurf)

If your agent runs inside an LLM environment that supports the Model Context Protocol, this is the fastest path. No code required. You add a JSON configuration block, and your agent gets payment tools it can call directly.

Add the following to your MCP configuration file (for example, claude_desktop_config.json for Claude Desktop, or the equivalent settings file for Cursor or Windsurf):

{
  "mcpServers": {
    "moltpe": {
      "command": "npx",
      "args": ["-y", "@moltpe/mcp-server"],
      "env": {
        "MOLTPE_API_KEY": "your-api-key-here",
        "MOLTPE_WALLET_ID": "your-wallet-id-here"
      }
    }
  }
}

Once configured, restart your LLM environment. The agent now has access to MoltPe tools including check_balance, send_payment, and list_transactions. When the agent needs to pay for something, it calls these tools the same way it calls any other MCP tool — through natural language reasoning.

For example, if you ask your agent "Buy the premium dataset from DataProvider for 2 USDC," the agent will:

1. Call check_balance to verify sufficient funds.
2. Call send_payment with the recipient address and amount.
3. Confirm the transaction completed and report back.

The spending policies you set in Step 2 are enforced on every call. If the agent tries to exceed a limit, the MCP server returns an error explaining why the transaction was blocked.

Option B: REST API

For custom agents or any software that can make HTTP requests, the REST API gives you full programmatic control. Here are the key operations.

Check wallet balance:

curl -X GET https://api.moltpe.com/v1/wallet/balance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "X-Wallet-ID: YOUR_WALLET_ID"

Response:

{
  "wallet_id": "wlt_abc123",
  "balance_usdc": "47.50",
  "network": "polygon",
  "daily_spent_usdc": "2.50",
  "daily_limit_usdc": "50.00"
}

Send a payment:

curl -X POST https://api.moltpe.com/v1/wallet/send \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "X-Wallet-ID: YOUR_WALLET_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "0x1234...abcd",
    "amount_usdc": "2.50",
    "memo": "Dataset purchase - order #4821"
  }'

Response:

{
  "transaction_id": "txn_xyz789",
  "status": "confirmed",
  "amount_usdc": "2.50",
  "to": "0x1234...abcd",
  "network": "polygon",
  "timestamp": "2026-04-16T14:32:01Z"
}

The API returns structured JSON that your agent can parse and act on. Every response includes a transaction ID for audit purposes. If a payment violates a spending policy, the API returns a clear error with the specific policy that was triggered, so your agent can handle the rejection gracefully.

Option C: x402 Protocol

The x402 protocol is the most seamless option for agents that call paid APIs. Instead of your agent explicitly deciding to make a payment, the payment happens automatically as part of the HTTP request cycle.

Here is how it works:

1. Agent calls a paid API. A standard GET or POST request to any x402-enabled endpoint.
2. Server responds with 402. The response includes a payment requirement: price, recipient address, and accepted chains.
3. Agent wallet pays automatically. MoltPe's infrastructure intercepts the 402 response, constructs the USDC payment, signs it, and attaches the payment proof to a retry request.
4. Server delivers the data. The server verifies the payment and returns the requested resource.

From the agent's perspective, this looks like a normal API call that happens to cost money. The payment is invisible to the agent's logic. Here is the flow in practice:

# Agent makes a normal API request
GET https://api.dataprovider.com/v1/dataset/premium
Authorization: Bearer agent-token

# Server responds with 402 Payment Required
HTTP/1.1 402 Payment Required
X-Payment-Amount: 1.50
X-Payment-Currency: USDC
X-Payment-Address: 0xabcd...1234
X-Payment-Network: polygon

# MoltPe wallet automatically pays and retries
GET https://api.dataprovider.com/v1/dataset/premium
Authorization: Bearer agent-token
X-Payment-Proof: eyJhbGciOiJFUzI1NiIs...

# Server returns the data
HTTP/1.1 200 OK
Content-Type: application/json
{ "dataset": "..." }

x402 is particularly powerful for agents that interact with many different paid services. The agent does not need to know the pricing of each service in advance. It just makes requests, and payments happen when required. Your spending policies still apply: if a service charges more than your per-transaction cap, the payment is blocked and the agent receives an error.

Testing Your Integration

Before deploying to production, verify that every part of the payment flow works correctly. Here is a testing checklist.

1. Verify Balance

Check that your agent can read its wallet balance. Whether you are using MCP, the REST API, or x402, the first thing to confirm is that the agent can see how much USDC is available. In the dashboard, compare the balance shown there with what your agent reports. They should match exactly.

2. Send a Test Payment

Send a small payment (even $0.01 if your policy allows it) to a known address. Verify three things:

• The payment shows as confirmed in both the API response and the MoltPe dashboard.
• Your wallet balance decreased by the correct amount.
• The transaction appears in your transaction history with the correct recipient, amount, and timestamp.

3. Test Policy Enforcement

This is the most important test. Deliberately try to break your own rules:

• Send a payment that exceeds your per-transaction cap. It should be rejected with a clear error.
• Send multiple payments in rapid succession to hit the daily limit. Payments beyond the limit should fail.
• If you set an allowed recipients list, try sending to an address not on the list. It should be blocked.

If all three tests pass, your agent is correctly integrated and your spending policies are enforced. You can explore the full payment flow interactively at demo.moltpe.com before committing to a live setup.

4. Review Transaction History

Open the MoltPe dashboard and verify that every test transaction appears with the correct details. The dashboard is your audit trail. In production, this is where you will monitor your agent's spending behavior and catch any anomalies.

Common Issues and Fixes

Here are the problems developers encounter most often when setting up agent payments, and how to resolve each one.

Insufficient Balance

Symptom: Payment request returns an "insufficient funds" error even though you deposited USDC.

Fix: Confirm you deposited USDC on the correct network. If your wallet is on Polygon PoS but you sent USDC on Ethereum mainnet, the funds will not appear. Also check that you sent USDC (the stablecoin), not USDT or another token. In the dashboard, verify the balance shows on the chain you configured.

Policy Rejection

Symptom: Transaction fails with a policy violation error.

Fix: The error message tells you which policy was triggered. Common causes: the payment exceeds your per-transaction cap, you have hit your daily limit, or the recipient address is not on your allowlist. Check your current daily spend in the dashboard. If you need higher limits, update the policy in wallet settings. Remember that policy changes take effect immediately.

Wrong Network

Symptom: Agent cannot find the wallet or balance shows as zero.

Fix: Make sure your API calls or MCP configuration specify the same network your wallet was created on. A wallet created on Base will not respond to queries for Polygon PoS. Check the network field in your wallet details on the dashboard and match it in your configuration.

MCP Server Not Connecting

Symptom: LLM environment does not show MoltPe payment tools after adding the configuration.

Fix: Restart the LLM environment completely after adding the MCP config. Verify the JSON syntax is valid (a trailing comma or missing quote breaks the config silently). Check that your API key and wallet ID are correct by testing them directly with a curl command against the REST API. If the tools still do not appear, check the MCP server logs for connection errors.