Your leadership just asked whether you should be doing agentic payments. Most of the market is still debating the question. You need to know what it took to ship the one system that already answered it.
TL;DR
One production deployment exists today, not a pilot. A cross-border payments provider went from kickoff to a live agentic payments demo in 5 months, covering 40+ countries at launch. Zero hallucinated transactions or model-generated errors followed.
AI-assisted and AI-initiated are different risk categories. Assisted means the model recommends and a human clicks. Initiated means the system completes the transaction, and the safeguard has to live in the architecture, not in someone's judgment.
Safety here comes from architecture, not from trusting the model. No LLM output calls a payment API directly. Every agent output passes through a guardrail layer before it reaches a payment provider.
The delivery pattern is small and fast. Four engineers, five months, a stack built on n8n, Model Context Protocol (MCP), Redis, and PostgreSQL, not a multi-year platform rebuild.
Conversational payments AI: what actually separates AI-initiated from AI-assisted?
Agentic commerce in payments means AI agents complete a transaction themselves, not just recommend one. Conversational payments AI gets pitched as a single category. It isn't.
Assisted means the model recommends and a human clicks to confirm. Initiated means the model completes the transaction itself, no click required. That's the distinction that matters for risk.
AI agent payment processing changes character the moment you cross from assisted to initiated. In assisted flows, a bad recommendation is a UX problem someone can catch or ignore. In initiated flows, a bad output is a transaction that already happened.
The point of control moves from a person's judgment at the moment of approval. It shifts to whatever the system does before the transaction reaches a payment provider.
Dimension | Ai-assisted | AI-initiated |
Who approves | A human, after the model recommends | The system, through a guardrail layer |
Where risk is controlled | Human judgment at the point of click | Architecture, while the transaction executes |
Typical flows | Spend nudges, budgeting suggestions | Transfers, funding, bill pay |
Failure mode | A bad suggestion someone can reject | A transaction that already happened |
Your product already ships some form of assisted AI: a chatbot, a spend nudge, a recommendation engine. What's rare, and what risk teams are starting to ask about directly, is agentic payments where the model initiates the transfer itself. That's a different category of fintech software engineering than a chatbot feature, sometimes called agentic AI banking.
Has anyone actually deployed agentic payments in production?
Yes. We built the system: a cross-border payments provider went from kickoff to a live production demo in 5 months, covering 63+ countries at launch. Zero hallucinated transactions or model-generated errors have been recorded since, and the public case study on the build lays out the numbers in full.
The system handles the full transaction lifecycle, further than the industry’s typical initiated flows: sign-up, KYC, transfers, funding, and support are each initiated by AI agents rather than recommended to a human first. That's what makes it a genuine agentic payments deployment rather than a chatbot layered on top of an existing flow. It's also the only production system of its kind with public numbers.
Mastercard has run public pilots since: PhotonPay in Hong Kong, maib and Moldindconbank in Moldova, Santander in Europe. Each proved a single transaction, not a production system running sign-up through support.
The team behind it built and shipped in five months with four engineers. That timeline matters as much as the safety numbers. It's the difference between a category fintechs can evaluate this year and one they file under "check back in 2028."
How do you stop an LLM from moving money it shouldn't?
The system stops wrong transfers with a guardrail check while the transaction executes.
The system we built starts with an orchestrator that routes each user intent to a specialized agent. KYC runs in the same conversation; identity documents never reach the LLM. Every agent's output then passes through a guardrail layer before it reaches a payment provider. The guardrail layer, not the model, decides whether an action is allowed to execute.
This is where conversational banking earns or loses trust. A model that occasionally hallucinates is expected behavior for any LLM deployment. A model that can move money based on that hallucination is a different risk entirely.
The fix is architectural: keep the model out of the critical path to the payment API. This is the same principle behind most AI enablement work built for regulated systems: the model proposes, the system disposes.
Zero hallucinated transactions across 40+ countries since launch isn't a claim about the model behaving well. It's a claim about the guardrail layer doing its job every time the model didn't.
Is agentic commerce safe for financial transactions today?
Safe enough for the flows it's been proven on. Not safe as a blanket claim across every kind of payment.
Regulators and risk committees increasingly draw the line around AI-initiated transactions specifically, not around AI-assisted recommendations. This system was built with that distinction in mind from the start.
Conversational banking will likely expand past this first use case. Right now it's an emerging category with one production precedent, not an inevitability every fintech needs to plan around this quarter. What it proves is narrower and more useful. AI-initiated transactions can be made safe when the guardrail sits in the system architecture instead of in a person's attention span. Whether that holds for your specific transaction types, currencies, and regulatory footprint is a scoping question, not a given.
What does shipping this actually take?
Four engineers. Five months from kickoff to a live production demo. A stack built on n8n for orchestration, MCP for connecting agents to tools and data, Redis for state, and PostgreSQL as the system of record.
That's a flexible team shipping a full agentic payments system, covering sign-up through support, across 40+ countries, with an audited safety record. Team experience with the guardrail pattern mattered more than headcount. A focused team ships this kind of integration, not relearning KYC and guardrail decisions from scratch.
That's the actual constraint most agentic commerce fintech projects run into. Not whether the technology works. Whether the team building it has shipped the guardrail architecture before.
Key insights
One production precedent exists, not a market trend. 40+ countries, zero hallucinated transactions, five months from kickoff to live demo.
AI-initiated is a different risk category than AI-assisted, and it needs a different architecture, not a bigger prompt.
The guardrail layer, not the model, is what makes agentic payments safe. No LLM output calls a payment API directly.
Shipping this took four engineers and five months, not a platform rebuild. Team experience with the guardrail pattern mattered more than headcount.
Fintechs that get agentic commerce right this year will treat it as an architecture problem from day one. Not a model upgrade. Marek Gajda, who led the team behind the build, put it simply: “Everything happens in one chat. No jumping between dashboards, no filling out forms, no approval steps.”
Authors

Jakub Matuszak
Marketing Specialist at The Software House, focused on B2B tech insights and turning complex topics into actionable guidance for engineering leaders.
