Skip to main content
Free access works when every interaction is low-stakes. It breaks down when an agent delivers premium output, consumes paid infrastructure, or needs to enforce economic boundaries before work begins.

​
Why Payments Matter

In an open Agent-to-Agent network, payment cannot depend on manual invoicing, custom dashboards, or a centralized billing gate. If an agent charges for execution, the caller needs a way to pay programmatically and prove that payment before protected work is allowed to run.
Traditional Payment RailsBindu X402 Payments
Built for human checkout flowsBuilt for agent-to-agent and API-native flows
Verification often depends on a provider webhookVerification is tied to on-chain payment proof
Hard to compose inside autonomous workflowsDesigned to slot into agent execution paths
Usually centered on accounts and dashboardsCentered on requests, sessions, and payment payloads
Weak fit for crypto-native machine paymentsNative fit for verifiable on-chain settlement
That is the shift: Bindu gives agents a programmatic payment layer that can create sessions, verify on-chain payment, and issue short-lived access payloads for protected methods.
If an agent offers premium actions, the calling system should not have to rely on a human approval step or a private billing back office. It should be able to pay, prove payment, and continue automatically.

​
How Bindu Payments Work

Bindu supports the X402 payment protocol, allowing you to require payment before executing specific agent methods. After a successful payment, Bindu issues a base64-encoded payment payload used to access paid functionality via the X-PAYMENT header.

​
The Payment Model

Bindu uses a straightforward payment lifecycle: 
payment session -> wallet payment -> on-chain verification -> payment payload
The model is easy for developers to reason about and strict enough for production controls:
  • A payment session defines what must be paid
  • A wallet transaction settles the payment on-chain
  • A verification step confirms the transaction details
  • A payment payload (passed in X-PAYMENT) proves access for the protected method

Programmatic

Payments can be initiated and completed as part of automated agent workflows.

Verifiable

Bindu checks blockchain data before issuing access to protected methods.

X-PAYMENT Header

Proven access is provided via a base64-encoded payload in the X-PAYMENT header.

​
The Lifecycle: Session, Verification, Access

1

Session

Bindu creates a payment session whenever a caller attempts to access a protected method. The session captures the amount, token, network, and recipient wallet.
config = {
    "author": "your.email@example.com",
    "name": "paid_agent",
    "description": "An agent that requires payment",
    "deployment": {"url": "http://localhost:3773", "expose": True},
    "execution_cost": {
        "amount": "$0.0001",
        "token": "USDC",
        "network": "base-sepolia",
        "pay_to_address": "0xYourWalletAddressHere"
    }
}
By default, message/send is the protected method. To customize which methods require payment, set X402__PROTECTED_METHODS in your environment variables.
2

Verification

The user completes payment in their wallet. Bindu then validates the transaction on-chain. Poll the status endpoint to retrieve the required payment payload.
curl http://localhost:3773/api/payment-status/{session_id}
3

Access

Once payment is verified, the caller uses the payment_token in the X-PAYMENT header to access the protected method.
curl http://localhost:3773/ \
  -H "X-PAYMENT: <base64-encoded-payment-payload>" \
  -d '{ "method": "message/send", "params": { ... } }'

​
Payment Configuration

Bindu lets you define either a single payment path or multiple acceptable payment options.

​
Single Option

config = {
    "execution_cost": {
        "amount": "0.0001",
        "token": "USDC",
        "network": "base-sepolia",
        "pay_to_address": "0xYourWalletAddressHere",
    }
}

​
Multiple Options

You can provide a list of options. Any one of them satisfies the payment requirement. 
config = {
    "execution_cost": [
        {
            "amount": "0.1",
            "token": "USDC",
            "network": "base",
            "pay_to_address": "0xYourWalletAddressHere",
        },
        {
            "amount": "0.0001",
            "token": "ETH",
            "network": "ethereum",
            "pay_to_address": "0xYourWalletAddressHere",
        }
    ]
}
If testing for the first time, use base-sepolia and fund a test wallet. Ensure your pay_to_address is a wallet you control.

​
Real-World Use Cases

Enforce infrastructure costs at the request boundary for expensive LLM or research tasks.
async def call_paid_agent(payment_payload, payload):
    headers = {"X-PAYMENT": payment_payload}
    return await httpx.post("http://localhost:3773/", headers=headers, json=payload)
Small, per-task payments for lightweight operations such as summarization or data transformation. Bindu accepts strings with $ prefixes (e.g., "$0.01") and converts them to atomic units automatically.

​
Security Best Practices

Use X-PAYMENT

Ensure your client is sending the correct X-PAYMENT header. Plain token strings in other headers will be ignored.

Verify on Base

Double-check your network string. base-sepolia is recommended for all development and testing phases.
Sunflower LogoBindu allows agents to bloom independently — turning trust into verifiable value, and bringing light to the Internet of Agents.