INTERNET-NATIVE PAYMENTS · EVM SETTLEMENT

x402Flex

Production settlement and sessions for x402 payments on EVM.

Route Permit2, ERC-2612, EIP-3009, and push deposits through one router.
Settle through one registry and emit a canonical receipt for indexing and reconciliation.
Add sessions for subscriptions, gift cards, and delegated agent spend without changing your receipt model.

Get started Explore the SDK View deployments

Multi-rail fundingCanonical receiptsSession budgetsToken-agnostic

Audited By CertiK logo

Event Log

PaymentSettledV2 emitted
schemeId: permit2
referenceHash verified
Authorized via Permit2 witness
Intent accepted -> auth rail selected

Receipt

PaymentSettledV2 {  payer: "0x7a42...19be",  merchant: "0x3f04...a810",  token: "USDC",  amount: "25.00",  schemeId: "permit2",  resourceId: "giftcard:flight-credit-25",  referenceHash: "0x86e2...013f"}

1 Intent · 4 Rails · 1 Receipt

Ship a payment flow in minutes.

One intent format. One receipt event. Multiple ways to pay.

Create an intent

Shape one intent payload with merchant, token, amount, and settlement context.

intent.ts

const intent = createIntent({
  merchant, token, amount, deadline,
  resourceId, referenceHash
})

Intent normalized for every funding rail.

Sign a witness

Attach user authorization as a witness signature bound to the intent hash.

witness.ts

const witnessSig = signWitness(
  intentHash,
  schemeId
)

Authorization bound to the exact payment intent.

Settle via the router

Submit the intent once and route settlement through the canonical router.

router.ts

await router.payWithPermit2(
  intent, witness, sig
)

Settlement executed through one registry path.

Verify the receipt

Confirm receipt integrity for indexing, analytics, and downstream reconciliation.

receipt.ts

verifyReceipt(
  paymentId,
  referenceHash
)

Receipt emitted with schemeId + resourceId.

Why x402Flex

Designed for production settlement, not single-path demos.

One router. Multiple authorization standards.

Ship every rail without fragmenting your integration.

Permit2, ERC-2612, EIP-3009, and push deposits
One submit path for merchants + facilitators

See payment schemes ->

Canonical receipts across every flow.

Normalize settlement events for indexing and reconciliation.

PaymentSettledV2 with schemeId + resourceId
referenceHash for verifiable intent binding

Receipt schema ->

Sessions for subscriptions, gift cards, and agents.

Delegate spend with on-chain guardrails.

Token caps + daily caps + rate limits
Claimable sessions for delegated flows

Sessions ->

AGENTIC COMMERCE

Give agents spending power without giving them your wallet.

x402Flex sessions let agents spend inside a policy, then prove settlement on-chain before you fulfill.

Policy budgets: per-token caps + daily caps
Guardrails: merchant scope + scheme allowlist + rate limits
Verifiability: canonical receipt fields for indexing + reconciliation

Build an agent flow ->Session policies ->Receipt verification ->

Policy Wallet Console

Bound spend · Verifiable settlement

session-policy.ts

policy = {
  tokenCaps: [{ token: "USDC", cap: 250, dailyCap: 100 }],
  allowedSchemes: ["permit2", "eip2612", "eip3009", "push"],
  merchantScope: "0xMERCHANT...",     // optional
  rateLimit: { maxTxPerMinute: 6, coolDownSeconds: 15 }
}

Signed by payer -> sessionId: 0x9a07...be4d

Agent request

Buy gift card · $25.00 USDC

APPROVED

Policy checks

Daily capPASS
Token capPASS
Merchant scopePASS
Rate limitPASS

Spend: $25.00

Daily remaining: 50 / 100

receipt.json

Canonical

PaymentSettledV2 {
  paymentId: "0x4be0...91c2",
  payer: "0x7a42...19be",
  merchant: "0x3f04...a810",
  token: "USDC",
  amount: "25.00",
  schemeId: "permit2",
  resourceId: "giftcard:travel-credit-25",
  referenceHash: "0x86e2...013f"
}

Backend verifies referenceHash + resourceId before fulfillment.

Receipt emitted -> PaymentSettledV2

PRODUCTION POSTURE

Built for production x402 on EVM

x402Flex standardizes settlement correctness, receipt integrity, and session guardrails.

Most integrations start with one payment path, then fragment as rails expand.
Production systems need multiple authorization rails without changing settlement semantics.
x402Flex routes every standard through one surface and emits the same canonical receipt each time.

Receipt schema ->Payment schemes ->Sessions ->

Capability matrix

Capability

x402Flex

Common first implementation

Funding rails

✓

All rails, one routerPermit2, ERC-2612, EIP-3009, push deposits.

◻

Single rail firstNew rails add bespoke rules.

Receipt semantics

✓

One canonical receiptschemeId, resourceId, referenceHash.

◻

Receipts drift by flowOff-chain or missing fields.

Settlement surface

✓

Single registry pathAll schemes settle in one place.

◻

Multiple settlement pathsAd-hoc accounting.

Delegated spend

✓

Budgeted sessionsToken caps + daily caps.

◻

Off-chain API keysDrift from settlement controls.

Integrations

✓

SDK helpersSigning, submit, verify.

◻

Re-implement typed dataEdge cases repeated.

Operational safety

✓

Consistent replay protectionScheme-bound nonces.

◻

Inconsistent protectionsSubtle replay gaps.

SECURITY

Security assessment

Remediation in progressCertiK preliminary comments received · Jan 2026

PRE-preliminary-20260124T062721Z

The router and registry have been audited by CertiK. Review scope and findings before relying on the assessment.

View report View fixes

Audited By CertiK logo

Findings snapshot

Total findings: 11

Last updated: January 24, 2026

View remediation tracker ->

Centralization0

Medium0

Minor6

Informational4

Discussion1

Snapshot reflects preliminary comments status at publication time. Status: pending in preliminary snapshot.

Remediation tracker

SessionStore daily-cap debit optimization and cap tests
BNB-01 · completed 2026-01-27
Fixed
Unscoped zero-merchant session guardrail in SessionStore
BNB-02 · completed 2026-01-27
Fixed
Router EIP-3009 flow moved to receiveWithAuthorization
BNB-04 · completed 2026-01-28
Fixed
Publish role-rotation and emergency playbook for operators
Ops runbook workstream
Planned
Codify governance boundaries for rescue/admin permissions
Protocol policy decision
Design decision

CONTRACTS

Reference deployments

Pin addresses per environment. Treat receipts as the source of truth for settlement.

Payment Registry

Unverified

Canonical settlement + receipt emission.

0x1fAa1B7445ed1B3120451cC3F8f2230CB172602fExplorer ↗

Version: Tag pending

Commit: Hash pending

Role transparency

Registry admin: Not published
Router admin: Not published
SessionStore admin: Not published
Fee recipient: Not published

SDK uses these addresses by network name. Override in config for forks.

Router

Unverified

Multi-rail payment execution and forwarding.

Pending publicationExplorer

Version: Tag pending

Commit: Hash pending

Role transparency

Registry admin: Not published
Router admin: Not published
SessionStore admin: Not published
Fee recipient: Not published

SDK uses these addresses by network name. Override in config for forks.

Session Store

Unverified

Budgeted sessions and delegated spend guardrails.

Pending publicationExplorer

Version: Tag pending

Commit: Hash pending

Role transparency

Registry admin: Not published
Router admin: Not published
SessionStore admin: Not published
Fee recipient: Not published

SDK uses these addresses by network name. Override in config for forks.

Subscription Manager

Unverified

Recurring billing built on the same receipt model.

0x8cB3b8E739a9f7E0Ca3337c52436a3907D366F55Explorer ↗

Version: Tag pending

Commit: Hash pending

Role transparency

Registry admin: Not published
Router admin: Not published
SessionStore admin: Not published
Fee recipient: Not published

SDK uses these addresses by network name. Override in config for forks.

Maintained by Pepay Labs

Pepay Labs maintains the reference router, registry, sessions, and SDK.

Stable semantics across tokens, schemes, and payers.
Integrators ship once and scale without protocol drift.

Open semantics

Receipt schema and typed data are documented and versioned.

Operational discipline

Change logs, deployment map, and remediation tracking stay public.

Builder support

SDK helpers and examples reduce integration drift.

pepay.io GitHub Contact / Support