The short answer

Indian pilots have been announced, but the reported NPCI registry is not a verified universal launch. Before considering an agent-led purchase, separate three things: who is acting, what you authorized and what actually happened.

An AI assistant that finds a product is useful. An assistant that spends your money needs a much more precise instruction. The question is no longer just whether it picked a good deal, but whether it had permission to place that exact order.

India's reported plans for an AI-agent registry bring that distinction into focus. Alongside payment-industry work outside India, they point toward shopping services that can act for customers under defined permissions. They do not establish that every UPI user can switch on autonomous shopping today.

Can AI agents make UPI payments now?

There have been announced Indian pilots, but the newer registry proposal should not be treated as a universal public launch. On 10 September 2026, Reuters reported that NPCI was developing a registry to verify and monitor payment agents as part of a planned Unified Agentic Protocol. The report relied on three unnamed sources and said NPCI had not responded to its request for comment. Read the Reuters report.

That leaves a practical access question: does your particular app, bank and merchant support the service, under documented terms? An industry announcement cannot answer it for every account. As of this article's fact-check date, we have not verified a public activation date or complete support list for the reported registry initiative.

The earlier pilot matters

Razorpay's October 2025 announcement described work with NPCI and OpenAI on a pilot for payments inside ChatGPT. It named Bigbasket among the initial merchants and described UPI Circle and UPI Reserve Pay as underlying innovations. The release's body is dated 9 October; its webpage header shows 30 October. Neither date is a new September 2026 launch. Razorpay's pilot announcement.

This history matters when judging headlines. A pilot demonstrates a narrower stage of development than broad availability; a later registry proposal addresses a different piece of the system. Neither should be used to promise immediate access to an unsupported customer.

What are agentic payments?

Agentic payments are transactions that software agents help initiate or execute on a user's behalf. The degree of delegation can vary: a person may approve a specific checkout, or authorize a tightly bounded task in advance.

Google's explanation of its Agent Payments Protocol, or AP2, distinguishes purchases made with the user present from delegated tasks. It describes signed records of instructions and purchase details as evidence of authorization. That is a useful way to understand the concept, not evidence that NPCI's reported protocol uses AP2. Google's AP2 explanation.

A hypothetical example makes the difference clearer:

  • Assistance: find a suitable printer cartridge and show the options.
  • Approved checkout: prepare one order, then let the customer approve its final price and seller.
  • Bounded delegation: reorder a specified cartridge from an approved seller within a budget and time window.

The third instruction should not silently permit a different model, a subscription or a second order. Those changes need their own decision.

Purchase review flow

Select a step to explore the prepare-only studio example. This is a way to understand the checks, not an NPCI specification or a payment activation guide.

Purchase review, step by stepIllustrative workflow, not a live payment service

Define the request

Step 1 of 4

Start with a precise purchase request. Let the agent prepare options without giving it permission to spend.

Exact itemQuantityApproved seller
Illustrative studio example

A design studio needs one printer cartridge with the correct product code from a supplier it already approves.

Stop and review: The proposed item is a substitute, its compatibility is unclear or the seller changes.

Set permission

Step 2 of 4

Define the budget, purchase window and limits separately from the agent's identity. An identified agent is not automatically authorized to make an order.

Total costTime windowOne order only
Illustrative studio example

The studio records its chosen budget including taxes and delivery. A changed quantity or a subscription needs a separate decision.

Stop and review: The final total exceeds the budget, the permission expires or an earlier order already exists.

Review the order

Step 3 of 4

During a prepare-only trial, a person reviews the final order and completes checkout. Confirm the seller, full price and delivery details before proceeding.

Human approvalFinal priceDelivery address
Illustrative studio example

The studio manager checks the prepared cartridge order before using the provider's official checkout and authorization screens.

Stop and review: An unexpected fee, changed address or new payment destination appears.

Match the receipt

Step 4 of 4

Keep the approved order, payment-provider reference and merchant confirmation together. A payment result and an order result need to agree.

Approved orderProvider referenceMerchant confirmation
Illustrative studio example

The studio matches the cartridge order to its receipt. If the payment result is uncertain, it checks the status before considering another attempt.

Stop and review: The payment and order disagree, or a timeout leaves the result uncertain.

What would an AI-agent registry solve?

Think of identity as one check in a longer purchase process. Knowing which agent submitted a request helps establish who is acting. It does not, by itself, show that the customer wanted the item or that a merchant fulfilled the order.

For evaluating a service, keep three questions separate:

  1. Identity: Which agent and operator are responsible for the request?
  2. Authority: What purchase did the user allow, and within which limits?
  3. Outcome: Was the payment completed, and is there a matching order and receipt?

These are reader-facing evaluation questions, not a description of an unpublished NPCI technical specification. A provider should be able to explain each part without asking customers to rely on a vague claim that its agent is trusted.

The global picture: Visa, Mastercard and Ant International

On 10 September 2026, Ant International, Mastercard and Visa announced collaboration on a Know-Your-Agent, or KYA, interoperability framework. Their stated aim is to make agent identification easier across networks while retaining each network's own verification and decision processes. The announcement highlights operator traceability, certification requirements and ongoing monitoring. Official joint announcement.

The effort builds on Visa's Trusted Agent Protocol, Mastercard Verifiable Intent and Ant International's Agentic Mobile Protocol. Collaboration is not the same as a finished, universally supported checkout standard.

For US businesses, the relevant next conversation is with their payment processor: which agent-led transactions are supported, and what records and controls are required? For Indian businesses, ask the equivalent questions of the payment provider and banking partners. A global card-network announcement should not be read as permission to automate a UPI account, and Indian pilot access should not be assumed to apply in the United States.

A purchase-permission worksheet for small businesses

The following is UseAIVisora's proposed evaluation worksheet. It is not an official payment limit, a production implementation or a guarantee against fraud.

Imagine a small Indian design studio wants help replenishing printer supplies. Start with a prepare-only trial: the agent builds a proposed order, while a person completes checkout. A US studio could use the same review pattern with a separate local budget.

Hypothetical office-supply order: define permission before considering payment automation
ControlExample ruleReason to stop
ItemOne cartridge with an exact printer-compatible product codeSubstitute item, unclear compatibility or changed quantity
SellerOne supplier already approved by the studioNew seller or changed payment destination
TotalIndia example: INR 1,500; independent US example: USD 40; include taxes and deliveryFinal payable amount exceeds the chosen budget
TimingOne order during a stated purchase windowPermission expired or an earlier order already exists
ReviewHuman approval of the final order during the trialSubscription, unexpected fee or altered delivery address
EvidenceKeep the approved order, provider reference and merchant confirmationPayment and order status disagree

The example amounts are independent budgets, not exchange-rate equivalents or UPI rules. A low budget also does not make a transaction harmless: repeated mistakes can add up, and address or account information can be sensitive regardless of the price.

Before testing any payment-capable service, ask what happens when a permission is revoked while an order is in progress. The answer should distinguish stopping future action from cancelling an already completed purchase.

Test failure handling before convenience

Our suggested acceptance test is deliberately unglamorous. Using a provider-approved sandbox or a prepare-only workflow, check whether the system stops when the price increases, the seller changes or a request is submitted twice. Ask how it handles an uncertain payment result instead of assuming that a timeout means nothing happened.

The current AP2 specification separates checkout and payment mandates and describes proof that an agent is authorized to pay for a particular checkout. That distinction reinforces why a business should ask for transaction-specific evidence rather than just an agent-generated explanation. AP2 specification.

We have not tested these scenarios against a live UPI agent. They are questions to take to a provider before giving software spending authority.

Where is the business opportunity?

Our analysis is that smaller teams can start with purchase preparation and approval workflows, without trying to become a payment network. A useful first service might turn an approved supply request into a comparison, route it to a manager and match the resulting receipt to the order.

Possible customers include agencies ordering equipment, small retailers purchasing routine supplies and operations teams reviewing repeated expenses. These are potential buyer groups to interview, not evidence of established demand or guaranteed revenue.

A practical discovery exercise is to ask a business for a redacted example of a delayed or incorrect order. Identify the failure, show how an approval screen or record check would catch it, and measure review time and exception rates during an agreed trial. Only consider payment execution after the provider's supported integration, access requirements and responsibilities are understood.

The broader service model is covered in our AI business ideas guide. For a consumer-agent perspective on action approval, see our Meta Muse explainer. Neither article is proof that a particular payment integration is available.

What should buyers check before enabling an agent?

Use the provider's official setup and payment-authorization screens. Do not paste a UPI PIN, OTP, banking password or session token into a chatbot or hand it to someone offering to activate agent payments.

Ask to see the exact spending scope, a way to revoke permission, transaction notifications and a clear support route. Keep sensitive information out of shared logs, and retain only the records needed for the task under an appropriate access and retention policy.

Responsibility also needs an answer. Reuters' registry report identifies liability for incorrect or unauthorized payments as an unresolved issue. Do not assume that agent registration guarantees reimbursement. Reuters reporting.

This article explains technology and evaluation questions; it is not legal or financial advice. For a disputed transaction, use the relevant bank or payment provider's official reporting process promptly.

What happens next?

Watch for official NPCI documentation, named participating services, supported-account details and clear rules for authorization, revocation and complaints. Until those are available for the service you intend to use, treat broad launch claims cautiously.

The useful near-term goal is a purchase process that can show what was requested, what was approved and what actually happened. An agent that cannot make those distinctions easy to inspect is not ready to handle your business's money.