𝖆𝖇𝖊𝖑

With ArcenPay, an agent that hits a 402 can read the price, sign the payment within the limits you set, retry, and get through. A human subscriber gets their feature the same way, through the same entitlement check. My take: the next wave of internet traffic won't only be people clicking buttons. It will be machines buying access from other machines, and they'll need a payment layer that's programmable, verifiable and bounded.

Now the honest part, because a billing layer should be judged on its edge cases. ArcenPay general availability is gated on an external security audit with no unresolved critical or high findings. So ArcenPay is live on mainnets, but the team itself treats the audit as the bar for general availability. Arc is still a testnet, and parts of the roadmap, like cross chain mirroring and richer mandate policies, are still ahead. Verify anything token related through the team's official channels before you act on it. This isn't financial advice. teapawt.org/arcenpayhq/status/2115…

An agent that can pay raises an obvious question: what stops it from spending everything? ArcenPay's answer has two parts. ArcenAuth mandates set the agent's spending authority, and the scope can only narrow as authority is delegated. A policy engine checks each spend, and a mandate can be revoked onchain through the SessionVault. Think of a company card with a limit that can be cut off at any time. Verify Then Settle escrow handles things delivered later, like a dataset or compute output. The provider commits to a hash of the deliverable, the buyer checks it locally, and the funds either settle or auto refund. So the agent can spend, but only inside boundaries, and only for things it can verify.

Now the agent. ArcenPay uses x402, a protocol built on that old HTTP 402 code. Here's the flow: ⇛ The agent requests a paid API route.
⇛ The server answers 402 Payment Required, with the price attached.
⇛ The agent reads the challenge, signs the payment, and retries automatically.
⇛ The request goes through. Each paid call is debited from the agent's session balance, with zero gas per call, and a call is only authorized while the balance covers it. For the builder, protecting a route takes a few lines of middleware. For the agent, paying is automatic. No card, no checkout page, no human clicking confirm a thousand times.

Let's start with how humans subscribe You pay for a plan in stablecoins. The subscription is minted onchain as an NFT with a validity period, and an autopay module renews it when your approved balance covers the price plus the protocol fee. Here's the clever part. The app doesn't just trust the last checkout screen. Before it shows you a feature or runs a paid action, it checks your entitlement: is there an active subscription covering right now? Nobody has to chase a spreadsheet.

So what is ArcenPay? It's the billing and entitlement layer for Web3 products and AI agents. Products use it to sell access, check who's allowed in, and settle payment in stablecoins. The same layer works for humans and for machines. What makes it stand out: → One layer, two kinds of customers: Human subscriptions and agent payments run through the same pipeline. 
→ Non custodial: It doesn't hold or control user funds, and smart contracts own settlement. 
→ Multi chain: Production settlement runs on BOT Chain, Stellar and Solana mainnets, with Arc Testnet as the development sandbox. 
→ Built to integrate, with React, Node.js and Agent SDKs. The point isn't to bolt a payment button onto a product. It's to give products one standard way to charge, gate features, and keep access in sync with payment. teapawt.org/arcenpayhq/status/2113…

Before agents, there was a quieter problem: billing. The ArcenPay puts it in one line: the product went on chain, but the billing around it never did. Look at how many Web3 products still sell access. ⪼ A message in a chat. ⪼ A wallet address. ⪼ A spreadsheet kept by hand. There's 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. Now add AI agents to that mess. Every team that wants an agent to buy something builds a custom payment flow, and every builder who wants to sell to agents builds a custom checkout. Same problem, twice. ArcenPay's answer is one shared layer for both.

There's an error code the internet has had on hold since 1997. 402 ▹ Payment Required. The web's builders put it aside for online payments of the future, but never showed how it would work. So for decades, it did nothing. Now it has a job. A protocol called x402 turns it into a simple deal: here's the price, pay it, and you're in. And @arcenpayhq is the billing layer built around it. A Thread 🧵