PayTo authorisation
The business presents a digital agreement, the customer reviews it through participating online banking, and the agreement reaches a supported status before an eligible payment is initiated.
Neutral method comparison
PayTo vs direct debit for Australian businesses
PayTo uses a digital agreement managed through participating online banking, while BECS direct debit uses a direct debit authority and generally operates through established batch-processing arrangements. The suitable method depends on customer reach, authorisation experience, timing, visibility, exception handling, cost and operational requirements. Neither method is universally right for every business.
At a glance
How do PayTo and direct debit differ?
| Area | PayTo | BECS direct debit |
|---|---|---|
| Customer authorisation | Digital agreement reviewed through participating online banking | Direct debit request or authority provided under the relevant process |
| Payment initiation | Business requests an eligible payment under a usable agreement | Business or provider submits payment instructions under the direct-debit arrangement |
| Processing model | Digital, status-led flow with bank and provider support conditions | Established direct-entry and batch-processing arrangements |
| Customer visibility | Agreement terms and lifecycle may be visible through banking | Visibility and notice depend on the authority, bank and provider process |
| Payment status | Agreement and payment status can be available in the configured workflow | Processing, dishonour and return information follows the relevant timetable |
| Reconciliation | Agreement/payment references, status and reports can support matching | Provider reports, batch files and return information support matching |
| Bank coverage | Depends on customer, account, bank and supported PayTo flow | Depends on customer account eligibility and the direct-debit process |
| Best fit | Businesses valuing digital authorisation and payment-state visibility | Businesses with established batch processes where immediate status is not essential |
Customer and payment journeys
How authorisation and processing work
BECS direct debit
The customer gives a direct-debit request or authority, and the business or provider submits payment instructions. Processing, dishonours and returns follow the relevant BECS/provider timetable.
Timing and confirmation are not the same as fund availability
Compare initiation, processing, confirmation, fund availability and return or dishonour risk separately. PayTo may provide faster status information where the supported flow allows it, but no method guarantees instant completion in every case.
Operational comparison
What happens when an exception occurs?
Agreement rejection
A PayTo agreement may be declined or remain pending before the business can request a payment.
Payment failure or return
Insufficient funds, invalid details, customer cancellation, bank review, timeout or provider processing can require follow-up.
Retry and communication
Define whether and when a retry is permitted, how the customer is contacted and how the exception is recorded.
Customer control and agreement changes
Compare how customers view, amend, pause or cancel each arrangement, how bank-account changes are handled and what notices or new authorities are required. Confirm current operational rules before promising a specific path.
Scenario-based choice
When might each method fit?
PayTo may suit
Businesses seeking digital customer authorisation, agreement visibility, supported one-off or repeat bank payments and status-led reconciliation.
Direct debit may remain appropriate
Businesses with established authorities, broad existing processes, low-cost batch workflows or use cases where immediate status is not essential.
Use both carefully
A primary and fallback approach can be considered only when the current product and operating process support it. Do not assume automatic fallback.
Test before migrating
Check payer coverage, payment value, schedule, exception handling, customer communications, reconciliation and commercial terms.
Frequently asked questions
Questions about PayTo and direct debit
Is PayTo the same as direct debit?
No. PayTo uses a digital agreement reviewed through participating online banking. BECS direct debit uses a direct-debit authority and established processing arrangements.
Does PayTo replace BECS direct debit?
PayTo is an alternative for some workflows, not a universal replacement. Suitability depends on customer and bank coverage, timing, operational requirements and commercial terms.
Which method processes faster?
Timing varies by method, bank, provider and exception. Compare initiation, confirmation, fund availability and return risk rather than assuming a universal processing time.
Can customers cancel both methods?
Customers may have cancellation or amendment rights under each arrangement, but the exact process depends on the agreement, bank and provider rules.
What happens when a payment fails?
The business should handle the relevant failed, rejected, pending, returned or dishonoured state, communicate with the customer and follow its approved retry process.
Can a business use both?
A business can evaluate a controlled primary and fallback approach, but it should confirm that the current product and operating process support the intended manual or automated flow.
Which method is better for recurring payments?
Either may fit depending on customer authorisation, coverage, schedule, visibility, exceptions, reconciliation and cost. Compare the real recurring workflow rather than choosing by label.
What should a business test before migrating?
Test payer-bank coverage, payment schedules, values, customer communications, agreement changes, failures, returns, reconciliation, support and current commercial terms.
Further reading
Review the methods in context
Choose the method that fits the operating model
Bring the collection schedule, customer authorisation process and exception workflow to a comparison discussion.