Start building with Foinse.
Accept compute for your site, use a Foinse account in your app, or verify a receipt. These docs show the working path and label what is test, live, or planned.
Choose your starting point
- Get paid for a site or API: follow the Toll SDK quickstart, or hand it to your coding agent.
- Build with a Foinse account: choose your integration in Developers, then use the API reference.
- Test the payment flow: start in the sandbox without real settlement.
- Check a payment: use receipt verify.
Documents
- API reference: account, market, toll, and card routes
- Toll SDK: add payment to your own site or API
- Developer onboarding: choose the right integration and credentials
- Checkout and links: see how checkout works and what is available
- Sandbox: test without real provider capacity or settlement
- Pricing: processing tolls and external ramps
- Compute economics: the bearer-value and exchange model
- Security: key handling, evidence grades, and limits
A note on status
Live proof, test evidence, historic implementations, and planned services are labeled differently. A route being present does not prove every operation is live; check the response grade and status before relying on it.
Integration, settlement, and economic details
Start with the integration model
- Toll acceptance: a creator installs middleware around a paid route. A visitor presents a capped native provider key to the signed surrender endpoint. The creator never receives that key as the product.
- Door 1: the historic flow verifies before charging and returns a signed, single-use
qtt1ticket for the visitor to present to the protected route. - Door 2: the improved flow verifies by making the exact charge. The committed payment movement
event_idis the access grant; no separateqtt1ticket is required. - Account and ledger access: FK1 authenticates a Foinse account for permitted transfers and native inference spending through Foinse's spend path. It is not a native provider key and is not sent to every toll endpoint as a universal credential.
Conventions
API responses are JSON. Account-authenticated requests use FK1 in the Authorization header where the endpoint specifies account access. Native or capped quota keys belong to the payer surrender flow, not to a universal account-authentication scheme. A settled line conserves as payer debit = recipient credit + protocol fee. Evidence grades are defined in proof and security.
The two economic loops
Pay and be paid: visitors pay provider-denominated bearer value for access and creators are paid in that denomination. Sell and buy: holders supply bearer balances and buyers acquire from pooled available inventory, with reserve-lot provenance preserved beneath the pool.