Billing & Entitlement Infrastructure
for Products and AI Agents

Web3 products sell access the way they did in 2016: a message in a chat, a wallet address, a spreadsheet kept by hand. There is no invoice, no receipt, no audit trail. When a payment is disputed it gets settled in DMs. When an auditor asks where the money came from, the answer is a CSV on someone’s laptop.

The product went on-chain. The billing around it never did. Modern products do not sell one thing — they sell a plan, an add-on, a credit pack, a usage allowance, and a feature flag, each in a different system, out of sync with the payment state that funds it. And AI agents, which can think, browse, and ship, cannot pay: no card, no bank account, no way to prove to a seller that a spend is authorized.

The machines are arriving faster than the payments layer.

Every team that wants an agent to buy something builds a custom payment flow. Every builder who wants to sell to agents builds custom checkout. The internet solved discovery for humans with HTTP, SMTP, and DNS. It has not yet solved payment for machines.

ArcenPay defines how products sell access and how agents pay for it, through one shared billing layer. It is not a payment processor bolted onto a product — it is the infrastructure products use to sell access, gate features, and settle stablecoin payments.

ArcenPay defines five protocol layers, each building on the last:

Applications integrate through the React, Node.js, or Agent SDKs. The platform API stores catalog data, subscription state, invoices, webhooks, payment links, mandates, and escrow records. A settlement engine runs renewals, x402 verification, session vault accounting, and webhook dispatch. And smart contracts enforce the on-chain state on EVM, Stellar Soroban, and Solana.

The payment flow is dual-mode by design — the same checkout serves a human in a browser and an agent fetching a machine-readable spec. The human subscription lifecycle and the autonomous agent lifecycle run through the same platform pipeline:

Five contracts enforce the system on-chain. Addresses are centralized in the platform core and resolved automatically by all SDKs based on chain ID:

Protected API routes are enforced server-side with x402. An unpaid request returns 402 Payment Required, and ArcenAgent parses the challenge, signs the payment, and retries automatically:

import { x402Middleware } from "@arcenpay/node";

app.use("/api/premium", x402Middleware({
  planId: "growth-api",
  ratePerCall: "0.001",
  chainId: 677, // BOT Chain Mainnet (or 9000000 Stellar, 5042002 Arc)
}));

Entitlement and dashboard state stay unified while settlement runs on the network a provider chooses. Stablecoins are the settlement asset. Production settlement runs on BOT Chain, Stellar, and Solana mainnets today; Arc Testnet remains the default development sandbox.

A MirrorRegistry keeps the protocol portable across networks. Teams develop on Arc Testnet, then promote to a production network with explicit confirmation — without changing how their code reads entitlements.

The dashboard owns the catalog. The chain owns the subscription.

Entitlements are the enforcement half of billing. A subscription is minted on-chain as an NFT with a validity period; an autopay module renews it; and apps check entitlements before showing a feature, running a paid action, or consuming usage.

Formally, company c is entitled to feature f at time t when an active subscription covers the current validity window:

where t₀ is the activation timestamp minted by the SubscriptionRegistry and Δis the plan period. Autopay renewal succeeds only when the subscriber’s approved balance covers price plus protocol fee:

React hooks keep the UI in sync, while server-side checks protect anything that creates cost. Access follows entitlements rather than the last checkout screen:

import { ArcenClient } from "@arcenpay/node";

const client = new ArcenClient({ apiKey: process.env.ARCENPAY_API_KEY! });

const entitlement = await client.checkEntitlement("analytics_export", {
  id: "company_123",
});

if (!entitlement.enabled) {
  throw new Error("Upgrade required");
}

The defining property of a machine-native payment layer is that the payer does not have to be human. ArcenPay ships four primitives that let an agent hold, spend, bound, and recover value.

x402 micropayments. A drop-in fetch()replacement that negotiates HTTP 402 responses with zero gas per call. Each paid call debits the agent’s session balance by the per-call rate, and a call is authorized only while the balance covers it:

Verify-Then-Settle escrow. Buying a dataset, model weights, or compute output is asymmetric: pay upfront and the seller may not deliver; pay on delivery and the buyer may not settle. The provider commits to a canonical hash of the deliverable, and the buyer verifies it locally:

ArcenAuth & mandates. Autonomous Agent Mandates bound spending authority with monotonic scope narrowing, evaluate it with a deterministic policy engine, and revoke it on-chain through the SessionVault. The same machine surface is exposed natively to LLM runtimes through twelve Model Context Protocol tools for Claude Desktop, Cursor, and LLM swarms — with budget guardrails built in.

ArcenPay is infrastructure, and its economics accrue from usage, not emissions. A FeeCollector contract receives protocol fees on subscription and settlement flows and routes them deterministically on-chain to the treasury.

Total fees at time t are the sum over all plans and all agent spend, each at its fee rate:

The flywheel is product-first. More products on ArcenPay mean more subscriptions and agent payments; more payments mean more settlement volume and fee routing; more volume funds the infrastructure that makes the next integration easier.

Value flows through the layer in real money, and a share of it routes back into the network rather than out of it.

ArcenPay has no token, and this paper does not invent one. Protocol economics here means fee routing, treasury allocation, and multi-provider settlement. If a token ever exists, it will be downstream of working payment flows — not a substitute for them.

ArcenPay is non-custodial. It does not hold, control, or manage user funds; contracts own settlement, and the platform owns the state around it. Every billing action emits a signed webhook event — 17 event types — authenticated with HMAC-SHA256 and verified with a server-side helper.

Processing is idempotent, replay protection is enforced at the facilitator, and secrets rotate without downtime. General availability is gated on an external security audit with zero unresolved critical or high findings, plus a validated US and India invoice and tax baseline.

A billing platform is only as trustworthy as its worst edge case.

Development and production run separate catalogs and allowed-chain sets, so teams iterate on testnet and promote with explicit confirmation — never by accident.

ArcenPay is organized around core product areas. Each area is useful on its own and connects into the full billing flow.

Full details for each area are available in the documentation.

The machines are arriving. They need a payment layer they can use without a human in the loop — one that is programmable, verifiable, and global.

ArcenPay is that layer, and it is live: verified contracts on BOT Chain, Stellar, and Solana mainnets, signed webhooks, autonomous agent payments, and escrow that settles itself. Every claim in this paper — from the entitlement predicate in (5.1) to the fee accumulator in (7.2) — is formalized from the platform’s documentation and checkable against the chain.

Every product sells access. Every agent needs to pay for it. ArcenPay connects the two.

The equations in Sections 5–7 formalize documented platform behavior. The authoritative and current description of the platform is the documentation:

ArcenPay is a payment infrastructure platform. This document describes the protocol and its economics and is not financial advice.