Understand every request.

A small payment. A clearly defined boundary. A useful response.

aepay brings payment controls to AI agent workflows, with explicit budgets, per-request limits and a clear record of each decision. An agent requests a resource, receives a price, checks its policy, and continues only when the request is allowed.

Use this documentation to understand the payment lifecycle, configure the sandbox and inspect its results. Start with a request, then review spending policies, response data and integration requirements.

Walk through a payment lifecycle without an account or real funds.

1. Open the interactive demo. The initial scenario is Successful request, with a $5.00 simulated budget.
2. Choose an agent and an API. Start with Search API at $0.002 per request.
3. Select Run request. Follow the request, payment terms, policy check, authorization, and response stages.
4. Inspect the result and transaction log. A successful Search API call leaves $4.998. Run another request to see the totals accumulate.
5. Try Insufficient budget or Policy rejection to explore the failure paths. Reset session clears the history and restores the current scenario's starting balance.

Open the interactive demo

The building blocks of a controlled agent payment.

One USD equals 1,000,000 micro-USD. Search API costs 2,000 micro-USD, displayed as $0.002. The engine subtracts integers, so repeated calls do not accumulate floating-point rounding errors.

A request moves forward only when both policy and budget allow it.

Policy is checked first. If the API is not allowed or its price exceeds the per-call ceiling, the result is policy_denied. If policy passes but the remaining balance is below the price, the result is insufficient_budget. Either rejection records an attempt with a zero charge.

Small amounts still deserve explicit controls.

The normal starting budget is adjustable from $1 to $100. The per-call ceiling limits the price of each individual request; it does not replace the overall budget. A request equal to the ceiling or remaining budget is allowed.

const policy = {
  maxPerCallMicroUsd: 20_000, // $0.020 per call
  allowedApiIds: ["search", "market", "inference"],
};

const initialBudgetMicroUsd = 5_000_000; // $5.00

The $0.001 failure preset deliberately sits below the normal budget slider range, so you can reach the error immediately. The allowlist is part of the engine's typed policy contract; the demo uses all three APIs and exposes the per-call ceiling as its editable control.

Three local resources, priced to make the flow easy to inspect.

These prices describe the demo only. They are not a commercial offer, a network fee estimate, or published pricing. No provider request is sent and no AI inference is performed. Resource paths displayed in the UI are identifiers, not callable endpoints.

{
  "results": [
    {
      "title": "Agent payment patterns",
      "source": "Sample dataset"
    }
  ],
  "count": 1,
  "simulated": true
}

How the website, sandbox engine and local data fit together.

The current implementation uses Next.js App Router, TypeScript and Tailwind CSS. It exports static pages. The demo owns its state in React and delegates budget and policy decisions to a pure TypeScript engine. Documentation and search are bundled with the frontend.

Browser
  ├─ Home: product explanation + interactive preview
  ├─ Docs: local content + local search index
  └─ Demo: React state
       ├─ API catalog: fixed local data
       ├─ Policy check: pure TypeScript function
       ├─ Ledger: integer micro-USD
       └─ Response: local sample JSON

A live integration requires authenticated agent clients, server-side policy evaluation, a payment gateway, resource providers, a ledger and settlement services. Those services are not connected to the sandbox.

• UI components render controls, status and transaction results.
• src/lib/demo-engine.ts defines the catalog, policy validation and ledger updates.
• src/content/docs.ts is the shared source for document sections and search.
• src/config/brand.ts and tokens.css define the brand and visual system.

Typed, local records make every simulated charge inspectable.

type DemoTransaction = {
  id: string;
  apiId: "search" | "market" | "inference";
  amountMicroUsd: number;  // requested price
  chargedMicroUsd: number; // zero on rejection
  status: "delivered" | "insufficient_budget" | "policy_denied";
  simulated: true;
  createdAt: string;       // ISO timestamp
};

The ledger stores initialBudgetMicroUsd, remainingBudgetMicroUsd and transactions. Total spend is the initial budget minus the remaining budget. Completed calls count only delivered transactions. Rejected attempts remain visible in the log with a zero charge.

Identifiers are session-local sequence numbers such as sim_0001, not blockchain hashes. Timestamps use the browser clock. The interface displays the most recent attempts; the session ledger retains all attempts until reset or navigation away.

Run a local policy check and inspect the result.

The following standalone JavaScript example can run in a browser console or Node.js. It demonstrates a local decision only; it sends no requests and signs no payments.

const budget = 5_000_000;
const price = 2_000;
const perCallLimit = 20_000;

function simulate(remaining, amount, limit) {
  if (amount > limit) return { status: "policy_denied", remaining };
  if (amount > remaining) return { status: "insufficient_budget", remaining };
  return { status: "delivered", remaining: remaining - amount };
}

console.log(simulate(budget, price, perCallLimit));
// { status: "delivered", remaining: 4998000 }

For the actual frontend implementation, transact(ledger, apiId, policy, createdAt) returns a new ledger and preserves its input. createLedger(amount) validates that a budget is a non-negative safe integer. The unit tests cover exact-budget calls, rejection, repeated spending and invalid configuration.

HTTP payment flow and current compatibility status.

x402 is an open payment protocol built around HTTP 402 Payment Required. It describes how a service can communicate payment requirements and how a client can provide payment information before receiving a resource.

The sandbox demonstrates the request → payment terms → authorization → response flow. Its internal state names and JSON are not an implementation of the x402 wire format. No facilitator, verification service, signing flow or settlement network is connected.

Read the official x402 documentation

Explore the x402 specification

Operations and infrastructure needed for a live integration.

Request and response schemas, authentication, error codes, endpoint paths, webhooks and rate limits require a separate API specification. No public URL is assigned to these operations here. The browser engine's types are not a production API contract.

A rejected request should be clear, explainable and free of charges.

The sandbox does not retry requests automatically. Each Run request action is a new local attempt, with one sequence ID and at most one charge. A production system would require durable idempotency keys and server-side concurrency controls; disabling a browser button is not a production guarantee.

How the sandbox handles input and session data.

• Demo configuration and history live in memory in the current page. Reset, reload, or leaving the demo clears the session.
• No wallet addresses, private keys, payment credentials, email addresses or account details are requested.
• No analytics, cookies, localStorage persistence or waitlist submission are implemented by the application.
• The page and its assets are served over the network. The hosting platform may process request metadata under its own policies; the payment simulation itself sends no API requests.
• Documentation search is local. Your search text is not sent to an external search service.

All enforcement here is client-side and can be modified by a browser user. A production service would need server-side policy checks, authenticated actors, key isolation, replay protection, safe retries, audit records and independent security review. The sandbox carries no security certification.

Read our Privacy Policy

Read our Cookie Policy

Available features, supported environments and integration enquiries.

For integration enquiries, contact support@aepay.vn with your agent workflow, API resources and spending requirements. The available environment is the browser sandbox; production access and launch dates are not announced here.

Return to the demo