Developers.
Code for taking USDC: the SDK in Next.js, Express and Hono, webhooks and their signatures, idempotency, and testing without a sandbox.
Add a "Pay with USDC" button to your website
You need three pieces for a Pay with USDC button: a server route that creates a Fianto checkout session with your app secret, a button from @fianto/js or @fianto/react that opens that session in a popup, and a webhook route that marks the order paid when order.paid arrives. The browser never sees a key, and nothing the browser reports counts as proof of payment.
Use casesDevelopersPaid Discord roles with USDC: a bot, a checkout and two webhook events
To sell a Discord role for USDC, run a bot that holds the Manage Roles permission, let a /join command open a Fianto subscription checkout with the member's Discord user ID as the customer reference, and add or remove the role when Fianto's subscription.created and subscription.ended webhooks arrive. Fianto has no Discord integration of its own: it collects the USDC into your wallet and tells your server what happened, and your bot does the Discord part.
DevelopersAccept USDC in a Next.js app, and gate pages by subscription status
To accept USDC in a Next.js App Router app, install @fianto/nextjs, export Checkout() from a route that creates the session and Webhooks() from a route that receives signed events, then render FiantoButton from @fianto/react. Grant and revoke access from the webhook, never from the browser: store each subscription's status (ACTIVE, PAST_DUE or ENDED) and let your pages read it.
DevelopersTesting a USDC integration when there is no test mode
Fianto has no test mode, no test keys and no hosted devnet: its API settles real USDC on Solana mainnet. You still test almost everything without spending money, by unit-testing your webhook route with signed sample events, replaying any event type with fianto trigger, and asking for a real signed test.event. The checkout itself you test once with a real payment of 0.01 USDC, the lowest price allowed, sent from a second wallet of your own back to yourself.
DevelopersVerify Standard Webhooks signatures for payment events
Verifying a webhook signature means recomputing an HMAC-SHA256 over the exact bytes you received and comparing it, in constant time, with the one in the request. Under the Standard Webhooks format that Fianto uses, the signed content is webhook-id.webhook-timestamp.body, the key is the base64 part of your whsec_ secret, and the result arrives as v1,<base64> in the webhook-signature header. Check the timestamp too, then dedupe on the id.
DevelopersAdd USDC checkout with an AI coding agent: the Fianto agent skill
Run npx skills add fianto-xyz/skills in your project, then ask your coding agent to add Fianto checkout: the skill gives it the real API, the official @fianto/* packages and the rules that keep money safe. It cannot create your merchant account, your API keys or your webhook secret, and it is told to ask you before anything irreversible, such as cancelling a real subscription or moving USDC.
DevelopersUSDC subscriptions in Express: a checkout route, a webhook route and a gate
To sell a USDC subscription from Express, register two routes from @fianto/express before express.json(): checkout() creates a subscription session for a recurring price, and webhooks() verifies the subscription.* events you store. Your own middleware then lets a user in while their stored status is ACTIVE or PAST_DUE. A subscription never creates an order, so order.paid never fires for it.
DevelopersIdempotency keys and order ids: how a payments API avoids charging twice
An idempotency key is a unique value a client sends with a write so that a retry returns the first result instead of doing the work again; it protects one HTTP request. An order id protects the business event: Fianto refuses a second checkout for an order that is already paid with 409 order_already_paid. Fianto requires an Idempotency-Key on every v1 POST, keeps it for 24 hours, and marks a replay with Idempotent-Replayed: true.
DevelopersComparePay-per-request (x402) vs subscriptions for APIs: per-request payments and capped monthly plans compared
x402 is an open standard that answers an unpaid HTTP request with status 402 and lets the client pay in stablecoins per request; a subscription charges a fixed price once per period. Per-request payment fits sporadic callers and AI agents with no account; a capped monthly plan fits steady customers and predictable revenue. Fianto does not implement x402 or any usage-based billing: it runs monthly and yearly USDC plans on Solana.
DevelopersAccept USDC payments with Hono on Node, Cloudflare Workers or Bun
Hono takes USDC payments through @fianto/hono's two handlers: checkout() creates a one-off checkout session for your pay button, and webhooks() verifies the order.paid event you fulfil from. Both pass Hono's untouched c.req.raw to the SDK and use only fetch, Request, Response and Web Crypto. On Node the code reads process.env; on Cloudflare Workers you build the handlers inside the route from c.env, and Fianto's CI does not yet test Workers or Bun.
DevelopersSolanaUSDC decimals, lamports and Solana units: one page of conversions
USDC on Solana has 6 decimals, so 1 USDC is 1,000,000 base units and 25 USDC is stored and sent as the whole number 25000000. SOL has 9 decimals: 1 SOL is 1,000,000,000 lamports, and every network fee and rent figure on Solana is counted in lamports. Fianto takes prices as decimal strings such as "12.50", returns every amount in its API and webhooks as a string of USDC base units, and never does money arithmetic with floating-point numbers.