PayTo explained: a practical guide for merchants to implement it safely

If cards are “transaction-by-transaction,” PayTo is “permission-first.” PayTo is built around payment agreements that customers can authorise (and later view, pause or cancel) inside their banking app. That’s a feature, not a constraint. It means you’re not only implementing a payment method; you’re implementing a consent and control experience. 

Why it matters: When something goes wrong (disputes, confusion, unauthorised activity), the question has always been “did the right person agree to the right payment”. With PayTo, there is now the real-time ability to mutually answer “was the agreement created and managed correctly?” 

Australia’s real‑time payments infrastructure is now well established. The New Payments Platform (NPP) facilitates billions of dollars in payments each day, and PayTo is increasingly being used for structured merchant payments rather than experimentation. 

Industry reporting indicates PayTo has surpassed ~$3 billion in annualised volume, with an average transaction size of around $600, a clear signal that it’s being used for higher‑value, permission‑based payments such as education fees, subscriptions and billing. At the same time, PayTo still represents a small share of overall NPP volume, which is typical for a newer overlay that’s still standardising controls and experiences across banks. 

For merchants, this puts PayTo in an important phase: 

• The rail is proven 
• Use cases are solid 
• Expectations around responsibility are rising 

This is where implementation detail matters most, particularly around controls for repeat payments and how businesses ensure they are driven by the correct user who created and authenticated the agreement in the first place. 

One of the emerging best‑practice responses to this is stronger, phishing‑resistant authentication bound to the agreement creation. While most PayTo implementations rely on traditional authentication methods, Azupay introduced passkeys (cryptographic credentials tied to a specific device and use) to raise the bar on phishing‑resistant authentication during repeat journeys from a payer across our network.

In practice, this does two things for merchants: 

• It significantly reduces the risk of agreement creation being triggered through stolen credentials or social engineering 
• It creates a much clearer evidence trail that the right person, on the right device, explicitly initiated every payment 

As PayTo adoption grows, controls like this are becoming less “nice to have” and more foundational to safe scale. 

When teams run into trouble with PayTo, the root cause usually falls into one of these buckets: 

a) Unclear consent (the biggest one)

• Agreement descriptions that read like internal shorthand 
• “Bundled consent” where customers don’t realise they’re authorising an ongoing debit ability 
• Missing or confusing maximum amounts / frequency cues 

Simple rule: Your agreement must make sense to a customer who is scanning it in a bank app in under 10 seconds. 

 b) Trying to use PayTo like a card rail without necessary workflows and controls 

PayTo is incredibly flexible, but it was not natively designed to mimic every card pattern so careful design of user experience, risk management, settlement flows and reporting are needed to suit many uses cases. 

Challenges tend to emerge when PayTo is implemented without adapting those patterns, particularly in: 

• Highly variable, ad‑hoc ecommerce patterns with little relationship context 
• “Funding” style flows that look and feel like account top-ups 
• Scenarios where payer expectation is not “I’m agreeing to future debits” 

These are not invalid use cases, in fact, many are high-value and actively growing. But they demand clear intent signaling, appropriate controls, and well-defined lifecycle handling to work effectively, safely and at scale. 

Industry discussions have reinforced that when PayTo issues occur, they are typically driven by implementation choices and control gaps, not by the underlying PayTo infrastructure itself. 

c) Weak lifecycle operations

PayTo isn’t “set and forget.” Agreement lifecycle is where operational maturity shows up: 

• Handling pauses/cancellations quickly and correctly 
• Managing amendments (amount changes, schedule changes) cleanly 
• Monitoring patterns that look “off” before customers complain

d) Treating PayTo as “just an API” 

A safe PayTo rollout is cross‑functional: 

• Finance (reconciliation, cashflow, settlement expectations) 
• Ops (exceptions, failed payments, customer queries) 
• CX/Support (scripts, education, dispute handling) 
• Product/Engineering (flows, logging, audit history) 
• Risk/Compliance (controls, monitoring, escalation paths) 

If PayTo sits only in the engineering backlog, you’ll feel it later through escalations and brand risk. 

Phase 1: Build it right (before you launch) 

Think of this as your PayTo “safety checklist.” 

Design the agreement like a product, not a form 

Your agreement should clearly communicate: 

• Merchant name as customers recognise it 
• What the payment is for, clearly explained during setup and consistent with the banking experience 
• Amount logic (fixed/ variable /capped) 
• Frequency and when it starts 
• How to stop it (pause/ cancel reminder) 

Best practice: If your agreement is variable, set a sensible cap and explain it in plain language. 

Make payer intent unmistakable 

A good test: 

Would a customer clearly understand what they’ve authorised if they encountered the agreement again out of context? 

If not, simplify. 

Authentication matters here as much as wording. Strong implementations increasingly combine: 

• Clear agreement language 
• Explicit customer action 
• Phishing‑resistant customer authentication (such as passkeys) for the merchant to control connection between the person authenticating the agreement in their bank with the same person returning in future payment flows 

This pairing reduces ambiguity and protects both the merchant and the customer if an agreement, or related payments are later questioned. 

Build your evidence trail (quietly, but properly) 

Even if you never need it, your internal records should support: 

• What the customer saw at authorisation 
• When and how consent occurred 
• Any amendments and the customer’s acknowledgement (where relevant) 
• Any cancellations and effective dates 
• Evidence of the same person making repeat payments 

This isn’t about over‑engineering, it’s about being able to clearly show what happened if questions are ever raised. 

Plan your bank variability strategy  

Consumer experiences can vary by institution (notifications, limits, flows). Factor that in: 

• Test across major payer banks 
• Expect different behaviours at the edges 
• Make your customer messaging resilient (“If you don’t see the request immediately…”) 

Phase 2: Run it safely (after you launch) 

This is what separates “enabled” from “operational.” 

Monitor what matters 

You want visibility on: 

• Authorisation success rates (and drop-off reasons) 
• Payment success/failure patterns 
• Spikes in cancellations (a leading indicator of confusion) 
• Unusual usage clusters (risk signal) 

Treat cancellations as sacred 

If a customer cancels in their bank app, your internal systems and your customer experience must respect it immediately, both technically and operationally.  

This is where trust is built (or lost). And where PayTo offers major enhancement versus existing payment methods where you only discover payment methods are cancelled when you next try to collect payment. 

Equip support teams with two scripts 

Support needs: 

• A “what is PayTo?” explainer in plain English 
• A “how do I manage my agreement?” guide (pause/cancel basics) 

If support teams sound uncertain, customers assume the payment method is risky. 

Phase 3: Improve with real feedback 

After 30-60-90 days, review: 

• Which use cases are the smoothest 
• Where customer confusion appears 
• Which banks or journeys create friction 
• What operational workload you didn’t anticipate 

Then iterate; PayTo is infrastructure, and infrastructure improves through cycles. 

As PayTo matures, the partner decision is less about “who can connect me” and more about “who can help me run this safely, clearly and at scale.” 

The most useful questions are the ones that test how a partner supports real users, real operations, and real systems, as much as the initial integration. 

Here are the questions worth asking: 

a) User experience and consent design 

• Do you provide out‑of‑the‑box consent and payment UI components, or are merchants expected to design everything themselves? 
• How do you keep those experiences aligned with best‑practice PayTo design as the market and bank experiences evolve? 
• What support do you offer to ensure agreement language is clear, customer‑readable, and defensible, not just technically valid? 

 b) Enterprise enablement and system fit

• Do you provide integration patterns that align to common, real‑world payment use cases? 
• Can you support current‑state connectivity methods alongside an API‑first future, without forcing re‑architecture? 
• How do you help merchants manage reconciliation, reporting and treasury impacts of PayTo alongside other payment methods? 

c) Operational ownership and lifecycle maturity 

• What responsibility do you take for ongoing agreement lifecycle operations (amendments, pauses, cancellations)? 
• What tools, data or guidance do you provide to help operations and CX teams explain PayTo clearly and confidently? 
• When issues arise, how easily can teams access the evidence and context needed to understand what happened? 

 d) Ecosystem alignment and industry engagement

• How do you stay aligned with changes in PayTo scheme expectations and industry guidance as they evolve? 
• What role do you play in representing merchant and operational perspectives within the broader payments ecosystem? 
• How are ecosystem changes translated into practical safeguards or improvements for merchants, rather than adding complexity or burden? 

A strong PayTo partner enables access to the rail, but more importantly, they stay close to the ecosystem, translate change into clarity, and take responsibility for helping merchants operate safely as expectations evolve. 

From Azupay’s perspective, PayTo has always been about merchant‑grade enablement, as much as it’s about infrastructure.

That’s why controls like Azupay Passkeys exist and is recommended at the foundation layer, not as an add‑on. By using device‑based, cryptographic authentication for sensitive actions like agreement creation and payment initiation, Azupay reduces reliance on shared secrets and one‑time codes that are increasingly targeted by fraud and social engineering. 

It’s one example of a broader philosophy: 

• Design for real‑world failure modes 
• Reduce ambiguity before it appears 
• Build controls into the flow, not around it 

As PayTo moves from early adoption into mainstream merchant usage, that kind of operational discipline is what separates “enabled” from “safe.” 

A safe PayTo rollout requires clarity and discipline, and not a 40‑page governance pack:

• Clear customer consent 
• A use case that fits the model 
• Lifecycle operations that work in the real world 
• A partner that can support the “run” phase, not just the “build” phase 

PayTo is powerful. Implemented well, it’s also one of the most trust‑friendly payment experiences available, because customers can actively see and control what they’ve authorised.