Batch Payment#
This page is for HTTP Sellers. Batch payment currently supports HTTP Sellers only.
For definitions and the underlying protocol, see Core Concepts · Batch payment. This page focuses on integration.
When it fits#
| Your business | Suitable |
|---|---|
| Per-call amount is very small (a few cents to fractions of a cent) | ✅ |
| Ultra-high call frequency (tens to hundreds per minute) | ✅ |
| Response speed prioritized over instant on-chain settlement | ✅ |
Prerequisites#
Batch payment requires the buyer to use Agentic Wallet. A regular EVM wallet cannot use this mode.
Reason: batch payment depends on two pieces of key infrastructure —
- Session Key: a temporary signing key generated by Agentic Wallet; the Agent signs directly with this key on every call, no need to wake up the buyer's main private key per call
- TEE: a hardware-isolated secure environment where OKX runs the batch settlement, ensuring signature data cannot be tampered with or stolen
Business flow#
Key timing difference (vs. one-time payment): the buyer receives the resource immediately and the seller also confirms receipt immediately (settle returning status=success is treated as paid); on-chain settlement happens asynchronously.
Seller integration flow#
✅ Node.js / Rust / Go / Java SDKs are all available
Each Tab is a complete single-language implementation (aggr_deferred scheme). The architecture has 4 components: Facilitator client (with OKX API Key) → Resource Server (registers the scheme) → Routes config (accepts array) → middleware mount.
import express from "express";
import {
paymentMiddleware,
x402ResourceServer,
} from "@okxweb3/x402-express";
import { AggrDeferredEvmScheme } from "@okxweb3/x402-evm/aggr-deferred/server";
import { OKXFacilitatorClient } from "@okxweb3/x402-core";
const app = express();
const NETWORK = "eip155:196";
const PAY_TO = process.env.PAY_TO_ADDRESS || "0xYourSellerWallet";
const facilitatorClient = new OKXFacilitatorClient({
apiKey: "OKX_API_KEY",
secretKey: "OKX_SECRET_KEY",
passphrase: "OKX_PASSPHRASE",
});
const resourceServer = new x402ResourceServer(facilitatorClient);
resourceServer.register(NETWORK, new AggrDeferredEvmScheme());
app.use(
paymentMiddleware(
{
"GET /api/realtime": {
accepts: [
{
scheme: "aggr_deferred",
network: NETWORK,
payTo: PAY_TO,
price: "$0.001",
},
],
description: "Realtime data",
mimeType: "application/json",
},
},
resourceServer,
),
);
app.get("/api/realtime", (_req, res) => {
res.json({ data: "realtime data" });
});
app.listen(4000);
Buyer integration#
The buyer must use Agentic Wallet.
- 1Install Agentic Wallet
Create Agentic Wallet via the Onchain OS Skill (email login, no seed phrase). The private key is generated and held inside the TEE. See Agentic Wallet install.
- 2High-frequency calls
The Agent signs automatically; each signature is millisecond-level, and the entire call flow doesn't require the buyer's main private key.
Limits and trade-offs#
- Large per-call amount, need on-chain confirmation before delivery: aggregated on-chain settlement has latency; the resource may be delivered before on-chain confirmation (you've treated it as paid, but on-chain it isn't done yet) → use One-time payment
syncSettle: true - Buyer unwilling to install Agentic Wallet: batch payment forces Agentic Wallet → fall back to One-time payment (any EIP-3009 wallet works)
- Per-call consumption can't be precomputed: use Pay-as-you-go
- Need splits: batch payment doesn't support splits yet; for small-amount split scenarios use One-time payment
charge
Advanced#
Coexistence strategy with exact#
Let one route serve both buyer types — declare both exact and aggr_deferred in the accepts array, and the buyer wallet picks based on capability.
| Buyer type | Scheme used | On-chain timing |
|---|---|---|
| Regular EIP-3009 wallet | exact | Instant |
| Agentic Wallet, high-frequency calls | aggr_deferred | Async aggregation |