Less payment plumbing
Give an existing agent typed payment tools and domain adapters. Reuse request, receipt, and exception handling across applications.
Payment tools for agents
Let agents handle
the payment admin.
Collect an invoice, buy a dataset, or reconcile a claim. OpenPaygents brings the financial tools, permissions, and transaction records into one self-hostable foundation.
Developer preview. Reconciliation is interactive today; the connected agent platform is being built.
What it is for
Useful financial actions.
With a record you can check.
Authority stays with you
Set the accounts, payees, budgets, and approvals. The transaction service enforces the rules outside the model.
An answer you can verify
Check what changed in the transaction record. Keep payment, delivery, and reconciliation distinct, including when something fails.
Applications
Different jobs. A shared payment foundation.
Choose a use case to see the problem, the flow, and the parts behind it.
Commerce
Match the payment. Release the order once.
A merchant receives bank transfers against customer invoices. Repeated notifications, incorrect references, and wrong amounts make a paid status unreliable.
The useful result
A checked payment status that an order system can act on, with a reason for every exception.
The flow
- Create the invoice request
- Match the account, reference, currency, and amount
- Record one allocation; hold discrepancies for review
Assembled from
OpenPaygents matching core · receipt adapter · transaction records · fulfillment outbox
The matching core is in the sandbox. Backend persistence and order fulfillment are specified.
Fintech
Make a transfer within a defined mandate.
An operations agent needs to move money between approved accounts without receiving unrestricted payment credentials.
The useful result
Limits apply to the actual transaction. A timeout stays unresolved until its status is checked, preventing a blind second payment.
The flow
- Check the payee, amount, budget, and approval
- Submit the authorized transfer through a scoped adapter
- Read the receipt before reporting completion or retrying
Assembled from
Synthetic banking adapter · policy and approval service · Anvil/OpenZeppelin local token rail
Specified sandbox profile. Local test tokens have no monetary value; live banking is outside this build.
Capital research
Buy the dataset behind a decision.
A research agent finds a useful report or dataset. It needs permission to purchase it, a task budget, and proof that the expected resource arrived.
The useful result
The research can continue without an ad hoc payment integration. Paid, delivered, and reconciled remain separate facts.
The flow
- Get a quote from an approved seller
- Authorize the purchase against the research budget
- Verify the content and attach the expense to the task
Assembled from
Research purchase adapter · scoped tools · local transfer rail · optional x402 adapter
Specified purchase lifecycle using a synthetic seller and dataset. x402 is an optional protocol integration.
Travel & hospitality
Collect the deposit. Keep the booking straight.
A booking requires a deposit, but payment can arrive late, use the wrong reference, or be reported twice. Booking and payment status need to stay in agreement.
The useful result
A verified deposit can advance the booking once. An expired request or mismatched payment stays visible to the operator.
The flow
- Create a request linked to the booking
- Check the deposit receipt and expiry
- Send one fulfillment event or route the booking for review
Assembled from
Payment requests · receipt matching · separate booking state · idempotent fulfillment event
Booking deposits appear in the demo. The connected booking workflow is specified.
Healthcare & insurance
Explain what is still owed.
A claim can have insurer payments, patient payments, adjustments, and a remaining balance. Those entries need different treatment.
The useful result
A billing operator can trace the balance to its source records and see what needs attention. The agent does not make coverage or clinical decisions.
The flow
- Import the claim and its payment records
- Reconcile cash receipts and permitted adjustments separately
- Explain the remaining obligation and unresolved discrepancies
Assembled from
Seeded Synthea records · claims adapter · exact monetary arithmetic · exception and audit tools
Specified synthetic administration pack, with its own partial-payment and adjustment rules.
The product underneath
The pieces that make the applications possible.
Conversational tools
An agent can create a request, inspect a transaction, and explain an exception through a fixed tool interface.
Permissions and approvals
Bind permission to the exact action, destination, and amount. Wait for approval when the mandate requires it.
Transaction records
Store requests, receipts, allocations, and decisions in Postgres, with exact monetary values and stable identities.
Safe retries
Recognize the same command or receipt. Resolve uncertain outcomes before submitting another transaction.
Domain and rail adapters
Keep bank matching, synthetic transfers, token receipts, and claims rules behind explicit interfaces.
Independent evaluation
Let a separate evaluator drive the agent and inspect committed state with its own credentials.
Reuse before reinvention
Reuse the parts that already exist.
The build plan combines existing open-source components with OpenPaygents’ matching core. These are selected sources and adapters, not a claim that every integration is already running.
JV Ledger AgentTyped financial tools and exception-handling patterns↗AI SDKProvider-neutral model and tool calling↗OpenBox SDKSelective reuse of approval and cancellation behavior↗Agent Governance ToolkitPolicy components evaluated behind our permission interface↗SafeAgentEvalSession contracts, state inspection, and transaction scenarios↗
Domain components and interoperability
Anvil and OpenZeppelin supply the local token test environment. Synthea supplies synthetic claims data.
x402 is the optional paid-resource adapter. Google AP2 is a later interoperability candidate. LedgerForge or Blnk would be evaluated if a full ledger becomes necessary.
Built for human control
Keep your records.
Choose your infrastructure.
OpenPaygents is the payment layer for a broader system of human-controlled agents. It can serve a research product, an operating business, or another agent runtime without turning a model provider into the owner of the financial record.
- Self-hostable
- Cloudflare services and Neon Postgres are the reference deployment, with replaceable interfaces.
- Portable
- Exportable records, conventional data formats, and explicit model and payment adapters.
- Inspectable
- Trace the action to its permission, evidence, and outcome. Keep human intervention in the record.
What you can try todayCreate a request.
Create a request.
See what happens to the receipt.
The current sandbox exercises exact matching, duplicate detection, and exceptions using synthetic records. No real money moves.
Open the sandbox GitHub repository MIT-licensed. Repository access is currently by invitation.