GET STARTED/INTRODUCTION

P2Flux documentation

P2Flux executes blockchain payments that settle straight to your own wallet. This documentation describes what is implemented today, on Base Sepolia — nothing here is a plan.

NETWORKBase Sepolia · testnet

ASSETUSDC

AUTHNone in v1

FEE1% one-time · 2% + 0.10 recurring

NON-CUSTODIAL

There is no P2Flux balance and no payout step. A payment moves from the buyer’s wallet to the recipient address, and the P2Flux fee is split out inside the same transaction. Nothing is held between the two.

The model

P2Flux signs the terms of a payment, the buyer’s wallet executes it, and the contract enforces what was signed. P2Flux stores nothing: a payment intent and a subscription capability are HMAC-signed tokens that carry their own contents, and every status answer is read from the chain at request time.

Recurring payments work the same way. The customer signs an EIP-712 authorization once — payer, recipient, token, amount, period, start, end, salt — and the contract enforces exactly those terms, one charge per period. There is no scheduler and no database here: your application owns the subscription lifecycle and calls /v1/charges when a renewal is due.

What you own, what we run

P2Flux v1 is a hosted service. You integrate against an API and a checkout that P2Flux operates — there is no P2Flux backend for you to install, and running your own is not part of the product.

That is a smaller surface than it sounds, because the parts that hold value are not ours. The contracts are public and immutable, the wallets belong to you and your customers, and your application keeps every record of who bought what. What we run is the machinery between them.

YOURS, OR PUBLICRUN BY P2FLUX

The contracts — public, immutable, verifiable on chainThe API

The JavaScript and PHP SDKs — public sourceThe hosted checkout

This documentation and the protocol it describesThe relayer that submits renewals

Your application and its database — orders, customers, subscriptionsChain access, price feeds and the security infrastructure around them

Your merchant wallet, which receives every paymentOperational monitoring and capacity

The buyer’s wallet, which sends it—

WHAT THAT MEANS FOR RISK

Everything P2Flux runs sits beside the payment rather than inside it. We are never a party to the transfer: if the API were unavailable no payment already authorized could be taken from you, and no outage puts merchant funds anywhere but the merchant’s wallet.

What exists today

This documentation describes the current implementation and nothing else.

CAPABILITYSTATUS

One-time paymentsImplemented

Recurring payments (merchant-triggered)Implemented

Hosted checkoutImplemented

JavaScript and PHP SDKsImplemented — not yet published to npm or Packagist

API authenticationNot currently available — see Authentication

WebhooksNot currently available

RefundsNot currently available

Base mainnetNot currently available — Base Sepolia (testnet) only

Assets other than USDCNot currently available

SCOPE

A capability marked “not currently available” has no implementation in the codebase. It is listed so an integration is not planned around something that does not exist.

ENVIRONMENT

Everything documented here runs on Base Sepolia, a test network. The value that moves is testnet USDC from a faucet, not real money. The API and checkout are hosted by P2Flux and their URLs are issued to integrators; there is no public host to point at yet.

Integration flow

A one-time payment, end to end. Every arrow is a real call in the current code.

one-time payment

your server   POST /v1/payments            → intent + pay parameters
your page     open checkout #/pay/<intent>
buyer wallet  signs one transaction         → USDC moves, fee splits
your server   POST /v1/payments/verify     → valid + block number
your system   marks the order paid

The buyer’s transaction pays the recipient and the fee wallet in one call. P2Flux never receives the merchant’s share, so there is no settlement step to wait for and no balance to withdraw.

What P2Flux does not do

It does not hold funds, so there is nothing to pay out and nothing to reverse.
It does not schedule renewals. Your billing system decides when a period is due and calls /v1/charges.
It does not store orders, customers or subscriptions. A payment reference is 32 random bytes generated by P2Flux, never a value you supply.
It cannot cancel a subscription on the customer’s behalf. Cancellation is a transaction from the customer’s own wallet; the API returns the calldata for it.

Where to next

QuickstartTake one payment, from request to confirmation.Recurring paymentsAuthorization, renewals, cancellation.API referenceEvery endpoint, field and status code.Networks & assetsChain, token, decimals, contracts.

Something more than a standard integration?

Marketplace flows, platform billing and custom settlement logic.

Discuss an integration