# insimbi insimbi curates the right transaction, rails and record for every value movement, whether fiat, stablecoins, markets or tokens. Every decision, every fee and every outcome, on the record. Built first for agents, predictive markets and real-money operators, then enterprises. Built for: Payments & finance leaders (/pricing/#finance); Engineering & platform leads (/developers/#platform); Operations leads (/product/#operations) ## The right rails. The right record. insimbi curates the right transaction, rails and record for every value movement. ## Every value movement Six kinds of value movement. Market figures from public sources, not insimbi's own numbers. Forecasts are marked. ### Fi Fiat · cards - **$11.903 trillion** spent with US-issued credit, debit and prepaid cards in 2024. Source: [The Nilson Report, March 2025](https://www.globenewswire.com/news-release/2025/03/19/3045828/0/en/merchant-processing-fees-in-the-united-states-exceeded-187-billion-in-2024.html) - **$187.20 billion** in processing fees paid by US merchants to accept card payments in 2024. Source: [The Nilson Report, March 2025](https://www.globenewswire.com/news-release/2025/03/19/3045828/0/en/merchant-processing-fees-in-the-united-states-exceeded-187-billion-in-2024.html) ### Sc Stablecoins - **$320 billion** stablecoin market capitalization, around this level as of end-May 2026. Source: [BIS Annual Economic Report, June 2026](https://www.bis.org/publ/arpdf/ar2026e3.htm) - **$28 trillion** estimated stablecoin transaction volume in 2025. Raw figure: the BIS notes volume net of transfers between a party's own wallets is far lower. Source: [BIS Annual Economic Report, June 2026](https://www.bis.org/publ/arpdf/ar2026e3.htm) ### Mk Markets - **15.3 billion** listed options and futures contracts cleared by OCC in 2025, a record. Source: [OCC 2025 Annual Report](https://annualreport.theocc.com/2025/a-message-from-leadership) ### Tk Tokens - **$39.11 billion** distributed value of tokenized real-world assets onchain, excluding stablecoins, as of Oct 13, 2026. Source: [RWA.xyz dashboard, as of Oct 13, 2026](https://app.rwa.xyz/) ### Mm Machine & agentic - **$3 trillion to $5 trillion** (forecast) of global consumer goods commerce that AI agents could mediate by 2030, under moderate assumptions. Source: [McKinsey, The agentic commerce opportunity, October 2025](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity-how-ai-agents-are-ushering-in-a-new-era-for-consumers-and-merchants) ### Vs Value-added services - **$10.9 billion** revenue from value-added services at one card network, Visa, in fiscal 2025. Source: [Visa Inc. Form 10-K, fiscal 2025](https://www.sec.gov/Archives/edgar/data/1403161/000140316125000089/v-20250930.htm) More on cards: - **$1.57** in fees for every $100 in card payments merchants accepted in 2024. Source: [The Nilson Report, March 2025](https://www.globenewswire.com/news-release/2025/03/19/3045828/0/en/merchant-processing-fees-in-the-united-states-exceeded-187-billion-in-2024.html) - **$34.12 billion** in interchange fees across all US debit and general-use prepaid card transactions in 2023. Source: [Federal Reserve Board, Regulation II data, 2023](https://www.federalreserve.gov/paymentsystems/2023-interchange-fee.htm) ## You can't see how your money moves. Most merchants can't see how their money moves. Fees are blended. Holds aren't chosen. Rail choices can't be inspected. We work closest to the metal: we never stack our product on another PSP. One integration, every rail we connect to directly, each decision cited to its rule. Choice without fragmentation. ## Four controls. You set each one. Turn a control off and watch the simulated payments change. - **Rail**: Choose the rail for each transaction. - **Pay out**: Choose when money lands. - **Price**: See every fee, line by line. - **Own**: Export your data, any time. | line | amount | |---|---| | authorization | gross amount | | network fee | at cost, itemized | | insimbi fee | our fee, itemized | | settled to you | net, on your schedule | ## Readable by people and by agents. Every page here also exists as markdown. Agents can read /llms.txt, follow /agents.md and use the API, with the same controls you have. ## Move one rule at a time. Connect, mirror, move. Run both setups side by side. Shift traffic by rule, and roll back in one step. ## What we can show you, and when. Procurement will ask. We list certifications, audit reports and uptime commitments only once they are real and audited. | item | status | |---|---| | PCI DSS | published once audited | | SOC 2 | published once audited | | Uptime SLA | published once contracted | | Trust documents | on request | ## Request access. Tell us how your payments run today. We will show you what you control with insimbi. ## Umuntu ngumuntu ngaBantu. It means a person is a person through other people. We think payments work the same way: a payment only completes when every party does its part. Our ring is drawn as iridium, the most corrosion-resistant metal known. We chose it on purpose. Payments should not corrode. Iridium is one of the rarest elements on Earth. South Africa mines about 80% of the world's supply, and the Bushveld Complex holds the largest reserves of the platinum-group metals it comes from. Source: [Royal Society of Chemistry, Periodic Table: Iridium](https://periodic-table.rsc.org/element/77/iridium) · Source: [International Platinum Group Metals Association, Iridium factsheet, March 2026](https://ipa-news.com/assets/pdfs/factsheets/2026-03-iridium-factsheet.pdf) Ask insimbi: open the command bar with ⌘K / Ctrl+K. --- # Product The right transaction, rails and record. Seven pillars, one ledger. Every value movement needs three choices: the transaction, the rails and the record. insimbi makes those choices by your rules, and shows you each one. Seven pillars cover every kind of value movement. One record sits under all of them. 1. **Transaction**: What is being paid for, by whom, under which mandate. 2. **Rails**: Which network, bank rail or chain carries it, chosen by your rule. 3. **Record**: One ledger line with its fees, its rule and its reconciliation. ### [Fe The record](/product/record/) One ledger under every movement. ### [Fi Fiat and cards](/product/fiat/) Accept and pay out across cards and bank rails. ### [Sc Stablecoins](/product/stablecoins/) Dollar stablecoins as one more rail, on the same record. ### [Mk Markets](/product/markets/) Funding and settlement for regulated venues. ### [Tk Tokens](/product/tokens/) Money in and out of tokenized assets. ### [Mm Machine and agentic](/product/agentic/) Let agents pay, inside limits you set. ### [Vs Value-added services](/product/value-added/) The extras, itemized and optional. ## Four controls across every pillar - [Rails](/product/rails/): The right transaction and rail for each payment. - [Payouts](/product/payouts/): Choose when money lands. - [Fee visibility](/product/pricing/): See every fee, line by line. - [Data](/product/data/): Export everything, any time. ## For operations leads Disputes, refunds, payouts and exceptions sit in one queue. Each item shows the rule that caused it. You don't need a support ticket to learn why money moved. - **Exception queue**: Disputes, refunds and failed payouts in one list. - **Rule attached**: Each exception shows the rule behind it. - **Payout reconciliation**: Each settlement is matched to its transactions. - **Audit log**: Who changed what, when, and what it touched. ## See it in a scenario Illustrative scenarios show how the pillars combine for a type of business. - [Use cases](/use-cases/): Eight illustrative scenarios, from marketplaces to agents. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Rails The right transaction and rail for each payment, on the record. Write the rules: by account range, card type, region, amount or time. For each payment, insimbi curates the transaction and picks the rail your rules allow, among the networks and rails we connect to directly: the one that costs least for that card or best fits your business. We show the arithmetic and the rule before the authorization goes out. Every choice is written to the record with the rule that made it, so you can review it, diff it and roll it back. New rails reach you without a new integration. This is not orchestration across processors. We never stack our product on another PSP. --- # Payouts You choose when money lands. Set when and where money lands, per account and per currency. The schedule is yours, and it is written down. --- # Fee visibility Every fee, line by line. Every transaction comes with its own fee lines: network, scheme and ours. Nothing is blended or rounded away. --- # Data Your data. Export it any time. Raw events, settlements and fees, streamed or exported. If you leave, your data leaves with you. --- # The record One ledger under every movement. Every payment, payout, fee and decision lands in one record. Finance, operations and auditors read the same lines. This is the base the other pillars build on. ## Capabilities - **Decision trace**: Every payment shows the rule that sent it where it went. - **Fee lines**: Network, scheme and insimbi fees, itemized per transaction. - **Reconciliation**: Each settlement row matched to the transactions behind it. - **Exception queue**: Disputes, refunds and failed payouts in one list, each with its rule. - **Search and export**: Find any record. Export it as a file, on request. - **Audit log**: Who changed what, when, and what it touched. - **Double-entry ledger**: Fiat, stablecoin and token balances in one set of books. - **Data streaming**: Raw events, settlements and fees into your warehouse. ## Protocols and standards Supports: ISO 20022, Double-entry accounting, CSV, Parquet and webhooks ## In a scenario - [A marketplace paying sellers in dollars and stablecoins](/use-cases/marketplace-payouts/): Illustrative scenario. - [An agent paying for API calls, one request at a time](/use-cases/agent-api-payments/): Illustrative scenario. - [A procurement agent buying from suppliers](/use-cases/procurement-agent/): Illustrative scenario. - [A retailer taking control of card costs](/use-cases/retailer-card-costs/): Illustrative scenario. - [An insurer paying claims on the fastest sensible rail](/use-cases/insurer-claims/): Illustrative scenario. - [A software platform billing people and agents](/use-cases/software-platform-billing/): Illustrative scenario. Related: [Fee visibility](/product/pricing/) · [Data](/product/data/) --- # Fiat and cards Accept and pay out across cards and bank rails. Cards and bank transfers carry most US commerce today. You choose the rail for each transaction and see the cost of each choice. ## Capabilities - **Your rules**: Rules by card type, region, amount or time. Reviewable and reversible. - **Debit network choice**: Send eligible debit to the network your rules pick. - **Direct network connections**: The card networks and bank rails we connect to directly. New rails arrive without a new integration. - **Network tokens**: Store tokens, not card numbers. - **Bank payouts**: ACH, same-day ACH and instant bank rails, per account. - **Payout cutoffs**: See the next settlement window before it closes. - **Parallel run**: Compared against your current setup, payment by payment. ## Protocols and standards Supports: Visa and Mastercard, EMV 3-D Secure, Network tokens, ACH and Same Day ACH, RTP, FedNow, Fedwire (ISO 20022) ## In a scenario - [A marketplace paying sellers in dollars and stablecoins](/use-cases/marketplace-payouts/): Illustrative scenario. - [A procurement agent buying from suppliers](/use-cases/procurement-agent/): Illustrative scenario. - [A retailer taking control of card costs](/use-cases/retailer-card-costs/): Illustrative scenario. - [An insurer paying claims on the fastest sensible rail](/use-cases/insurer-claims/): Illustrative scenario. - [A software platform billing people and agents](/use-cases/software-platform-billing/): Illustrative scenario. Related: [Rails](/product/rails/) · [Payouts](/product/payouts/) · [Switch](/switch/) --- # Stablecoins Dollar stablecoins as one more rail, on the same record. Stablecoins settle around the clock. insimbi treats them as a rail you can choose per movement, delivered through regulated partners, with the same fee lines and record as a card or a bank transfer. ## Capabilities - **Stablecoin acceptance**: Take regulated dollar stablecoins at checkout or on invoice, through regulated partners. - **Stablecoin payouts**: Pay sellers, suppliers or partners in stablecoins, by rule. - **Convert to dollars**: Settle to your bank in USD through regulated partners. - **Chain choice**: Pick the network per payout by cost and speed. - **Wallet screening**: Screen counterparties before money moves. - **Unified balances**: Fiat and stablecoin balances in one view. - **Around-the-clock settlement**: Settle on weekends and holidays, not just banking hours. - **Mint and redeem**: Move between dollars and stablecoins at par through regulated partners. - **Stablecoin treasury**: Hold, sweep and rebalance stablecoin balances by rule. ## Protocols and standards Supports: USDC, USDT, PYUSD, Ethereum, Solana, Base, Tron, ERC-20 ## In a scenario - [A marketplace paying sellers in dollars and stablecoins](/use-cases/marketplace-payouts/): Illustrative scenario. - [An agent paying for API calls, one request at a time](/use-cases/agent-api-payments/): Illustrative scenario. - [An event-contract venue settling winners](/use-cases/prediction-market-settlement/): Illustrative scenario. - [A tokenized fund taking subscriptions and paying redemptions](/use-cases/tokenized-fund/): Illustrative scenario. - [An insurer paying claims on the fastest sensible rail](/use-cases/insurer-claims/): Illustrative scenario. Related: [Payouts](/product/payouts/) --- # Markets Funding and settlement for regulated venues. Exchanges, brokers and event-contract venues move customer money in and out all day. insimbi funds accounts fast and settles them correctly, with a record that holds up to review. ## Capabilities - **Account funding**: Fund customer accounts by card, bank or stablecoin. - **Settlement payouts**: Pay out after a contract resolves, on the rail the customer picked. - **Segregated balances**: Customer funds and house funds kept apart in the record. - **Cutoff preview**: See which payouts make the next window. - **Withdrawal rules**: Limits, holds and reviews you set and can explain. - **Instant withdrawals**: Pay out to debit cards, instant bank rails or stablecoin wallets around the clock. - **Venue connectivity**: Connect to regulated exchange and event-contract venue APIs for funding and settlement instructions. - **Trade-to-cash matching**: Match every fill, resolution and fee to the cash that moved. - **Customer funds statements**: Daily segregated-funds reports your compliance team can file. ## Protocols and standards Supports: FIX, CFTC-regulated venue APIs, ACH, RTP and FedNow, USDC ## In a scenario - [An event-contract venue settling winners](/use-cases/prediction-market-settlement/): Illustrative scenario. Related: [Payouts](/product/payouts/) --- # Tokens Money in and out of tokenized assets. Tokenized funds and assets still need cash to come in and go out. insimbi takes subscriptions and pays redemptions and distributions in dollars or stablecoins, and matches them to the asset's records. ## Capabilities - **Subscriptions**: Take subscriptions by wire, ACH or stablecoin. - **Redemptions**: Pay redemptions on the rail the holder picked. - **Distributions**: Pay yield or dividends to many holders in one run. - **Register matching**: Match each cash movement to the asset register. - **Holder screening**: Check eligibility before money moves. - **Permissioned token support**: Work with tokens that enforce transfer rules onchain. - **Cross-chain movements**: Move tokenized assets and their cash legs across chains with one record. - **Around-the-clock settlement**: Subscribe and redeem at any hour in stablecoins. - **Investor statements**: Holdings, cash movements and distributions per investor. ## Protocols and standards Supports: ERC-20, ERC-3643, Chainlink CCIP, Ethereum, Solana, USDC, PYUSD ## In a scenario - [A tokenized fund taking subscriptions and paying redemptions](/use-cases/tokenized-fund/): Illustrative scenario. Related: [Data](/product/data/) --- # Machine and agentic Let agents pay, inside limits you set. Software agents now buy things and pay for services. With insimbi, an agent acts for one principal, within one mandate, and every payment it makes lands in the same record. ## Capabilities - **Agent-readable docs**: Every page as markdown, plus llms.txt and agents.md. - **Scoped API access**: Credentials limited to one principal and one scope. - **Agent mandates**: Bind an agent to a principal, a spend limit and a scope. - **Payment intent preview**: Check a request against the mandate before it runs. - **Tool interface for agents**: MCP tools so agents work with insimbi directly. - **Per-request payments**: Charge or pay per API call over HTTP 402, in fiat or stablecoins. - **Agent card credentials**: Single-use or limited card credentials for agent purchases. - **Agent protocols**: Accept agent checkouts over AP2 and ACP, verify agents with network agent programs. ## Protocols and standards Supports: MCP, Agent Payments Protocol (AP2), Agentic Commerce Protocol (ACP), x402, Visa Intelligent Commerce, Visa Trusted Agent Protocol, Mastercard Agent Pay, Machine Payments Protocol (MPP), Universal Commerce Protocol (UCP) ## In a scenario - [An agent paying for API calls, one request at a time](/use-cases/agent-api-payments/): Illustrative scenario. - [A procurement agent buying from suppliers](/use-cases/procurement-agent/): Illustrative scenario. - [A software platform billing people and agents](/use-cases/software-platform-billing/): Illustrative scenario. Related: [Developers](/developers/) --- # Value-added services The extras, itemized and optional. Fraud tools, account updates and cost modelling add value when you can see what each one costs and turn it off. Each service is a line item. ## Capabilities - **Cost modelling**: Preview a rule or payout change before you make it. - **Fraud signals**: Bring your own fraud tools or use partners, scored per payment. - **Card account updates**: Keep stored cards current. - **Dispute handling**: Evidence and deadlines in the exception queue. - **Onboarding review**: Review a business, its owners and its agents in one place. - **Authentication**: Run 3-D Secure only when your rules or the issuer need it. - **Payee tax forms**: Collect payee tax details and produce year-end forms for payouts. - **Cross-border FX**: Show the rate and the spread as their own lines. ## Protocols and standards Supports: EMV 3-D Secure, Network tokens, Card account updater services ## In a scenario - [A retailer taking control of card costs](/use-cases/retailer-card-costs/): Illustrative scenario. - [A software platform billing people and agents](/use-cases/software-platform-billing/): Illustrative scenario. Related: [Pricing](/pricing/) --- # Use cases Illustrative scenarios. How the pillars fit together. **Illustrative scenario.** A fictional type of business, not a customer. No results are claimed. Each scenario describes a fictional type of business, not a customer. It shows the problem and how insimbi handles the transaction, rails and record. - [A marketplace paying sellers in dollars and stablecoins](/use-cases/marketplace-payouts/): Fi + Sc - [An agent paying for API calls, one request at a time](/use-cases/agent-api-payments/): Mm + Sc - [A procurement agent buying from suppliers](/use-cases/procurement-agent/): Mm + Fi - [An event-contract venue settling winners](/use-cases/prediction-market-settlement/): Mk + Sc - [A tokenized fund taking subscriptions and paying redemptions](/use-cases/tokenized-fund/): Tk + Sc - [A retailer taking control of card costs](/use-cases/retailer-card-costs/): Fi + Vs - [An insurer paying claims on the fastest sensible rail](/use-cases/insurer-claims/): Fi + Sc - [A software platform billing people and agents](/use-cases/software-platform-billing/): Mm + Fi + Vs Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # A marketplace paying sellers in dollars and stablecoins A US marketplace with 40,000 sellers, some in the US and some abroad. **Illustrative scenario.** A fictional type of business, not a customer. No results are claimed. Cohorts: Fi + Sc Video (36 s, illustrative): [MP4](/assets/use-cases/marketplace-payouts.mp4) · captions: [WebVTT](/assets/use-cases/marketplace-payouts.vtt) · step list for software: [flow.json](/assets/use-cases/marketplace-payouts.flow.json) ## The problem Sellers want to be paid on their own terms. US sellers want next-day bank deposits. Sellers abroad wait days for wires and lose money on conversion. Finance can't see what each payout really costs. ## Value anatomy 1. **Transaction**: Buyers pay by card. Each order splits into the seller's share and the marketplace fee. 2. **Rails**: A payout rule picks the rail per seller: same-day ACH for US sellers, a dollar stablecoin for sellers who ask for it. 3. **Record**: Every payout carries its fee lines and the rule that chose the rail. Each settlement reconciles to its orders. ## What it uses - **Your rules**: Rules by card type, region, amount or time. Reviewable and reversible. - **Bank payouts**: ACH, same-day ACH and instant bank rails, per account. - **Stablecoin payouts**: Pay sellers, suppliers or partners in stablecoins, by rule. - **Wallet screening**: Screen counterparties before money moves. - **Fee lines**: Network, scheme and insimbi fees, itemized per transaction. - **Reconciliation**: Each settlement row matched to the transactions behind it. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # An agent paying for API calls, one request at a time A US data provider selling an API, and the AI agents that call it. **Illustrative scenario.** A fictional type of business, not a customer. No results are claimed. Cohorts: Mm + Sc Video (36 s, illustrative): [MP4](/assets/use-cases/agent-api-payments.mp4) · captions: [WebVTT](/assets/use-cases/agent-api-payments.vtt) · step list for software: [flow.json](/assets/use-cases/agent-api-payments.flow.json) ## The problem Agents need data now, not after a sales call and a monthly invoice. API keys and invoices don't fit software that buys on its own. The provider needs to know who is paying and to stop runaway spend. ## Value anatomy 1. **Transaction**: The API answers an unpaid request with a price. The agent's mandate allows it, so it pays and retries. 2. **Rails**: Small payments settle in a dollar stablecoin, or batch onto a card when the buyer prefers. 3. **Record**: Each call, its price and the mandate that allowed it land in one line. The buyer and the provider see the same record. ## What it uses - **Per-request payments**: Charge or pay per API call over HTTP 402, in fiat or stablecoins. - **Agent mandates**: Bind an agent to a principal, a spend limit and a scope. - **Payment intent preview**: Check a request against the mandate before it runs. - **Scoped API access**: Credentials limited to one principal and one scope. - **Fee lines**: Network, scheme and insimbi fees, itemized per transaction. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # A procurement agent buying from suppliers A US manufacturer that lets an AI agent reorder parts from approved suppliers. **Illustrative scenario.** A fictional type of business, not a customer. No results are claimed. Cohorts: Mm + Fi Video (36 s, illustrative): [MP4](/assets/use-cases/procurement-agent.mp4) · captions: [WebVTT](/assets/use-cases/procurement-agent.vtt) · step list for software: [flow.json](/assets/use-cases/procurement-agent.flow.json) ## The problem The agent can find the best price, but finance won't hand it a corporate card. Every purchase needs a limit, a supplier list and a trail an auditor can follow. ## Value anatomy 1. **Transaction**: The agent proposes an order. Two checks run before it reaches the network: policy first (is it inside the mandate: supplier, amount, category?), then risk (does this payment look like this agent?). Both results are lines on the record. 2. **Rails**: An approved order is paid with a single-use card credential, or by bank transfer for suppliers that invoice. 3. **Record**: Each purchase is tied to the agent, the person it acts for and the mandate. Refunds and disputes go to the exception queue. ## What it uses - **Agent mandates**: Bind an agent to a principal, a spend limit and a scope. - **Agent card credentials**: Single-use or limited card credentials for agent purchases. - **Payment intent preview**: Check a request against the mandate before it runs. - **Exception queue**: Disputes, refunds and failed payouts in one list, each with its rule. - **Audit log**: Who changed what, when, and what it touched. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # An event-contract venue settling winners A US regulated event-contract venue with retail customers. **Illustrative scenario.** A fictional type of business, not a customer. No results are claimed. Cohorts: Mk + Sc Video (36 s, illustrative): [MP4](/assets/use-cases/prediction-market-settlement.mp4) · captions: [WebVTT](/assets/use-cases/prediction-market-settlement.vtt) · step list for software: [flow.json](/assets/use-cases/prediction-market-settlement.flow.json) ## The problem Customers fund accounts at all hours and expect winnings fast when a contract resolves. Customer money must stay separate from the venue's own. Every withdrawal needs a reason on file. ## Value anatomy 1. **Transaction**: Customers fund by debit card, bank transfer or stablecoin. Funds land in segregated customer balances. 2. **Rails**: When a contract resolves, payouts go out on the rail each customer picked, inside the venue's withdrawal rules. 3. **Record**: Each payout links to the contract, the resolution and the rule that released it. ## What it uses - **Account funding**: Fund customer accounts by card, bank or stablecoin. - **Segregated balances**: Customer funds and house funds kept apart in the record. - **Settlement payouts**: Pay out after a contract resolves, on the rail the customer picked. - **Withdrawal rules**: Limits, holds and reviews you set and can explain. - **Cutoff preview**: See which payouts make the next window. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # A tokenized fund taking subscriptions and paying redemptions A US asset manager running a tokenized short-term Treasury fund for qualified investors. **Illustrative scenario.** A fictional type of business, not a customer. No results are claimed. Cohorts: Tk + Sc Video (36 s, illustrative): [MP4](/assets/use-cases/tokenized-fund.mp4) · captions: [WebVTT](/assets/use-cases/tokenized-fund.vtt) · step list for software: [flow.json](/assets/use-cases/tokenized-fund.flow.json) ## The problem Investors want to subscribe and redeem in stablecoins as well as dollars, at any hour. Operations must match every cash movement to the token register and check every holder's eligibility. ## Value anatomy 1. **Transaction**: An investor subscribes by wire or stablecoin. insimbi checks eligibility before accepting funds. 2. **Rails**: Redemptions and distributions go out in dollars or stablecoins, per holder instruction. 3. **Record**: Each cash movement matches to a register entry. Mismatches go to the exception queue. ## What it uses - **Subscriptions**: Take subscriptions by wire, ACH or stablecoin. - **Redemptions**: Pay redemptions on the rail the holder picked. - **Distributions**: Pay yield or dividends to many holders in one run. - **Register matching**: Match each cash movement to the asset register. - **Holder screening**: Check eligibility before money moves. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # A retailer taking control of card costs A US omnichannel retailer with stores and an online shop. **Illustrative scenario.** A fictional type of business, not a customer. No results are claimed. Cohorts: Fi + Vs Video (36 s, illustrative): [MP4](/assets/use-cases/retailer-card-costs.mp4) · captions: [WebVTT](/assets/use-cases/retailer-card-costs.vtt) · step list for software: [flow.json](/assets/use-cases/retailer-card-costs.flow.json) ## The problem Card fees arrive as one blended number. Nobody can say what each payment cost, which debit network carried it, or what choosing another network would save. ## Value anatomy 1. **Transaction**: Each card payment runs through the retailer's own rules: by card type, channel and amount. 2. **Rails**: Eligible debit goes to the debit network the retailer's rule chooses, compared against your current setup, payment by payment. 3. **Record**: Every payment shows its network, the rule that chose it and its fee lines, so finance can model the next change before making it. ## What it uses - **Your rules**: Rules by card type, region, amount or time. Reviewable and reversible. - **Debit network choice**: Send eligible debit to the network your rules pick. - **Parallel run**: Compared against your current setup, payment by payment. - **Cost modelling**: Preview a rule or payout change before you make it. - **Fee lines**: Network, scheme and insimbi fees, itemized per transaction. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # An insurer paying claims on the fastest sensible rail A US property insurer paying claims to policyholders and repair shops. **Illustrative scenario.** A fictional type of business, not a customer. No results are claimed. Cohorts: Fi + Sc Video (36 s, illustrative): [MP4](/assets/use-cases/insurer-claims.mp4) · captions: [WebVTT](/assets/use-cases/insurer-claims.vtt) · step list for software: [flow.json](/assets/use-cases/insurer-claims.flow.json) ## The problem Claimants wait for checks. Some want money in minutes, others are fine with a bank transfer. Each claim payment needs a clear trail for the regulator. ## Value anatomy 1. **Transaction**: An approved claim creates a payout instruction with the payee and amount. 2. **Rails**: A payout rule picks the rail: instant bank payment where supported, ACH otherwise, a stablecoin for payees who ask. 3. **Record**: Each payout links to the claim, the rail chosen and why. Returns land in the exception queue. ## What it uses - **Bank payouts**: ACH, same-day ACH and instant bank rails, per account. - **Stablecoin payouts**: Pay sellers, suppliers or partners in stablecoins, by rule. - **Payout cutoffs**: See the next settlement window before it closes. - **Exception queue**: Disputes, refunds and failed payouts in one list, each with its rule. - **Reconciliation**: Each settlement row matched to the transactions behind it. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # A software platform billing people and agents A US software company selling seats to people and usage to AI agents. **Illustrative scenario.** A fictional type of business, not a customer. No results are claimed. Cohorts: Mm + Fi + Vs Video (36 s, illustrative): [MP4](/assets/use-cases/software-platform-billing.mp4) · captions: [WebVTT](/assets/use-cases/software-platform-billing.vtt) · step list for software: [flow.json](/assets/use-cases/software-platform-billing.flow.json) ## The problem Seats bill monthly by card. Agent usage arrives in millions of tiny calls. Today these sit in two systems that never agree. ## Value anatomy 1. **Transaction**: Seats renew by card. Agent usage is metered per call against each agent's mandate. 2. **Rails**: Cards for seats. Per-request payments in fiat or stablecoins for agent usage. 3. **Record**: Both streams land in one ledger, by customer, so revenue and fees reconcile in one place. ## What it uses - **Per-request payments**: Charge or pay per API call over HTTP 402, in fiat or stablecoins. - **Agent mandates**: Bind an agent to a principal, a spend limit and a scope. - **Card account updates**: Keep stored cards current. - **Fee lines**: Network, scheme and insimbi fees, itemized per transaction. - **Data streaming**: Raw events, settlements and fees into your warehouse. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Agent payment workers Workers that run your payments back office, under your rules. Workers are agents that run the payments back office. Each one works under your rules and inside a mandate you set. Each action lands in the record with the rule behind it. They propose, you approve what matters, and nothing they do is hidden. 1. **Rule**: You write it. Workers can't change it. 2. **Mandate**: What a worker may do, for whom, up to what limit. 3. **Record**: Every action, its reason and its result, in the ledger. ## Rail worker Applies your rules to every payment and writes the decision to its ticket, cited to the rule that chose the rail. - **Allowed to**: Choose among the rails your rules allow. It can't add a rail or change a rule. - **Writes to the record**: A decision on each ticket, linked to the ledger line. ## Reconciliation worker Matches every settlement, payout and fee line back to its source transaction, across cards, bank rails and stablecoins. - **Allowed to**: Match and flag. It can't move money. - **Writes to the record**: A match record per row. Breaks go to the exception queue with the evidence attached. ## Payout worker Builds each payout run from your schedule, shows which items make the next cutoff, and sends them on the rail each payee chose. - **Allowed to**: Release payouts inside your schedule and limits. Larger runs wait for your approval. - **Writes to the record**: The run, each payout, its rail, its fees and its cutoff. ## Dispute worker Gathers evidence for each dispute from the record, drafts the response and tracks every deadline. - **Allowed to**: Draft and file inside the rules you set. You approve anything above your threshold. - **Writes to the record**: The evidence pack, what was filed, when and the outcome. ## Mandate worker Checks every agent request against what that agent may do, through the same access check the API runs. Each request is allowed or denied, and the decision is recorded before any response goes out. It quotes the payment before anything reaches a network. - **Allowed to**: Allow or deny. It can't widen what an agent may do: that change is proposed, and a person approves it. - **Writes to the record**: The request, the access decision (allowed or denied) and its decision ID. ## Fee worker Checks every fee line against your contracted rates and flags anything that doesn't match. - **Allowed to**: Flag and report. It can't change a rate. - **Writes to the record**: A fee check per movement, plus a monthly variance report. ## You stay in control - Every worker runs under a mandate you can read, change and revoke. - Actions above your thresholds wait for a person. - Every action has a reason, a rule version and an undo path. - Every access decision, allowed or denied, is recorded before any response goes out. - Widening what an agent may do is a proposed change. A person approves it, and the approval is bound to that change. - Your own agents use the same API, the same mandates and the same record. _The rail, reconciliation, payout, dispute and fee workers run on the designed payment endpoints in the API reference. The mandate worker's decisions run through the API's access check._ - [Mandates and the decision trace](/docs/concepts/): How rules, mandates and the record fit together. - [MCP tools](/docs/mcp/): Run or supervise workers from any MCP client. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Integrations Every rail and every major agent protocol. One record. insimbi connects to the rails you already use and the ones you're adding. Every connection writes to the same record, with the same fee lines and the same decision trace. ## Rails - **Cards** (Fi): Visa and Mastercard, through more than one acquirer. Network tokens. EMV 3-D Secure. - **US bank rails** (Fi): ACH, Same Day ACH, RTP, FedNow and Fedwire (ISO 20022). - **Stablecoins** (Sc): USDC, USDT and PYUSD on Ethereum, Solana, Base and Tron, through regulated partners. - **Tokens** (Tk): ERC-20 and ERC-3643 assets, with cross-chain movement over Chainlink CCIP. - **Markets** (Mk): FIX connectivity and CFTC-regulated venue APIs for funding and settlement. ## Agent protocols Cohorts: Mm Supports: MCP, Agent Payments Protocol (AP2), Agentic Commerce Protocol (ACP), Universal Commerce Protocol (UCP), Machine Payments Protocol (MPP), x402, Visa Intelligent Commerce, Visa Trusted Agent Protocol, Mastercard Agent Pay Accept agent checkouts on any of these and settle on the rail your rules choose. No protocol locks you to one network or one chain. ## Partners - **Acquirers**: Bring your current acquirers or add new ones. Run them side by side. - **Banks**: Sponsor and settlement banks for US bank rails. - **Stablecoin partners**: Regulated partners for custody, mint and redeem, and conversion to dollars. - **Risk and fraud**: Bring your own fraud tools or use partner signals, scored per payment. - **Identity and KYB**: Verified legal entities for onboarding and for every agent of record. - **Geolocation**: Location checks where a market or venue requires them. - **Tax forms**: Payee tax details and year-end forms for payouts. - **Event-contract venues**: Order entry, fills, positions and settlements, reconciled to the record. - **Connected-account platforms**: Sub-merchant onboarding, transfers and payouts, with webhooks matched to the record. - **Edge and bot verification**: Signed agent requests verified before checkout, and pay-per-request access recorded per request. ## Platforms and data - **Your warehouse**: Stream raw events, settlements and fees as webhooks, CSV or Parquet. - **ERP and accounting**: Post ledger entries with fee lines to your general ledger. - **Agent frameworks**: Any MCP client, plus clients generated from our OpenAPI contract. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Docs Build on the record. Read every decision. Everything here is also markdown: add .md to any address. Agents can start at /llms.txt. - [Flows](/docs/flows/): An index of every sequence diagram, each shown in the section it explains. - [Quickstart](/docs/quickstart/): Sandbox credentials to a token and your first account read. - [Core concepts](/docs/concepts/): Transaction, rails and record. Access and the audit record. Mandates. - [API reference](/docs/api/): The OpenAPI contract, then the designed payment endpoints. - [MCP tools](/docs/mcp/): insimbi as tools for any MCP client. - [Webhooks](/docs/webhooks/): Events for every movement and every decision. - [Sandbox](/docs/sandbox/): Separate credentials and sandbox accounts. Nothing real moves. - [SDKs](/docs/sdks/): OpenAPI first. Generate a client in any language. **Pages show what is in the OpenAPI contract and mark what is designed. Designed endpoints and examples are illustrative and can change before your account is live.** Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Flows Every sequence diagram, linked to the section it explains. Every flow is a numbered sequence diagram with the same steps written out underneath. Each one now sits in the section it explains; this page links to them. Sign-in is in the OpenAPI contract. The rest are designed and marked that way. ## Sign-in - [Sign in with a signed client assertion](/docs/quickstart/#flow-token): Quickstart, step 1. In the OpenAPI contract. ## Payments - [A payment, end to end](/docs/api/#flow-payment): API reference, POST /v1/payments. Designed. ## Webhooks - [An event, from the change to your endpoint](/docs/webhooks/#flow-webhooks): Webhooks. Designed. ## Agent protocols - [MCP tools](/docs/mcp/#flow-mcp): MCP tools. Designed. - [x402 with insimbi in the path](/docs/protocols/x402/#flow-x402): Its own page. Designed. - [Agent Payments Protocol (AP2)](/docs/protocols/ap2/#flow-ap2): Its own page. Designed. - [Agentic Commerce Protocol (ACP)](/docs/protocols/acp/#flow-acp): Its own page. Designed. - [Machine Payments Protocol (MPP)](/docs/protocols/mpp/#flow-mpp): Its own page. Designed. - [Universal Commerce Protocol (UCP)](/docs/protocols/ucp/#flow-ucp): Its own page. Designed. - [Visa Intelligent Commerce](/docs/protocols/vic/#flow-vic): Its own page. Designed. - [Visa Trusted Agent Protocol](/docs/protocols/tap/#flow-tap): Its own page. Designed. - [Mastercard Agent Pay](/docs/protocols/agentpay/#flow-agentpay): Its own page. Designed. Connectors to venues, stablecoin partners, connected-account platforms and edge verification are listed under Partners on Integrations (/integrations/#partners). Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Quickstart From sandbox credentials to your first account read. 1. Get sandbox credentials. Request access and we register your client and its public signing key. You get a client_id. 2. Get an access token from /oauth2/token with a signed client assertion. 3. Read your merchant account. 4. Designed: create a payment, read its ticket and receive its events. ## 1. Get a token Sign-in, step by step: your service signs a client assertion, swaps it for a token, then reads with it. Every decision is recorded. **Sign in with a signed client assertion.** In the OpenAPI contract. Lanes: Your service, insimbi API, Audit record 1. Your service: Sign a client assertion (JWT, RS256) with your registered private key. Audience: the token endpoint. 2. Your service to insimbi API: POST /oauth2/token with grant_type, client_id, client_assertion and optional scope 3. insimbi API: Verify the signature against your registered key, reject replays, check your credential, grants and scopes 4. insimbi API to Audit record: Record token.issued (or security.rejected) 5. insimbi API to Your service: 200: access_token, token_type Bearer, expires_in (60 s at most), scope 6. Your service to insimbi API: GET /v1/merchant-accounts/{id} with Authorization: Bearer 7. insimbi API to Audit record: Record the access decision: authorization.allowed or authorization.denied 8. Audit record to insimbi API: Decision captured 9. insimbi API to Your service: 200 merchant account, or 403 insufficient_authority. X-Request-ID on every response. _From the OpenAPI contract._ ``` curl https://sandbox.api.insimbi.xyz/oauth2/token \ -d grant_type=client_credentials \ -d client_id=$CLIENT_ID \ -d client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer \ -d client_assertion=$SIGNED_JWT ``` The client assertion is a JWT you sign with your registered private key (RS256). Its audience is exactly https://sandbox.api.insimbi.xyz/oauth2/token. Leave out scope to get every scope your client is allowed, or ask for a subset. There are no client secrets. _From the OpenAPI contract._ ``` { "access_token": "", "token_type": "Bearer", "expires_in": 60, "scope": "organization.read legal_entity.read merchant_account.read" } ``` Tokens are short-lived: expires_in is at most 60 seconds. Get a new token when one expires. ## 2. Read your merchant account _From the OpenAPI contract._ ``` curl https://sandbox.api.insimbi.xyz/v1/merchant-accounts/$MERCHANT_ACCOUNT_ID \ -H "Authorization: Bearer $TOKEN" ``` _From the OpenAPI contract._ ``` { "id": "", "organization_id": "", "legal_entity_id": "", "environment": "sandbox", "environment_id": "", "status": "active" } ``` ## 3. Create a payment **Designed.** Payments, tickets and webhooks are designed endpoints. They are not in the OpenAPI contract yet. The full payment flow, from the rule check to the record, is on the API reference (/docs/api/#flow-payment). _Illustrative example._ ``` curl https://sandbox.api.insimbi.xyz/v1/payments \ -H "Authorization: Bearer $TOKEN" \ -H "Idempotency-Key: 6f1c2a90-order-1042" \ -d '{"merchant_account_id":"","amount":"182.40","currency":"USD","source":"tok_sandbox_debit"}' ``` ## 4. Read the ticket _Illustrative example._ ``` curl https://sandbox.api.insimbi.xyz/v1/tickets/tkt_01J9 -H "Authorization: Bearer $TOKEN" ``` _Illustrative example._ ``` { "id": "tkt_01J9", "payment_id": "pay_01J9", "status": "settled", "lines": [ { "label": "interchange", "amount": "0.31", "rule": "rule:interchange.debit.regulated@v3" }, { "label": "network", "amount": "0.04", "rule": "rule:network.assessment@v7" }, { "label": "insimbi", "amount": "0.05", "rule": "rule:contract.platform_fee@v2" } ], "decisionRefs": [ "dec_rail_01J9" ], "eventRefs": [ "evt_01J9a", "evt_01J9b" ] } ``` Every fee line cites the rule that produced it. Nothing is blended. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Core concepts Transaction, rails, record. Access, rules, mandates. 1. **Transaction**: Who pays whom, for what, under which mandate. 2. **Rails**: The network, bank rail, chain or venue that carries it. 3. **Record**: A ledger entry with fee lines, the rule and its reconciliation. ## A payment, end to end Authenticate, check the rules and the agent's mandate, ask a person above your threshold, let the rail rule choose the rail, then write the ledger entry, fee lines and ticket. The sequence diagram is with the endpoint, on the API reference (/docs/api/#flow-payment). ## Access and the audit record Every API call carries a short-lived token, and every protected read is checked against the grants for its organization. The decision, allowed or denied, gets a decision ID and is written to the audit record before the response is released. If the decision can't be recorded, the response isn't sent. - **Access decisions**: authorization.allowed, authorization.denied, authentication.failed - **Tokens and rejections**: token.issued, security.rejected, security.unavailable, security.capacity_rejected - **Clients**: principal.created, principal.suspended - **Credentials**: credential.issued, credential.rotated, credential.compromised, credential.revoked - **Roles and grants**: role.created, grant.created, grant.revoked - **Approvals**: approval.proposed, approval.approved Widening access is a change that is proposed and then approved by a person. The approval is bound to that exact change and can't be reused for another. ## Rules A rule chooses the rail. Rules are versioned code. You can diff, test in the sandbox and roll back any rule in one step. ## Tickets and the decision trace Every payment has a ticket: its fee lines, each cited to a rule in the rules register, plus references to the decisions and events behind it. Ask why a payment took its rail, was priced or was declined and you get the answer line by line, with citations. ## Mandates and perimeters A mandate is the set of bounds an operator approves for an agent: scopes, caps, recipients and finality rules. In the designed API it is a perimeter, versioned and expiring. Every request is checked against it before anything reaches a network. Outside it, the request is denied and the denial is recorded. The access layer already works this way: grants decide what each client may do, every denial is recorded, and widening a grant needs an approved change. ## Agent of record Every agent-initiated payment carries an agent of record: the verified legal entity that answers for it. Agents authenticate as registered clients with their own signing keys, never with a shared secret. ## Accounts Organizations hold legal entities. Legal entities hold merchant accounts. Each has its own read permission (organization.read, legal_entity.read, merchant_account.read), and credentials and grants are scoped along that hierarchy. ## The record One double-entry ledger for fiat, stablecoins, market funding, token cash legs and agent payments. Fee lines are entries, not footnotes. ## Idempotency and versions Designed payment writes take an Idempotency-Key header. Money amounts are decimal strings with an explicit currency. Objects carry the rule and perimeter versions that produced them. --- # API reference The OpenAPI contract, then the designed endpoints. **Base URL: https://sandbox.api.insimbi.xyz. The first part is the OpenAPI contract. Request access for the full specification.** ## In the OpenAPI contract - **GET /health**: Liveness. Returns 204 with no body. No token needed. - **POST /oauth2/token**: Exchange a signed client assertion for a short-lived Bearer token. Form fields: grant_type=client_credentials, client_id, client_assertion_type, client_assertion and an optional scope. - **GET /.well-known/oauth-authorization-server**: Authorization server metadata: issuer, token endpoint, JWKS URI, the client_credentials grant, private_key_jwt client authentication and RS256. - **GET /.well-known/jwks.json**: Public RS256 keys to verify tokens, each with a kid. During rotation more than one key is published. - **GET /v1/organizations/{organization_id}**: Read an organization. Needs organization.read. Returns id, environment, environment_id and status. - **GET /v1/legal-entities/{legal_entity_id}**: Read a legal entity. Needs legal_entity.read. Adds organization_id. - **GET /v1/merchant-accounts/{merchant_account_id}**: Read a merchant account. Needs merchant_account.read. Adds organization_id and legal_entity_id. _From the OpenAPI contract._ ``` { "issuer": "https://sandbox.api.insimbi.xyz", "token_endpoint": "https://sandbox.api.insimbi.xyz/oauth2/token", "jwks_uri": "https://sandbox.api.insimbi.xyz/.well-known/jwks.json", "grant_types_supported": [ "client_credentials" ], "token_endpoint_auth_methods_supported": [ "private_key_jwt" ], "token_endpoint_auth_signing_alg_values_supported": [ "RS256" ] } ``` ## Errors Account reads return one error shape. The request_id matches the X-Request-ID header. _From the OpenAPI contract._ ``` { "error_version": "error/1.0", "code": "insufficient_authority", "message": "", "request_id": "" } ``` - **401**: invalid_identity: The token is missing, expired or invalid. - **403**: insufficient_authority: The token is valid but lacks the permission for this resource. - **404**: not_found: The resource doesn't exist or isn't visible to you. - **429**: rate_limited: Too many requests. - **503**: unavailable: The service can't decide safely right now. The token endpoint returns the OAuth error shape, {"error": ""}, with Cache-Control: no-store. Codes: invalid_request, invalid_client, invalid_scope and unsupported_grant_type with 400, and temporarily_unavailable with 503. It also returns 405 for the wrong method and 429 when rate limited. ## Request IDs Every response carries an X-Request-ID header. On token and account requests we always assign a fresh one. On other paths, an ID you send is kept if it is 1 to 128 letters, digits, dots, underscores or hyphens. Quote the request ID when you contact us, and never put secrets or personal data in it. ## Retries Retry 429 and 503 with exponential backoff and jitter, and get a fresh token if yours has expired. Don't retry 400, 401, 403 or 404 unchanged: fix the request, the credentials or the grant first. When a decision can't be made safely, the API returns 503, never a cached allow. ## Designed endpoints **Designed.** These endpoints are specified in our designs and are not in the OpenAPI contract yet. Paths and fields are illustrative and can change. - **GET /v1/grants/{grant_id}**: Read an access grant. - **POST /v1/payments**: Create a payment. Requires Idempotency-Key. - **POST /v1/payments/{payment_id}/captures**: Capture an authorized payment. - **GET /v1/transactions**: Search transactions by status. - **GET /v1/tickets/{ticket_id}**: Read a ticket: fee lines with rule citations, decision and event references. - **POST /v1/cutoffs/preview**: See what a cutoff change would do. Changes nothing. - **POST /v1/exports/preview**: Start an export job. - **GET /v1/exports/{job_id}**: Check an export job. - **GET /v1/events**: List events with cursor pagination. - **GET /v1/webhooks/{webhook_id}/deliveries**: List deliveries for an endpoint. - **GET /v1/webhooks/{webhook_id}/deliveries/{delivery_id}/attempts**: See every attempt, status and timing. - **POST /v1/webhooks/{webhook_id}/deliveries/{delivery_id}/replays**: Replay a delivery. ## POST /v1/payments: a payment, end to end **Designed.** Payment endpoints are designed. Every check in this flow is written to the record. **A payment, end to end.** Designed. Where the rule check, approval, rail choice and record happen. Lanes: Your app or agent, insimbi API, Rules and mandate check, Operator, Rail, Record 1. Your app or agent to insimbi API: POST /v1/payments with an Idempotency-Key 2. insimbi API: Authenticate the token and record the access decision 3. insimbi API to Rules and mandate check: Check the payment against your rules and the agent's mandate 4. Rules and mandate check to Operator: Above your threshold: propose for approval 5. Operator to Rules and mandate check: A person approves 6. Rules and mandate check to insimbi API: Allowed. The rail rule chooses the rail. 7. insimbi API to Rail: Submit on the chosen rail 8. Rail to insimbi API: Rail result 9. insimbi API to Record: Write the ledger entry, fee lines cited to rules, and the ticket 10. insimbi API to Your app or agent: 201 with the ticket id 11. insimbi API to Your app or agent: Event delivered to your webhook endpoint ## Example: price a payment before it runs Agents use the designed quote_ticket tool (see MCP tools). It returns the fee lines and the perimeter decision that would apply, without submitting anything. _Illustrative example._ ``` { "tool": "quote_ticket", "input": { "amount": "0.02", "currency": "USD", "payee": "api.example-data.com" } } ``` _Illustrative example._ ``` { "lines": [ { "label": "network", "amount": "0.0004", "rule": "rule:rail.stablecoin.fee@v1" } ], "perimeter": { "id": "per_01J9", "version": 3, "decision": "allow" } } ``` --- # MCP tools insimbi as tools for any MCP client. **Designed.** The MCP server and these tools are designed. The server address comes with your access. Connect any MCP client to insimbi. Each agent is bound to an agent of record and acts inside a perimeter, so it can only do what you allowed. _Illustrative example._ ``` { "mcpServers": { "insimbi": { "url": "", "auth": "oauth" } } } ``` - **quote_ticket**: Price a proposed payment before submission. Returns fee lines with rule citations and the perimeter decision. - **explain_decision**: Explain why a payment took its rail, was priced, declined or was denied, line by line, each cited to a rule. - **get_rule**: Resolve a citation to its rule text, source and version. - **open_mandate**: Request a perimeter from an operator. Creates a pending request; a person approves it. Agents can price and explain on their own. Widening what an agent may do always needs a person. It works like access changes in the API: the change is proposed (approval.proposed), a person approves it (approval.approved), and the approval is bound to that exact change. **MCP tools.** Designed. Tool calls over MCP, with a person approving any wider access. Lanes: Agent (MCP client), insimbi MCP server, insimbi API and record, Operator 1. Agent (MCP client) to insimbi MCP server: tools/list 2. insimbi MCP server to Agent (MCP client): quote_ticket, explain_decision, get_rule, open_mandate 3. Agent (MCP client) to insimbi MCP server: tools/call quote_ticket 4. insimbi MCP server to insimbi API and record: Price the payment against your rules. Nothing is submitted. 5. insimbi API and record to Agent (MCP client): Fee lines with rule citations and the perimeter decision 6. Agent (MCP client) to insimbi MCP server: tools/call open_mandate 7. insimbi MCP server to insimbi API and record: Propose the change (approval.proposed) 8. insimbi API and record to Operator: Ask a person to approve 9. Operator to insimbi API and record: Approve (approval.approved), bound to that exact change 10. insimbi API and record to Agent (MCP client): Mandate granted Other agent protocols: x402, AP2, ACP, MPP, UCP, Visa Intelligent Commerce, Visa Trusted Agent Protocol and Mastercard Agent Pay each have a page with their flow. See Flows (/docs/flows/#protocols). --- # x402 HTTP 402 payments from agents, verified and settled through a regulated partner. Cohorts: Mm + Sc **Designed.** Protocol support is designed. The flow follows the protocol's published specification, with insimbi on the merchant side. Every check and every settlement is written to the record. **x402 with insimbi in the path.** Designed. Follows the x402 HTTP flow: 402, signed retry, verify, work, settle. Lanes: Client (agent), Merchant API, insimbi, Facilitator (regulated partner) 1. Client (agent) to Merchant API: Request a resource 2. Merchant API to insimbi: Price it and check your rules for which assets and networks to accept 3. Merchant API to Client (agent): 402 Payment Required with a PAYMENT-REQUIRED header 4. Client (agent) to Merchant API: Retry with a signed payment in the PAYMENT-SIGNATURE header 5. Merchant API to insimbi: Check the payment against your rules and the agent's mandate 6. insimbi to Facilitator (regulated partner): POST /verify 7. Facilitator (regulated partner) to insimbi: Verification result (isValid, payer) 8. insimbi to Merchant API: Allowed 9. Merchant API: Perform the work 10. Merchant API to insimbi: Settle 11. insimbi to Facilitator (regulated partner): POST /settle 12. Facilitator (regulated partner) to insimbi: Settlement result (success, transaction, network) 13. insimbi: Write the ledger entry and fee lines to the record 14. Merchant API to Client (agent): Return the resource with a PAYMENT-RESPONSE header - [All flows](/docs/flows/): Every sequence diagram, linked to its section. - [Integrations](/integrations/#protocols): Every agent protocol and rail we connect. - [MCP tools](/docs/mcp/): insimbi as tools for any MCP client. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Agent Payments Protocol (AP2) A person present, an agent shopping, insimbi as the merchant's payment processor. Cohorts: Mm + Fi **Designed.** Protocol support is designed. The flow follows the protocol's published specification, with insimbi on the merchant side. Every check and every settlement is written to the record. **Agent Payments Protocol (AP2).** Designed. AP2 human-present journey, with insimbi as the merchant's payment processor. Lanes: User (trusted surface), Shopping agent, Merchant, insimbi, Credentials provider and network 1. User (trusted surface) to Shopping agent: Give the agent a shopping task 2. Shopping agent to Merchant: Build a cart 3. Merchant to Shopping agent: Cart, signed by the merchant 4. Shopping agent to Credentials provider and network: Ask for an applicable payment method 5. Shopping agent to User (trusted surface): Show the cart and payment method 6. User (trusted surface) to Shopping agent: Approve: a signed Checkout Mandate 7. Shopping agent to Merchant: Submit the order with the Checkout Mandate and Payment Mandate 8. Merchant to insimbi: Authorize the payment 9. insimbi: Check the mandates against your rules, choose the rail 10. insimbi to Credentials provider and network: Authorization, with agent presence signals 11. Credentials provider and network to insimbi: Approved (or a challenge such as 3-D Secure) 12. insimbi to Merchant: Result, written to the record 13. Merchant to User (trusted surface): Order confirmed - [All flows](/docs/flows/): Every sequence diagram, linked to its section. - [Integrations](/integrations/#protocols): Every agent protocol and rail we connect. - [MCP tools](/docs/mcp/): insimbi as tools for any MCP client. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Agentic Commerce Protocol (ACP) Checkout sessions and a delegated payment token, charged by insimbi for the merchant. Cohorts: Mm + Fi **Designed.** Protocol support is designed. The flow follows the protocol's published specification, with insimbi on the merchant side. Every check and every settlement is written to the record. **Agentic Commerce Protocol (ACP).** Designed. ACP checkout sessions and a delegated payment token, with insimbi charging for the merchant. Lanes: Agent, Merchant, insimbi, Delegated payment provider 1. Agent to Merchant: POST /checkout_sessions (line items, currency) 2. Merchant to Agent: 201 with the authoritative cart, totals and fulfilment options 3. Agent to Merchant: POST /checkout_sessions/{id} to update choices 4. Agent to Delegated payment provider: POST /agentic_commerce/delegate_payment with an allowance 5. Delegated payment provider to Agent: Delegated token id 6. Agent to Merchant: POST /checkout_sessions/{id}/complete with payment_data 7. Merchant to insimbi: Charge the delegated token 8. insimbi: Check your rules and the allowance, choose the rail 9. insimbi to Delegated payment provider: Redeem the token within its allowance 10. Delegated payment provider to insimbi: Result 11. insimbi to Merchant: Result, written to the record 12. Merchant to Agent: Completed checkout and order - [All flows](/docs/flows/): Every sequence diagram, linked to its section. - [Integrations](/integrations/#protocols): Every agent protocol and rail we connect. - [MCP tools](/docs/mcp/): insimbi as tools for any MCP client. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Machine Payments Protocol (MPP) Challenge, Credential and Receipt over HTTP 402, on the rail your rules choose. Cohorts: Mm + Fi + Sc **Designed.** Protocol support is designed. The flow follows the protocol's published specification, with insimbi on the merchant side. Every check and every settlement is written to the record. **Machine Payments Protocol (MPP).** Designed. MPP's Challenge, Credential and Receipt over HTTP 402. Lanes: Client (agent), Merchant API, insimbi, Payment method (rail or regulated partner) 1. Client (agent) to Merchant API: Request a resource 2. Merchant API to insimbi: Price it and pick the payment methods your rules allow 3. Merchant API to Client (agent): 402 Payment Required with WWW-Authenticate: Payment (the Challenge) 4. Client (agent) to Payment method (rail or regulated partner): Pay with the method the Challenge names 5. Client (agent) to Merchant API: Retry with Authorization: Payment (the Credential) 6. Merchant API to insimbi: Verify the Credential is bound to the original Challenge 7. insimbi to Payment method (rail or regulated partner): Confirm the payment 8. Payment method (rail or regulated partner) to insimbi: Confirmed 9. insimbi: Write the ledger entry and fee lines to the record 10. Merchant API to Client (agent): 200 with a Payment-Receipt header - [All flows](/docs/flows/): Every sequence diagram, linked to its section. - [Integrations](/integrations/#protocols): Every agent protocol and rail we connect. - [MCP tools](/docs/mcp/): insimbi as tools for any MCP client. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Universal Commerce Protocol (UCP) Discovery, payment handlers and complete checkout. Cohorts: Mm + Fi **Designed.** Protocol support is designed. The flow follows the protocol's published specification, with insimbi on the merchant side. Every check and every settlement is written to the record. **Universal Commerce Protocol (UCP).** Designed. UCP discovery, payment handlers and complete checkout. Lanes: Platform (agent), Business, insimbi, Payment handler 1. Platform (agent) to Business: GET /.well-known/ucp 2. Business to Platform (agent): Profile: version, services, capabilities, payment handlers 3. Platform (agent) to Business: Create checkout 4. Business to Platform (agent): Checkout, advertising the payment handlers it accepts 5. Platform (agent) to Payment handler: Execute the handler to get a token or credential 6. Payment handler to Platform (agent): Token 7. Platform (agent) to Business: Complete checkout with the token 8. Business to insimbi: Authorize 9. insimbi: Check your rules, choose the rail, write the record 10. insimbi to Business: Result (or a challenge for strong authentication) 11. Business to Platform (agent): Checkout completed - [All flows](/docs/flows/): Every sequence diagram, linked to its section. - [Integrations](/integrations/#protocols): Every agent protocol and rail we connect. - [MCP tools](/docs/mcp/): insimbi as tools for any MCP client. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Visa Intelligent Commerce Agent tokens, passkey-authenticated payment instructions and commerce signals. Cohorts: Mm + Fi **Designed.** Protocol support is designed. The flow follows the protocol's published specification, with insimbi on the merchant side. Every check and every settlement is written to the record. **Visa Intelligent Commerce.** Designed. Agent tokens, passkey-authenticated payment instructions and commerce signals. Lanes: User, Agent, Visa, Merchant, insimbi 1. Agent to Visa: Enrol the card: an agent-specific token, cardholder step-up and a passkey 2. Agent to User: Recommend a purchase and ask to make it 3. User to Agent: Authenticate the payment instruction with the passkey 4. Agent to Visa: Submit the instruction and request payment credentials 5. Visa to Agent: Credentials that match the instruction 6. Agent to Merchant: Check out with the agent token 7. Merchant to insimbi: Authorize 8. insimbi to Visa: Authorization through the network, which checks merchant and amount against the instruction 9. Visa to insimbi: Result 10. insimbi to Merchant: Result, written to the record 11. Agent to Visa: Share the purchase outcome as commerce signals - [All flows](/docs/flows/): Every sequence diagram, linked to its section. - [Integrations](/integrations/#protocols): Every agent protocol and rail we connect. - [MCP tools](/docs/mcp/): insimbi as tools for any MCP client. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Visa Trusted Agent Protocol HTTP message signatures prove the agent before checkout. Cohorts: Mm **Designed.** Protocol support is designed. The flow follows the protocol's published specification, with insimbi on the merchant side. Every check and every settlement is written to the record. **Visa Trusted Agent Protocol.** Designed. HTTP message signatures (RFC 9421) prove the agent before checkout. Lanes: Agent, Merchant edge, Agent key directory, insimbi 1. Agent: Sign the request: Signature-Input and Signature over the authority and path, with created time, nonce and keyid 2. Agent to Merchant edge: Request the page or checkout with the signature headers 3. Merchant edge to Agent key directory: Fetch the public key for the keyid 4. Agent key directory to Merchant edge: Public key 5. Merchant edge: Verify the signature, the domain and path, the time window and the nonce 6. Merchant edge to insimbi: Pay, with the verified agent attached 7. insimbi: Record the agent verification with the payment 8. insimbi to Merchant edge: Result - [All flows](/docs/flows/): Every sequence diagram, linked to its section. - [Integrations](/integrations/#protocols): Every agent protocol and rail we connect. - [MCP tools](/docs/mcp/): insimbi as tools for any MCP client. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Mastercard Agent Pay Registered agents and Agentic Tokens. Cohorts: Mm + Fi **Designed.** Protocol support is designed. The flow follows the protocol's published specification, with insimbi on the merchant side. Every check and every settlement is written to the record. **Mastercard Agent Pay.** Designed. Registered agents and Agentic Tokens. Lanes: Consumer, Agent, Mastercard, Merchant, insimbi 1. Agent to Mastercard: Register and verify the agent 2. Consumer to Mastercard: Set what the agent may buy; an Agentic Token is issued 3. Consumer to Agent: Authenticate, for example with on-device biometrics 4. Agent to Merchant: Pay with the Agentic Token 5. Merchant to insimbi: Authorize 6. insimbi to Mastercard: Authorization through the network, identified as agent-initiated 7. Mastercard to insimbi: Result 8. insimbi to Merchant: Result, written to the record - [All flows](/docs/flows/): Every sequence diagram, linked to its section. - [Integrations](/integrations/#protocols): Every agent protocol and rail we connect. - [MCP tools](/docs/mcp/): insimbi as tools for any MCP client. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Webhooks Events for every movement and every decision. **Designed.** Webhooks, GET /v1/events and the event names below are designed. Access and security events are already written to the audit record; see Core concepts. Every change becomes an event. Read them with GET /v1/events, or receive them at your webhook endpoints. - **Deliveries**: One delivery per event per endpoint. - **Attempts**: Every attempt is kept: status, timing, signing-key version. - **Replays**: Replay any delivery. Replays are linked to the original. _Illustrative example._ ``` { "id": "evt_01J9b", "type": "payment.captured", "schema_version": "2026-10", "data": { "payment_id": "pay_01J9", "ticket_id": "tkt_01J9" } } ``` Every delivery is signed. Retries back off. Each event has an id you can use to deduplicate. **An event, from the change to your endpoint.** Designed. Every change becomes an event. Each delivery is signed, retried with backoff and can be replayed. Lanes: insimbi API and record, Events and deliveries, Your webhook endpoint, Your team or service 1. insimbi API and record: A payment is captured and written to the record 2. insimbi API and record to Events and deliveries: Emit payment.captured with an event id and schema_version 3. Events and deliveries to Your webhook endpoint: Deliver the event, signed. One delivery per event per endpoint. 4. Your webhook endpoint to Events and deliveries: No 2xx in time: the attempt is kept with its status and timing 5. Events and deliveries to Your webhook endpoint: Retry with backoff, signed with the current signing-key version 6. Your webhook endpoint to Events and deliveries: 2xx: delivered 7. Your webhook endpoint: Deduplicate on the event id before acting 8. Your team or service to Events and deliveries: GET /v1/webhooks/{webhook_id}/deliveries/{delivery_id}/attempts 9. Your team or service to Events and deliveries: POST .../replays to replay a delivery. The replay is linked to the original. 10. Your team or service to Events and deliveries: GET /v1/events to read every event with cursor pagination --- # Sandbox Separate credentials, sandbox accounts. Nothing real moves. The sandbox runs at https://sandbox.api.insimbi.xyz with its own credentials. Every account resource there reads environment: sandbox and carries its environment_id, so sandbox data can't be mistaken for live data. - Separate client registration and signing keys - Sandbox organizations, legal entities and merchant accounts - The same token, error and request ID behaviour as the API reference - No real money ## Simulated rails **Designed.** Simulated rails and scenarios are designed. Use them to test rules, mandates and workers before they touch money. - Test cards, bank accounts and stablecoin wallets - Triggerable scenarios: declines, disputes, returns and payout bursts - Cutoff previews and export jobs on synthetic data --- # SDKs OpenAPI first. Generate a client in any language. The OpenAPI contract is the source of truth for the API. Generate a client from it in any language. It covers tokens, discovery, account reads, errors and request IDs. - **OpenAPI**: Request access for the specification, then generate a client with your usual tooling. ## Language SDKs **Designed.** TypeScript, Python and Go SDKs are designed. They will be generated from the same contract, so they won't drift from it. - **TypeScript**: For services and agent frameworks. - **Python**: For data, finance and agent workflows. - **Go**: For high-volume services. _Illustrative example._ ``` import { Insimbi } from "@insimbi/sdk"; const insimbi = new Insimbi({ token: process.env.INSIMBI_TOKEN }); const pay = await insimbi.payments.create( { merchant_account_id, amount: "182.40", currency: "USD", source }, { idempotencyKey: "order-1042" }); const ticket = await insimbi.tickets.get(pay.ticket_id); console.log(ticket.lines); // each line cites its rule ``` --- # Developers One API for your team and your agents. Anything you can do in the dashboard, you can do through the API. Rules are code you can review, diff and roll back. Every payment comes back with its rail, its fees and the rule that chose it. - [Docs](/docs/): Quickstart, concepts, API reference, MCP, webhooks, sandbox, SDKs. - [Quickstart](/docs/quickstart/): From sandbox key to first decision trace. - [Agent payment workers](/workers/): Workers that run rail choice, reconciliation, payouts, disputes and mandates. - [Integrations](/integrations/): Rails, protocols and platforms. ## For engineering and platform leads Your rules are versioned and cited. Every ticket tells you which rule produced each line. _Illustrative example._ ``` curl https://api.insimbi.xyz/v1/tickets/tkt_01J9 \ -H "Authorization: Bearer $TOKEN" # fee lines, each cited to a rule ``` ## Readable by agents - [llms.txt](/llms.txt): An index of this site for language models. - [llms-full.txt](/llms-full.txt): Every page in one file. - [agents.md](/agents.md): Instructions written for agents. Request access: sales@insimbi.net _insimbi is in early access with design partners._ --- # Changelog What changed, and when. ``` 2026-10 insimbi.net: agent payment workers, integrations, developer docs hub 2026-10 insimbi.net: seven product pillars, illustrative use cases, value anatomy, Request access 2026-10 insimbi.net: polish pass: real 404, sitemap, link previews, clickable contact links, sourced origin note 2026-10 insimbi.net: copy rewritten in plain language 2026-10 insimbi.net v2: segment market figures with sources, mobile navigation, full-width layout ``` --- # Pricing Fees you can read before you sign. We will publish our pricing. Every transaction shows its own fees: network, scheme and ours. Nothing is blended. - **Card-present**: on request - **Card-not-present**: on request - **Payouts**: on request - **Platform fee**: on request - **Contract term**: on request - **Volume tiers**: on request **Rates on request. Request access: sales@insimbi.net** ## For payments and finance leaders See what each transaction costs by network, region and rail. Model a rule change before you make it. Your auditors see the same ledger you do. - Effective rate by network, region and rail - Cost-model export Enterprise terms: sales@insimbi.net. --- # Switch Move at your own pace. Roll back any time. There is no big-bang migration. You run insimbi next to your current setup and move traffic one rule at a time. 1. Connect: bring in your current configuration. 2. Mirror: run live traffic through both and compare the cost and outcome of each transaction. 3. Move: shift traffic by rule, one region, card type or percent at a time. Roll back in one step. 4. Own: end the old contract when the numbers say so. To plan a parallel run, write to sales@insimbi.net. --- # Customers Merchants who run their own payments. We publish a customer story only when the customer approves it. Until then, there are no quotes and no numbers here. --- # Company We curate the right transaction, rails and record for every value movement. - **About**: insimbi is a transaction service provider for humans and agents. We curate the right transaction, rails and record for every value movement. - **Contact**: sales@insimbi.net ## Origin > Umuntu ngumuntu ngaBantu. insimbi is isiZulu for iron. Umuntu ngumuntu ngaBantu means a person is a person through other people. We think payments work the same way. A payment only completes when every party does its part. A merchant should get stronger through its network, not more dependent on a middleman. Our ring is drawn as iridium, the most corrosion-resistant metal known. We chose it on purpose: payments should not corrode. Iridium is one of the rarest elements on Earth. South Africa mines about 80% of the world's supply, and the Bushveld Complex holds the largest reserves of the platinum-group metals it comes from. Source: [Royal Society of Chemistry, Periodic Table: Iridium](https://periodic-table.rsc.org/element/77/iridium) · Source: [International Platinum Group Metals Association, Iridium factsheet, March 2026](https://ipa-news.com/assets/pdfs/factsheets/2026-03-iridium-factsheet.pdf) --- # Security What we can show you, and when. Procurement will ask, so the answers will live here. We list a certification, audit or uptime figure only once it is real and audited. ## Trust documents For our security questionnaire, DPA and subprocessor list, write to sales@insimbi.net. --- # Legal Terms and privacy. Our terms, privacy policy and licenses are available on request. Questions: sales@insimbi.net. --- # Status System status. Customers get a live status page. Questions: sales@insimbi.net.