Interactive collections prototype
Collect payments
Create payment requests, retrieve their status, match incoming bank receipts, identify duplicates, and route incorrect amounts or references for review.
Open financial operations · Agents + APIs
Open financial operations.
Built for agents.
OpenPaygents brings payment tools, financial agents, and transaction workflows into one portable stack. Collect, pay, reconcile, and resolve exceptions through software you can inspect, extend, and run on your terms.
Developer preview. The collections and reconciliation prototype runs today with synthetic payments in your browser. Model-backed execution, persistent banking records, and outgoing transfer workflows are being connected.
The first capabilities
Collect. Pay. Reconcile.
Financial work can start in a conversation, a business application, or an API request. The same underlying tools handle the transaction, preserve the record, and leave people in control of consequential decisions.
Synthetic banking under integration
Pay suppliers
Find the approved recipient, inspect available funds, prepare an exact transfer, request customer approval, and observe what actually happened before reporting completion.
Core matching available
Reconcile and resolve
Connect payments with the invoices, orders, and obligations behind them. Work through missing receipts, retries, discrepancies, and incomplete transactions without losing the history.
One financial task
From instruction to completed work.
The agent helps with interpretation, investigation, and next steps. Financial operations use defined tools and separate authorization. A task is not finished just because a model says it is.
Request
“Pay Supplier A $120. Ask me first.”
The agent identifies the account, supplier, balance, and missing information. If the recipient is ambiguous, it asks instead of guessing.
Prepare and authorize
An exact payment instruction.
- Recipient
- Supplier A
- Amount
- USD 120.00
- Approval
- Required
The payment service preserves the proposed terms. A separate customer confirmation is required before execution.
Execute and reconcile
Continue until there's a real outcome.
Once authorized, the system records the synthetic transfer, handles retries safely, and gives the agent the actual status to explain. If execution fails or remains uncertain, the task stays open.
See the implementation architectureIllustrative payable workflow, not a claim of live transfer execution. The available browser sandbox demonstrates incoming payment matching; the conversational banking flow remains in development.
Where the tools fit
Financial operations travel across industries.
Fintech is the first focused implementation. The same finance capabilities can serve commerce, capital research, travel, and insurance administration with domain-specific rules and records. These additional applications are directions for development, not completed integrations.
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.
For builders
The financial capabilities, without the closed stack.
Use the agent, call the tools yourself, or connect them to an existing product. The financial rules stay in software rather than depending on the model to follow instructions.
Agent and API access
Typed financial operations are callable from a model-assisted workflow or a conventional application, with separate permissions for each actor.
Accounts and payment records
Track requests, payees, balances, receipts, and postings with exact money values, stable identities, and clear transaction states.
Approvals and spending controls
Keep spending limits, recipient checks, and customer confirmation outside the language model and bound to the exact financial action.
Reconciliation and exceptions
Match external payment events to obligations, isolate duplicates, and preserve unresolved items for an operator to handle.
Replaceable components
Choose a model provider, database deployment, ledger engine, and payment adapters. The agent does not require one vendor's cloud.
Persistent tasks and retries
Retain context across multi-step financial work, resume pending approvals, and look up uncertain outcomes before trying again.
Developer-first
Build once. Use it wherever payments matter.
OpenPaygents combines a model-independent agent interface with reusable payment services. The reference implementation uses Cloudflare and Neon Postgres; other runtimes, ledgers, and rails can be integrated behind explicit contracts. The codebase is being prepared for public open-source release.
Part of a larger product ecosystem
Open tools for financial work.
Across real businesses.
OpenPaygents is being built within the Humanscaled venture network. Our other products span intelligence, commerce, research, healthcare administration, and more. Each needs reliable financial actions and records without rebuilding the payment layer from scratch.
- Open by design
- Self-hostable direction, portable data, documented interfaces, and permissive licensing for the core.
- Model-independent
- A replaceable model is one way to use the financial tools, not the source of financial authority.
- Built from real workflows
- Start with collections and synthetic banking, then add applications with distinct requirements and useful operators.
Try it nowCreate a request.
Create a request.
Match the payment.
Our live browser sandbox demonstrates exact incoming-payment matching, duplicate protection, and exception handling across synthetic payment contexts. The agent-backed services and durable banking sandbox are the next integration milestone.
Open the sandbox Explore the platform Development preview. No real bank connections, customer funds, or public source repository yet.