Paystack is payment infrastructure an autonomous agent can call directly — to pay another agent, a vendor, or a person — under spending caps enforced at authorization, into custody that keeps the payment reversible, with an audit record that says which agent did what.
Agent-to-agent payments are transactions in which an autonomous AI agent pays another agent, a vendor, or a person without a human approving each transfer. They need three things an ordinary payment rail does not provide: a spending authority bound to the agent's identity and enforced at authorization, a custody window in which a mistaken payment can be reversed before funds leave, and an immutable record of which agent paid whom under which task. Paystack provides all three, and exposes them over the Model Context Protocol so an agent can call them as tools.
None of these are theoretical. They are the four questions every security review asks before an agent is allowed near production money, and a card number answers none of them.
Issuing a virtual card to an agent gives it a bearer credential with a monthly limit and a merchant-category filter. That is the entire control surface. It cannot express "this agent may pay this counterparty, for this task, up to this amount, and I can take it back for six hours."
Caps are per agent — per transaction, per day, and per month — enforced at authorization, not reconciled after.
On most rails the money is gone the moment the call succeeds. If the agent was wrong — hallucinated an invoice, double-paid, picked the wrong vendor — your remedy is a dispute process measured in weeks.
Funds land in custody first. Release is a separate, explicit act, so a mistaken payment is cancelled rather than clawed back.
A row in a payments dashboard says an amount moved. It does not say which agent, under which task, with which reasoning, against which approval. When finance asks, the answer is a log-diving expedition.
Every movement carries the initiating agent identity, the task correlation, and an immutable audit record.
When an agent misbehaves at 3am, rotating an API key stops future calls but does nothing about the eleven payments already in flight.
One operator switch halts all pending movement across every agent, immediately, without a deploy.
This is what escrow was invented for, and it is why agent commerce needs custody rather than a faster rail. Neither side can enforce a contract against the other, so the money has to do the enforcing.
Your agent gets a task and a spending authority — say $2,000 for the month, restricted to compute and data vendors. The authority lives with Paystack, not in the agent's prompt, so it cannot be talked out of it.
The counterparty may be another autonomous agent, a vendor API, or a human business. Terms are agreed; the buying agent calls Paystack to fund the obligation.
The money leaves the buyer's balance and is held. The selling agent can verify the funds exist and begin work — which is the actual purpose of escrow between parties that do not trust each other and cannot sue each other.
On confirmed delivery the buyer releases and the seller is paid — instantly over RTP, or by ACH. If delivery fails or the buyer reverses within the window, the funds return. No chargeback process, no dispute queue.
Paystack ships a Model Context Protocol server, so an agent discovers and calls payment tools directly — no wrapper functions to write, no tool schemas to hand-maintain, no prompt describing your internal payments API.
Granting MCP access is not the same as granting spending authority. Every tool call is evaluated against that agent’s caps and blocklists before money moves, so the safe default is an agent that can see the tools and cannot overspend.
{
"mcpServers": {
"paystack": {
"url": "https://api.getpaystack.com/mcp",
"headers": { "Authorization": "Bearer ${PAYSTACK_API_KEY}" }
}
}
}
// The agent then calls tools directly:
// initiate_escrow_payout — fund an obligation into custody
// check_payout_status — settlement timeline + reversibility window
// release_escrow — settle to the counterparty
// pause_escrow — hold before settlement
// cancel_escrow — reverse before settlement
// quote_fees — preview cost, no side effects
// explain_routing — preview rail selection, no side effects
// get_spending_limit — check remaining spend authority
//
// Every mutating call requires a non-empty reasoningLog and is
// evaluated against the agent's caps before any money moves.
// A call over cap fails; it does not warn.After-the-fact alerting is not a control — it is a notification that you have already lost the money. Each of these sits inside the authorization path.
Per-transaction, per-day, and per-month ceilings bound to the agent identity, plus velocity limits and cooldowns — all evaluated inside the authorization path. Agents get the tightest default limits of any actor type. An agent cannot exceed its cap by retrying or by racing another instance of itself.
Constrain an agent to a set of known vendors, or block a specific recipient globally. A payment to an unlisted counterparty fails closed rather than succeeding and alerting you afterward.
A custody window between authorization and settlement. During it the payment is real to your workflow — the agent can proceed — but the funds have not left, so a supervising human or a verifying agent can still reverse it at zero cost.
Below a threshold the agent settles autonomously. Above it, the payment enters custody and waits for approval. The boundary is configuration, so raising an agent's autonomy is a policy change rather than a code change.
Every mutating tool call must carry a non-empty reasoning log — the agent has to say why it is moving the money, and that statement is recorded alongside the authorization. Combined with append-only records of every release, reversal, and denial, this is the artifact an auditor or a customer's security review actually asks for.
Halts all pending movement across every workspace and agent at once. It is the control you want to already exist on the night you need it.
There is no AI surcharge and no percentage fee on custodial escrow. An agent paying by ACH pays $0.75. Paying instantly, 0.95% capped at $10.00. The controls, the custody window, and the audit record are part of the platform, not an upsell — which also means you can put an agent behind an existing integration without renegotiating anything.
Agent-to-agent payments are transactions where an autonomous AI agent pays another agent, a vendor, or a person without a human approving each transfer. They require controls a normal payment rail does not provide: a spending authority bound to the agent identity, a settlement window in which a mistaken payment can be reversed, and an audit record proving which agent moved what and why.
By separating authorization from settlement. The agent authorizes a payment into a custody wallet — funds leave the payer and are held — and settlement to the recipient is a distinct, later act. During that window the payment is real enough for the workflow to proceed but reversible at no cost. Combined with per-agent per-transaction, daily, and monthly caps enforced at authorization time, counterparty allowlists, and an operator kill switch, this bounds the worst case to an amount you chose in advance.
Yes. Paystack enforces per-transaction, daily, and monthly spending caps per agent identity, plus velocity limits and cooldowns, inside the authorization path, so an agent cannot exceed its limit by retrying, running in parallel, or racing another copy of itself. A call over cap fails closed. Limits are changed by configuration, not by redeploying the agent.
A virtual card is a bearer credential with a monthly limit and a merchant-category filter. It cannot express a per-task budget, a counterparty allowlist, a reversal window, or an approval threshold, and it produces no record of which agent acted under which task. It also settles immediately, so a wrong payment becomes a dispute rather than a cancellation.
The Model Context Protocol is an open standard for exposing tools to LLM-based agents. Paystack ships an MCP server so an agent connects and calls payment tools directly — create a payment, release it, reverse it, check remaining spend authority — with no glue code. Every tool call is evaluated against that agent's caps and blocklists before money moves, so MCP access is not the same as unbounded spending authority.
Before settlement, yes — that is what the custody window is for, and reversal costs nothing. After settlement it depends on the rail: an ACH debit can be returned, while RTP and FedNow credits are irrevocable. This is precisely why controls sit before the send rather than after it.
The same as everything else on the rate card — there is no surcharge for AI-initiated transactions and no percentage fee on custodial escrow. ACH is $0.75 flat, same-day ACH $1.50, instant payouts 0.95% capped at $10.00, cards interchange + 2.00% + $0.30, on top of a fixed $250/month platform fee.
Every authorization, release, reversal, and denial is written to an append-only audit record carrying the initiating agent identity, the task correlation ID you supplied, the counterparty, the amount, and the caps in force at the time. It is queryable per agent and exportable, so the answer to "what did this agent do in March" is a query rather than an investigation.
What it does, what it would pay for, and what the worst case looks like if it gets one wrong. We will tell you which controls bound that, and what is still your problem.