PayTo and the NPP: An Operator Guide to Australia's A2A Rails

The New Payments Platform (NPP) is Australia’s real-time account-to-account rail, and PayTo is the service built on top of it that lets a business pull funds from a customer’s bank account under a digital, payer-authorised agreement. If you are an operator deciding how to collect recurring or variable A2A payments in Australia — or planning a move off the legacy BECS direct-entry system — PayTo is the rail you have to understand, and it does not behave like the direct debit it is meant to replace.

This is a guide for operators standing up or supporting PayTo collections, not a consumer explainer of “what is PayTo” and not a generic recurring-payments strategy piece. It deliberately separates five layers that vendor decks and internal runbooks tend to blur: (a) the scheme and rail mechanics defined by the Reserve Bank of Australia (RBA), the NPP scheme, and Australian Payments Plus (AP+); (b) what the public rulebook and framework documents actually say; (c) the variation your PSP or sponsoring bank introduces; (d) the implications that fall on you as the merchant/operator; and (e) the operator guidance PaymentBrief layers on top (the checklists and decision matrix). Keeping those layers distinct is what separates a PayTo program that behaves predictably from one where every mandate edge case becomes an escalation.

Direct answer

The NPP is Australia’s real-time A2A rail — 24/7, ISO 20022, settled in central bank funds. PayTo is the NPP’s Mandated Payments Service (MPS): a payer authorises a digital payment agreement (a mandate) that is held centrally in the Mandate Management Service (MMS), and an authorised initiator (a merchant or biller, through a sponsoring PSP or bank) then pulls real-time NPP payments under that agreement. Against BECS direct debit the contrast is structural: real-time clearing instead of batch direct entry, a centrally-held digital mandate the payer can see and control instead of a biller-held authorisation, and near-immediate feedback instead of next-day returns. Settlement is real-time, line-by-line, via the NPP and the RBA’s Fast Settlement Service. Industry has signalled a direction to migrate A2A off BECS toward the NPP, but the timeline is under ongoing RBA/industry consultation — AusPayNet removed the June 2030 target end-date in December 2025. For operators, PayTo is a mandate-lifecycle and integration program, and adoption is still expanding across participants.

Australia’s A2A rail map: NPP, PayTo, BECS, cards, BPAY

Australia runs several payment systems in parallel, and an operator’s first job is to place PayTo correctly among them. The NPP is the real-time A2A infrastructure; PayTo is an overlay service that uses it for mandated pulls; BECS is the legacy batch direct-entry system PayTo is positioned to replace for recurring A2A; cards and BPAY serve different jobs. For the broader country context — currency, regulators, method mix — see Australia.

The rows that matter for this guide are the first three. BPAY and cards are included only so the map is complete; do not treat PayTo as a card substitute or a BPAY substitute — it is the A2A-mandate rail.

What the NPP is

The NPP is open-access infrastructure for fast payments, launched in February 2018 and developed through industry collaboration (the World Bank’s case study documents this design). AP+ describes it as a distributed switch that routes and exchanges ISO 20022 financial messages between participants, “always open for business, 24 hours a day, 365 days of the year.”

Three properties drive everything downstream for operators:

• Real-time settlement in central bank funds. The RBA’s Fast Settlement Service (FSS), a service of RITS (the Reserve Bank Information and Transfer System), provides “real-time line-by-line settlement of individual New Payments Platform (NPP) payments in ESA funds on a 24/7 basis.” There is no netting and no batching — each payment settles finally and irrevocably between institutions across their Exchange Settlement Accounts at the Reserve Bank. That finality is the rail’s defining trait and the reason there is no scheme reversal.
• Simple addressing via PayID. The NPP includes an addressing service, PayID, that lets a payment be addressed to a registered phone number, email, ABN, or organisational identifier instead of a BSB and account number. PayTo agreements can be set up against a PayID or a BSB + account number.
• Overlay services. The NPP infrastructure is built to be used by independently developed “overlay” services. Osko (a convenience payment service) is one overlay; PayTo (the Mandated Payments Service) is another. Operators integrate with an overlay and its rules, not with the raw switch.

What PayTo is and how it uses NPP

PayTo is the consumer/market brand for the NPP’s Mandated Payments Service (MPS) — “Mandated Payments Service” was the working name during development; PayTo is the customer-facing brand. It adds a capability the base NPP did not have: authorised third-party initiation of payments. Instead of the payer pushing each payment, the payer authorises a standing payment agreement, and an authorised initiator pulls payments under it.

The mechanics, from public AP+ and NPP material:

1. A payment agreement (mandate) is created. A merchant or biller (the payee), through its sponsoring PSP or bank, proposes a digital payment agreement that carries the terms — the payer, the amount or amount rules, frequency, and purpose.
2. It is held centrally. The agreement is stored in the Mandate Management Service (MMS), the central, secure database of PayTo agreements operated by NPP Australia (part of AP+). This is the structural break from BECS: the mandate is a centrally-held digital record, not a biller-held form.
3. The payer authorises it in their banking app. AP+ states PayTo agreements are “authorised and managed in your online banking, giving you more visibility and control over your money.” The payer can see the terms and, once authorised, payments are “processed according to the terms you’ve agreed to.”
4. The initiator pulls real-time NPP payments under it. Each resulting payment is an ordinary NPP payment — real-time, settled via the FSS.

Exact API call names, the precise mandate state machine, and field-level rules live in the NPP API Framework and PayTo Service Overview (public, redacted) and in the gated NPP Product Rules and developer sandbox. Describe the concept as above and confirm specifics against the PayTo specs or your PSP.

PayTo vs BECS Direct Debit

This is the comparison that matters most. PayTo is positioned as the modern replacement for the direct-debit half of BECS, but it is not a like-for-like swap — the authorisation model, timing, and feedback loop all change. For the broader direct-debit landscape across ACH, SEPA, Bacs and eGIRO, see direct debit payments explained; this guide does not restate it.

The migration framing belongs here, and it needs care. The RBA notes industry announced an intention in 2023 to decommission BECS with 2030 as a target end date, and the RBA has run a risk assessment on the proposed decommissioning, treating the NPP as the strategic A2A replacement. But this is an industry direction under ongoing consultation, not a fixed committed date: in December 2025 AusPayNet removed the June 2030 target end-date, citing the need for a shared A2A vision, the availability and adoption of alternatives, and a more complex risk environment — while stating it “remains the intention of BECS Members to transition away from BECS in favour of modern alternatives like the NPP.” A shared vision and roadmap were flagged for 2026. The operator takeaway: plan for the direction (A2A moving to the NPP), do not build to a specific shut-off year, and confirm the current published position with the RBA and AusPayNet. PayTo itself is also positioned to absorb existing direct debit arrangements — public material describes migrating DDRs to PayTo without re-authorisation, with a payer review window; treat the exact migration mechanics as PSP/rules detail to confirm.

PayTo mandate / payment agreement lifecycle

A PayTo agreement moves through a lifecycle, and your integration has to handle each transition rather than assume a static “active mandate.” The states below describe the concept; the exact state names and transitions are defined in the PayTo rules and API Framework — caveat against the current specs and your PSP.

The MMS is the source of truth: when an agreement is paused, amended, or cancelled, the holding bank notifies the MMS, which notifies the payee’s institution. Your system must treat the MMS-propagated state — surfaced via your PSP — as authoritative, not your own cached copy.

Initiation, authorization, amendment, pause, cancellation, and revocation

Who can do what, and where, is the part operators most often get wrong because it differs from BECS:

• Authorisation is the payer’s, in their banking app. Unlike a BECS DDR the biller holds, the payer authorises the PayTo agreement in their own online/mobile banking. You cannot self-authorise a mandate; you propose terms and wait.
• Initiation is the initiator’s, within the terms. Once active, the initiator (you, via your PSP) triggers each NPP payment under the agreement — within the agreed amount/frequency rules. Stepping outside the terms is a rules and reputational problem, not just a technical one.
• Amendment can come from either side, but re-authorisation may be required. If you change the terms (e.g. a price increase), expect the agreement to require the payer to re-authorise; do not assume a silent variation. Read the current agreement state before each cycle.
• Pause and cancel are largely the payer’s lever — and the bank’s. The payer can pause or cancel in their app at any time; banks can also pause an agreement to investigate suspected fraud. While paused, payment instructions are not processed. Your operations must handle “payment rejected because the mandate is not currently active” as a normal, expected outcome — not an exception.

The operational discipline: drive your initiation logic off the live agreement state from the MMS (via your PSP), and build for payer-initiated pause/cancel as a routine event, because on PayTo the payer holds far more control than they ever did on a BECS DDR.

Settlement and reconciliation considerations

Settlement is the clean part: each PayTo payment is an NPP payment, settled real-time and line-by-line in ESA funds via the FSS, with no netting or batching. There is no daily settlement file to wait on the way BECS works.

That inverts the reconciliation model. On BECS you reconcile against batch totals and a returns file on a known cycle; matching is batch-shaped. On PayTo, value moves transfer-by-transfer in real time, so reconciliation becomes per-payment: each debit is its own settlement event with its own status, and you match individual payments to individual obligations as they happen. This is the same A2A-versus-batch shift that bites operators moving off any batch rail — see the PSP reconciliation failure runbook for how to structure breaks and escalation when per-payment matching fails. Two practical points: confirm exactly what real-time confirmation your PSP surfaces (and how it carries the agreement and payment references you reconcile against), and design for a continuous reconciliation stream rather than an end-of-day batch job.

Failure, return, and exception handling

PayTo failures are real-time and per-payment, which is an improvement over waiting for a BECS dishonour file — but the categories must be handled explicitly. Do not invent a precise code taxonomy; the authoritative response/error codes live in the PayTo rules and API Framework — describe the categories and confirm the exact codes against the specs or your PSP. The categories that matter operationally:

• Insufficient funds. The payer’s account cannot cover the debit. On a real-time rail you learn this immediately rather than next cycle — decide your retry policy within the agreement terms.
• Mandate not active. The agreement is paused, cancelled, expired, or not yet authorised. Expect this as a routine state, not an error; check the live agreement state before initiating.
• Limit or rule breach. The payment exceeds the agreed amount/frequency or a payer/bank limit. Treat as a terms problem — initiating outside the agreement is the root cause.
• Other declines / exceptions. Account-level blocks, fraud holds, technical timeouts. These need investigation through your PSP/bank using the payment and agreement references, not through a scheme dispute portal.

The operator job is to map your PSP’s surfaced response categories to your own retry, dunning, and customer-comms logic — and to capture the agreement ID and payment reference at the moment of failure so any enquiry has what it needs.

Fraud, mandate-risk, and customer-dispute considerations

Like Mexico’s SPEI and other A2A rails, PayTo settles finally — there is no card-style chargeback a payer can pull back through a scheme. That moves the risk and the controls to different places than operators trained on cards expect.

• APP fraud is the rail-level risk. On any irrevocable push/pull A2A rail, authorised push payment (APP) fraud — a payer socially engineered into authorising something — is the dominant fraud vector, because the payment is genuinely authorised and settles finally. PayTo’s structural control against unauthorised pulls is the mandate authorisation itself: the payer must authorise the agreement in their own banking app, and can see, pause, and cancel it. That is a stronger consent record than a biller-held DDR, but it is a consent control, not a clawback.
• No chargeback; disputes run through the agreement and the banks. A payer who disputes a PayTo payment does not invoke a card scheme. The remedy lives in the agreement terms and is handled between the payer’s and payee’s banks (and, beyond that, the complaints/ombudsman framework). Confirm the exact error-correction and unauthorised-payment handling against the current PayTo rules and your PSP — do not promise customers a chargeback-style reversal.
• Your controls are mostly preventive. Because settled payments don’t reverse on the rail, controls sit before initiation: only initiate within the authorised terms, treat amended terms as requiring fresh authorisation, and monitor for agreements that look anomalous.

Operator decision matrix

This is PaymentBrief guidance, not an AP+ or RBA rule. PayTo is a strong fit for recurring or variable A2A collection where real-time confirmation and payer-visible mandates add value; it is a weak fit where you need card-style buyer protection or universal reach today. For how PayTo sits against other recurring rails strategically, see recurring payments rails compared; this matrix is scoped to PayTo’s rail fit, not general recurring strategy.

PSP / bank / partner due-diligence checklist

Before launching PayTo through a PSP or sponsoring bank, confirm (PaymentBrief guidance):

• Sponsor / initiator model. Are you an authorised payment initiator in your own right, or initiating through a sponsor’s connection? Who holds the participant relationship, and under what authorisation?
• Participant coverage. Which payer banks does your PSP actually reach for PayTo today? Coverage is expanding but not universal — get the current supported-institution position in writing, not a “PayTo is live in Australia” generality.
• Mandate APIs and lifecycle. How does the PSP expose agreement creation, authorisation status, amendment, pause, cancel, and the MMS-propagated state changes? Can you drive initiation off live agreement state?
• Return / response handling. What failure categories does the PSP surface, how fast, and carrying which references? How do they map to your retry and dunning logic?
• Settlement and confirmation. What real-time confirmation do you get per payment, and how does it reconcile to the agreement and payment references? Funds-settlement timing to your account.
• DDR migration path. If migrating a BECS book, exactly how does the PSP handle DDR-to-PayTo migration, the payer review window, and re-authorisation edge cases?
• Dispute / error handling. What is the documented path for unauthorised or disputed payments, given there is no chargeback? Confirm against current PayTo rules.

Monitoring checklist

What to monitor and escalate in production (PaymentBrief guidance):

• Mandate state changes — payer-initiated pauses/cancels and bank-initiated pauses; spikes can indicate a UX, billing, or fraud-investigation issue.
• Payment failure mix — insufficient funds vs mandate-not-active vs limit breach; the mix tells you whether the problem is collections timing, lifecycle handling, or terms.
• Initiation-outside-terms attempts — any payment rejected for breaching agreed amount/frequency is a logic defect to fix, not a transient error.
• Reconciliation break rate — unmatched per-payment confirmations; on a real-time rail these should clear continuously, not pile up to an end-of-day batch.
• Authorisation conversion — proposed agreements that never reach authorised; a leak here is lost revenue and a sign-up UX problem.
• DDR migration outcomes — for a BECS migration, track payer cancellations within the review window and failed migrations.

Common mistakes

• Assuming BECS has a fixed shut-off date. It does not — the migration is an industry direction under consultation, and AusPayNet removed the June 2030 target in December 2025. Building a hard cutover plan to a specific year is a planning error.
• Treating PayTo like a card. There is no scheme chargeback. Customer support promising a card-style reversal on a PayTo payment is setting up a complaint it cannot resolve.
• Assuming every bank supports PayTo. Coverage is expanding across NPP participants but varies by institution — confirm reach for your payer base before promising it.
• Conflating a PayTo mandate with a BECS DDR. The PayTo agreement is a centrally-held digital record the payer controls in-app, not a biller-held authorisation. Designing your flows as if it were a DDR misses the lifecycle and the payer-control model.
• Ignoring mandate lifecycle states. Initiating against a paused, amended, or cancelled agreement causes avoidable rejections. Drive initiation off live MMS-propagated state, via your PSP.
• Inventing a return-code taxonomy. The authoritative response/error codes live in the PayTo rules; handle the categories and confirm exact codes against the specs or your PSP rather than hard-coding a guessed list.

Related references

• SPEI Mexico: An Operator Guide to the Payment Rail — the local-rails sibling guide; same operator-guide structure, A2A irrevocability framing
• Real-Time Payment Rails Comparison Matrix — where the NPP sits among Pix, UPI, SPEI, and other domestic real-time rails
• Recurring Payments Rails Compared — how PayTo sits against cards-on-file and other recurring options, strategically
• Direct Debit Payments Explained: ACH, SEPA, Bacs, eGIRO — the direct-debit landscape PayTo’s BECS replacement fits into
• Australia market overview — country-level payment landscape, regulators, and method mix

Scope note

• Five layers, kept separate. (a) Scheme/rail mechanics are defined by the RBA (the Fast Settlement Service, real-time line-by-line settlement, finality), the NPP scheme, and Australian Payments Plus / NPP Australia (the NPP itself, PayTo as the Mandated Payments Service, the Mandate Management Service, PayID). (b) Public rulebook/framework detail — the PayTo Service Overview and NPP API Framework (public, redacted) — defines the agreement lifecycle, fields, and codes; this guide describes the concepts and points to those specs. (c) PSP/bank implementation varies — participant coverage, mandate APIs, surfaced failure categories, confirmation timing, and DDR migration handling are partner choices. (d) Merchant/operator implications (no chargeback; mandate-state-driven initiation; per-payment reconciliation) follow from the rail design. (e) The decision matrix, due-diligence checklist, monitoring checklist, and common mistakes are PaymentBrief operator guidance.
• BECS timeline is a direction under consultation, not a fixed date. The RBA attributes a 2023 industry intention to decommission BECS with 2030 as a target, and runs a risk-assessment/oversight program; AusPayNet removed the June 2030 target end-date in December 2025 pending a clearer A2A roadmap (expected 2026). No specific shut-off year is asserted here as settled — confirm the current published RBA/AusPayNet position.
• PayTo adoption is expanding, not universal or mature. PayTo has rolled out progressively across NPP participants; coverage varies by institution. Adoption is framed as expanding, and specific point-in-time volume/coverage figures are not restated as fixed facts.
• Gated content not relied on. The unredacted NPP Product Rules and the developer sandbox are gated; this guide is scoped to public sources (RBA, AP+/NPP Australia, AusPayNet, the World Bank case study) and the public redacted framework material. No gated detail is claimed.
• Not verified / deliberately not asserted. The exact PayTo mandate state names and transitions, and the precise response/error code taxonomy, live in the PayTo rules and API Framework — described here as categories and caveated, not fabricated. Exact participant-level coverage, per-payment timing experienced by end customers, and DDR-migration mechanics are PSP/rules detail to confirm with your provider.