Stripe Stablecoin
Primary commercial rail for stablecoin checkout and USD-settled business operations.
Payment Rails · Agent-paid OS usage
Settlement rails for agents that pay to use Wever Labs OS.
Wever Labs connects settlement intent, provider payment requests, credit funding, metered Work Orders, usage receipts, result contracts, and callbacks into one agent-native operating loop.
Provider tracks
Provider rails feeding the same credit ledger
Provider confirmation flows into the settlement webhook, funds a credit entitlement, and returns a settlement receipt.
x402
Agent-native track for HTTP payment-required workflows and machine-to-machine API usage.
Circle / AP2
Wallet, USDC, mandate, and authorization rails for richer agent payment flows.
Operating flow
How payment becomes work
Settlement does not end at payment. It funds credits, activates entitlement, allows paid agent runs, and returns receipts and callbacks.
settlement_intent
→ payment_request
→ provider_confirmation
→ credits_funded
→ paid_agent_run
→ usage_receipt
→ callback_deliveredQuote to credit
The credit ledger has a quoting front end.
Before settlement funds credits, the OS can estimate the work, name minimum evidence, create a quote, and prepare a scoped credit entitlement. That keeps payment tied to operating work instead of floating as disconnected settlement state.
agent_quote_request
→ estimated_credits
→ payment_request
→ settlement_confirmation
→ credit_entitlement
→ paid_agent_runReceipts and callbacks
Payment should return an operating trail.
After settlement funds credits and the OS runs the task, TokenOps can return a usage receipt, result package, callback payload, and next available actions. The rail is not only pay to start. It is pay, run, receive, continue.
credits_funded
→ paid_agent_run
→ usage_receipt
→ result_package
→ callback_payload
→ next_agent_actionCredit treatment for recovery
Replay should not automatically mean double billing.
The exception rail records whether recovery can proceed with no additional debit, a meter-delta-only debit, an estimate before debit, or a new quote. That keeps agent-paid work cleaner when a run pauses.
{
"credit_debit_policy": "meter_delta_only",
"approved_recovery_action": "add_evidence",
"resume_from_state": "evidence_review"
}Settlement rail state
Payment rails fund credits and return operating state.
The settlement rail object makes the separation explicit: provider settlement confirms funds, the credit entitlement activates spendable credits, and usage receipts record what the OS consumed. That separation is the spine of agent-paid work.
Provider confirmation
Stripe stablecoin, x402, Circle / USDC, or manual invoice can be represented without hardwiring public artifacts to credentials.
Credit funding rule
Provider settlement confirmation funds credits according to the release policy, credit cap, and agent operator control state attached to the entitlement.
Kill switch
Settlement rails include a pause switch, rate limits, credit caps, webhook signature checks, and refund or void handling.
Credential envelope rail
Approved agents can receive scoped OS credentials.
The access key rail connects trust approval to usable OS access with scoped tools, credit account binding, callback delivery, rotation, and gateway-ready operating links.
Settlement provider abstraction
Multiple provider rails resolve into one OS credit and receipt contract.
Stripe stablecoin, x402, Circle / USDC, AP2 mandate, invoice, and custom provider rails can route through the same provider abstraction: route, confirmation, credit entitlement, settlement receipt, usage receipt, result contract, and callback trail.