ZILLQ agentic payments: the platform and 2027 direction
ZILLQ is an independent agentic-payment system for AI agents, built around explicit, inspectable authority: who allowed an agent to spend, within which limits, and what happened afterward. Its European payment and identity sandbox makes the underlying mechanisms available for examination today.
Current stage: an independently built platform foundation demonstrated with synthetic funds and identity credentials. The 2027 milestones below are proposed goals; live regulated integrations, adoption and commercial results remain to be established.
AI payment infrastructure for agentic commerce
A payment-capable agent introduces a question that a checkout button alone does not answer: which decisions did the owner delegate, and which still need a person? A useful system must preserve that answer when the agent changes its proposal, a supplier changes the price, or a request is retried.
ZILLQ’s thesis is that explicit mandates, trusted identity context, payment controls and inspectable evidence belong together. The resulting boundary should remain understandable even when the model, interface or payment provider changes. This is a product thesis, not a claim that every integration is already supported.
The European context matters because payment consent, SCA, wallet identity and API authorization have distinct roles. Standards such as OAuth Rich Authorization Requests offer building blocks; turning them into a usable flow still requires enforcement, clear interfaces and reliable payment outcomes.
What can be examined today
| Area | Public starting point | Evaluation question |
|---|---|---|
| Agent mandate mechanisms | Mandate layer and API introduction | Which terms are enforced, where is the boundary, and what happens when a request exceeds it? |
| Payment mechanics | Synthetic consent, transfers and payment records | Can an evaluator follow a payment from permission through its recorded outcome? |
| Identity foundation | OAuth2/OpenID Connect and EUDI wallet emulation | How are owner, agent and credential evidence connected to a specific request? |
| Review material | 16 downloadable mandate test cases | Which checks pass in the evaluated build, which fail, and which remain untested? |
The test pack states expected behavior. It is not a report that the platform passes all 16 cases. The public sandbox uses synthetic accounts and funds; wallet emulation does not establish national-wallet certification or production interoperability.
That separation gives an evaluator a concrete starting point: inspect the mechanisms, record actual results against a named build, and identify the missing work. Website availability and a successful login are useful checks, but they do not establish payment-system assurance.
A focused first use case: bounded business purchasing
A candidate starting point is an agent preparing small office-supply purchases from approved suppliers. The owner defines a budget, a per-order cap and an expiry; the agent prepares a proposal; the service checks final payment details; exceptions return to the owner.
This is a useful evaluation scenario because it exposes the hard parts without requiring unlimited autonomous spending: changed delivery charges, recipient substitution, concurrent orders, revoked authority and an unknown provider outcome. The same review also gives product and operations teams meaningful work to assess.
Demand for this workflow is a hypothesis to validate. The next step is an inbound design-partner conversation tied to an actual purchasing process, an agreed success criterion and a recorded evaluation. Broader consumer or merchant use cases should follow evidence of need and integration fit.
A proposed path through 2027
- Make evaluation repeatable.Identify the build under review, reproduce the core mandate and payment journeys, publish supported behavior and keep failures visible. Use the test pack to organize evidence.
- Validate one workflow with users.Determine whether bounded purchasing solves a real problem. Measure successful task completion, the reasons people need help and whether they return to evaluate another scenario.
- Prove one integration boundary.Choose a relevant provider or wallet environment, document the authorization contract, and test identity binding, revocation, retries and outcome reconciliation. Define responsibilities with the participating parties.
- Establish the basis for commercial deployment.Use observed demand, integration results, operating requirements and a clear commercial arrangement to decide the next deployment scope. Production payment services require the appropriate legal, provider and operational arrangements.
The sequence is more important than a calendar promise. By the end of 2027, the meaningful evidence would be repeatable technical results, relevant returning evaluators, validated integration work and substantiated commercial interest. None of those outcomes is asserted as achieved by this brief.
What an investor should ask to see
- Technical evidence: the evaluated build, supported interfaces, observed test results, known limitations and unresolved controls.
- User evidence: who the workflow serves, completed evaluation tasks, repeat use and concrete feedback. Separate synthetic activity from external adoption.
- Integration evidence: provider and wallet compatibility demonstrated in a named environment, with clear boundaries around certification and regulated activity.
- Commercial evidence: verified enquiries, agreed evaluations and any later contracts or revenue. A roadmap or demo should not be counted as a customer.
- Execution evidence: ownership of the components, dependencies, maintenance work and a prioritized plan for the next milestone.
These records connect the platform’s current capabilities to the next investment and development decisions. An evaluator can inspect the mechanisms, assess the unmet need and judge the proposed milestones on that basis.
Start with a use case and an evaluation
Investors, payment providers, wallet teams and potential design partners can start with the public materials, then discuss the mechanisms and evidence most relevant to their decision. Include the workflow you care about and the next milestone you would want to assess.
Discuss ZILLQ’s agentic-payment platform →
About the builder · Platform overview · Download the test pack