Create payment experiences
Create one-time payments, invoices, subscriptions and other payment experiences that can be completed by people or AI agents.
Create the payment experience that matches how your business charges. You can collect a one-time payment, send an invoice, charge customers on a recurring basis or create other payment experiences for your product.
The same payment can be completed through the experience appropriate for the payer. A person can use a hosted checkout, while an AI agent can use a programmatic payment URL. Both belong to the same payment, so your reference, reconciliation and resulting balance remain consistent regardless of who pays.
Choose the payment experience
Start with what you are trying to collect rather than how the payer will complete it.
A one-time payment works well when the amount is already known and you simply need to collect it. Invoices add a formal billing lifecycle, while subscriptions are designed for recurring charges. Sessions and per-request payments are useful when payment is tied more closely to ongoing usage.
You do not need separate versions of these experiences for people and AI agents. Mitu handles the appropriate payment flow for the payer.
Before you begin
You need a Mitu account, a server-side API key and something you want to collect payment for. You should also have a stable reference from your own system, such as an order ID, invoice number, booking reference or another identifier that lets you reconcile the payment later.
Keep your merchant API key on your server. Customers and AI agents do not need access to it in order to complete a payment.
Choose what you are collecting
Decide which payment experience matches the transaction you are creating. For a single order, booking or service fee, create a one-time payment. If you need formal billing with line items and a due date, create an invoice. For recurring access, create a subscription.
The payment experience should reflect the business relationship you already have with the customer. Do not create separate payment types simply because one customer might pay directly while another delegates the payment to an AI agent.
For this guide, we will start with a one-time payment and then cover where invoices, subscriptions and other experiences fit.
Create a one-time payment
Create a payment link for the amount you want to collect and include a reference that maps the payment back to your own system.
Use reference for an identifier your application already understands. This gives your backend a reliable way to associate the completed payment with the order, booking, invoice or other record it belongs to.
Use metadata for additional information that is useful to your integration, but do not store secrets or sensitive customer information there.
Learn more about Payment experiences.
Use the appropriate payment URL
A payment can provide separate entry points for human and agent payers.
Give the checkout URL to a person and the agent URL to an AI agent. Both entry points belong to the same underlying payment, so you do not need to decide which type of payer will complete it when the payment is created.
You can present the checkout URL through your website, customer portal, email, SMS, WhatsApp or another customer channel. The agent URL can be passed directly to an AI agent that needs to complete the payment programmatically.
Let the payer complete the payment
When a person opens the checkout URL, they receive a hosted payment experience where they can review the payment and complete it using the methods available to them. Your application does not need to build or maintain this checkout interface.
When an AI agent receives the agent URL, Mitu handles the programmatic payment flow and the supported agent payment protocols required to complete the transaction. Your backend does not need separate x402 or MPP implementations.
Regardless of which entry point is used, the result is the same payment associated with the reference you provided when it was created.
Learn more about Agent payments.
Reconcile the payment
Use your reference to associate the completed payment with the corresponding record in your own system. If the payment was created with reference: "ORDER-8841", your backend can use that same value when the payment completes to find and update the order.
This keeps reconciliation independent of who completed the payment. Your application does not need separate logic for a payment made by a person and one made by an AI agent.
Do not mark a record as paid based only on a browser redirect, the state of a checkout page or a result reported by an AI client. Use a verified payment event or retrieve the payment state from the API.
Create invoices when you need formal billing
Use an invoice when you need more than a simple payment request. Invoices are designed for billing that includes line items, customer information, due dates and a lifecycle your application can track.
For example, you might create an invoice for a monthly design engagement containing a retainer and additional work as separate line items. The invoice can then be sent to the customer and tracked until payment is completed.
A payable invoice can support both human and agent payment experiences, so you do not need to create a separate invoice simply because an AI agent may complete the payment on the customer’s behalf.
Learn more about Invoices.
Create subscriptions for recurring payments
Use subscriptions when a customer should be charged repeatedly for ongoing access to a product or service. Define the plan and its billing schedule, then subscribe the customer to that plan.
A subscription manages the recurring billing relationship rather than representing a single payment. Each billing period can then be tracked as part of the subscription lifecycle without your application creating an unrelated one-time payment every cycle.
Keep plan configuration, billing intervals, subscription states and recurring payment behaviour in the dedicated subscription documentation.
Learn more about Subscriptions.
Use sessions for ongoing usage
Use a prepaid session when the payer should fund an amount that can be used across an ongoing interaction rather than completing a separate payment for every action.
This can be useful for metered or long-running workflows where many small paid actions may happen during the same session. The payer funds the session and the available amount can then be used as the interaction continues.
Sessions are a more specialised payment model than one-time charges, invoices or subscriptions, so use them when the payment pattern genuinely depends on ongoing usage.
Learn more about Payment experiences.
Use per-request payments for API usage
Use per-request payments when payment is tied directly to requests against an API operation. This is useful when you want AI agents to pay for individual calls to an API capability rather than paying through a standalone checkout or invoice.
If your main goal is to monetise an API for AI agents, use the dedicated API monetisation guide rather than treating per-request payments as a general checkout flow.
Continue with Sell your API to AI agents or Accept payments from agents.
Track payment activity
Configure webhooks so your backend receives payment events and can keep your own records up to date. Use the reference associated with the payment to determine which order, invoice, booking or other business record should be updated.
Your webhook handling should be independent of whether the payer was a person or an AI agent. The payment experience may differ for the payer, but your backend can reconcile the resulting payment through the same event flow.
Settle your funds
Payments you receive become part of your Mitu balance. From there, you can settle funds to a supported bank account or withdraw them to an onchain address.
How a payment was created or who completed it does not change how your business settles the resulting funds. A payment completed through hosted checkout and one completed by an AI agent can ultimately become part of the same balance available for settlement.
Learn more about Settlement.
One payment infrastructure for different payer experiences
Your product does not need separate payment systems for people and AI agents. Create the payment experience that matches what your business is charging for, then give each payer the entry point designed for them.
People can complete payments through hosted experiences, while AI agents can complete them programmatically. Your application continues to work with the same payment, reference and reconciliation process regardless of which payer experience was used.
This also means you can introduce agent payments into an existing billing flow without rebuilding the underlying order, invoice or subscription logic around AI agents.
Keep payment state in your backend
Treat verified payment events and API state as the source of truth for payment completion. Browser redirects, checkout screens and AI client responses are useful for the payer experience, but they should not be the mechanism your backend uses to decide whether money was received.
Use stable references from your own system and process webhook events idempotently so repeated delivery does not cause the same payment to be applied twice. Keep the detailed webhook signing, retry and event contracts in the dedicated Webhooks documentation.
Learn more about Webhooks.