18Docs
Payments
Accept USDC directly into your Solana wallet, or connect your own payment provider through a Function. Check payment in trusted backend code before you grant access or credit.
Choose how users pay
| Path | What you manage |
|---|---|
payments.acceptCrypto | Accept USDC on Solana. Bounded checks the transfer. Funds go directly to the seller. |
| Your own provider | Call a payment API from a Function. You manage the provider account, secrets, webhooks, and refunds. |
Choose a current payment integration
Use a direct payment provider for card checkout and recurring billing. Bounded account billing is separate from payments your app collects.
payments.acceptCrypto: direct USDC
Declare a seller-owned Solana address and the app can accept USDC directly into that wallet. Bounded creates an intent, verifies the finalized on-chain transfer, and records settlement; it never takes custody of the wallet, keys, or funds.
{
"payments": {
"acceptCrypto": {
"settleTo": "<seller-solana-address>",
"token": "usdc",
"environment": "production"
}
}
}settleTois a Solana address the seller controls.tokenisusdc; use the staging environment for devnet tests and production for mainnet.- The buyer pays the address from any compatible wallet. The app then submits the transaction signature for verification against the intended amount, token mint, environment, destination, finalization, and transaction success.
- Each transaction signature can settle only one intent globally. Re-verifying a settled intent returns the same record; uncertainty or insufficient payment does not settle.
- The direct-transfer rail has a 0 Bounded fee. Because funds move buyer-to-seller, Bounded has no post-settlement access to them.
Connect a payment provider
- Create the checkout in a trusted Function with your provider's API.
- Store a pending order with its expected buyer, amount, currency, and provider reference.
- Check payment through an authenticated provider response or a verified webhook.
- Record settlement once, using a unique provider payment ID.
- Grant access or credit through your app's policy rules.
Keep provider keys in Function secrets. The Functions guide includes a direct Stripe API example. That example uses your own Stripe account.
Recurring payments
Your provider owns the subscription lifecycle. Process renewal, failed payment, cancellation, refund, and dispute events in trusted code.
An initial successful checkout does not prove that a later renewal succeeded. Store each payment separately and update access only after you check the relevant event.
Paying for Bounded
Your Bounded account pays for platform usage and managed services. These charges do not collect revenue from your app's users.
Managed AI and service routes remain beta. Check the exact route's lifecycle and recovery behavior before relying on automated paid work.