PayTo Service Guide

Overview 

PayTo is an improvement on the existing Direct Debit function, allowing payments to be mandated and completed in real time.

NPPA background video: PayTo - Modern alternative to direct debit

For example, Person A pays for dinner then sends a mandate request with their PayID to the other 5 people. The others can accept and pay immediately. Payments can also be split out over time, allowing regular payback of debts. 

Or, a gym wants to set up recurring payments with a first payment being taken on site to secure the contract. Previously this would involve a DD setup plus initial card payment. PayTo allows all this in one flow. 

PayTo encompasses: 

1. Initiation of Payment Messages generated by third parties, to request payments from a customer’s bank account. Those payment requests are associated with a ‘mandate’ - a customer authorised payment arrangement. 
2. A centralised record for creating, storing and maintaining mandates. The database for this is owned and operated by NPP Australia. 
3. Business rules providing assurance that the payment initiation messages will be handled by the customer’s financial institution. 

Key use case examples

1. Instant Direct Debits. PayTo replaces the slower existing direct debits system. Batched direct debits can be subject to delays of several days – with failed payments a particular frustration. Via PayTo, money is debited, settled and cleared instantly. 
2. Instant payroll and disbursements. No need for large floats of cash sitting awaiting disbursement. Payroll and large supplier payment situations can benefit from instant movement of money. 
3. Control (where authorised) over movement of money between third parties. PayTo allows for the initiator of the transaction and the receiver of the transaction to be different entities. Unlike standard direct debits, a company could instruct funds to be taken from its customer and credit a third-party bank account without ever touching the funds themselves. For custodial services and similar, this means that you can automate transactions between accounts without third party ‘interference’. 
4. Alternative to expensive repeat card transactions. When confirming a regular service for customer, card has previously been the only way to secure a regular payment at the point of selling the service. PayTo allows regular payments to be set up and confirmed on the spot, meaning e.g. subscription sales can be closed reliably in person.

Shaype Capabilities – Initiator Service 

The following capabilities are included in Shaype’s PayTo Initiator Services  

Services 

Orchestration of PayTo related notifications and messaging between our PayTo Initiator clients and the NPP Mandate Management System (MMS). 

JSON APIs that provide RESTful synchronous web services that can be easily consumed by client and/or technology service provider systems, enabling Initiating Parties to:  

• Create PayTo agreements (including obtaining authorisation from the Debtor),
• Amend PayTo agreements (including obtaining authorisation from the Debtor if necessary), 
• Immediately Suspend, Release and Cancel PayTo agreements, and 
• Execute requests for mandated payments to be made (for example an on-demand pull request triggered by the initiator application) 

Operational Management Services 

Shaype’s Operations Team will provide back-office support to client teams. This includes any investigations and disputes raised by clients pertaining to PayTo mandates or mandated payments. 

During onboarding, Shaype works with our clients to ensure that their solution meets the rules and industry codes for Payment Initiators. 

Key Roles and Terms  

A PayTo agreement (mandate) is a record of payment authorisation given by a Debtor customer in favour of an NPP payment to a Creditor account.  

PayTo agreements and PayTo payments involve the following key roles:  

• The Debtor (the Payer account a PayTo payment is made from),  
• The Creditor (the Payee account a PayTo payment is made to), and  
• The Initiating Party (the party that defines the PayTo agreement payment terms e.g. a merchant).  
• The Payment Initiator sends the initiation request for each PayTo Payment to the Debtor on behalf of the Initiating Party. The Payment Initiator can be a payments service provider or a financial institution.  
• The Debtor and Creditor Account Servicers are the financial institutions (FIs) that maintain the NPP enabled accounts/PayIDs named in the PayTo agreement. 
• MPS User is a comprehensive term used to refer to any party other than the agreement Debtor. 
• The Initiating Party, Creditor, and Payment Initiators are all “MPS Users”.  
• Using the term “MPS User” allows for the broad range of use cases possible via PayTo.

Key Scenarios  

This section provides readers with an overview of the following key PayTo Payment Initiator and Initiating Party scenarios:  

• View a PayTo agreement  
• Creating an Authorised PayTo agreement  
  • All Payment Initiator clients can support the scenario where the Initiating Party is a third party to a PayTo agreement, and the Creditor Account Servicer is another organisation (i.e. the NPP payment is received by the other organisation, not the client).  
• PayTo Payments (where the Payment Initiator is third party)
• PayTo Payments (where the Payment Initiator is also Creditor Account Servicer)

Creating a PayTo agreement  

The client is responsible for enabling their customers to create PayTo agreements as the Initiating Party. 

Clients may implement features to support the creation of PayTo agreements by the Initiating Party in mobile or online applications, and/or via non-digital channels (such as a form). 

1. The Initiating Party provides the details for a new PayTo agreement to Shaype
2. Shaype validates the agreement: the service checks that the Debtor bank is NPP reachable, and supports the PayTo scheme 
   1. Shaype’s response to the client includes whether the agreement is valid, plus 
   2. it includes other “enrichment” data such as resolving the PayID (if one is used). 
3. Shaype then generates and sends a Mandate Creation Request message to the NPP PayTo Mandate Management Service.
   1. Mandate Creation Request messages:  must have a priority (attended or unattended), must have a frequency (ad-hoc, annual, monthly etc), must have an agreement type (Fixed, Variable, Usage, Balloon, Usage+, Variable+, Fixed+), may have a business expiry date/time (an expiry date/time is not mandatory). 
4. The MMS creates a PayTo agreement record, and sends a notification to the Debtor Account Servicer.  
5. The Debtor Account Servicer receives notification that a PayTo agreement has been created where their customer’s account (or PayID) is named as the Debtor, and authorisation is required.  

Sometime later... 

6. The Debtor customer can view the agreement terms, and authorise (or decline) the agreement. 

7. The Debtor Account Servicer sends the Debtor authorisation response to the MMS. 

8. The MMS updates their PayTo agreement record with the Debtor’s response. 

9. Shaype receives notification from the MMS that the agreement has been authorised (or not).

10. Shaype forwards the PayTo agreement authorisation response notification to the client.

Key PayTo Agreement Data Fields 

NPPA has defined the PayTo agreement data fields as follows:

PayTo Agreement Payment Terms 

NPPA has defined the PayTo agreement payment terms fields as:

Notes

Payment Amount Type = VARIABLE and USAGE_BASED are currently only available with Frequency = ADHOC

Types of PayTo Agreements 

NPPA has defined PayTo Agreement types as:

View details of a PayTo agreement  

The client is responsible for ensuring that the Initiating Party is able to view their PayTo agreements.  

• NPPA does not prescribe how PayTo agreement details are presented to the Initiating Party.  
• The Initiating Party could view their PayTo agreements in the client’s mobile or online app, and/or via non-digital channels (e.g. for non-digitally enabled customers).  
• The Initiating Party must be able to view all their PayTo agreements. 
• At any time, the Payment Initiator (client) systems must be able to request the latest details from the MMS for the Initiating Party’s agreements (by sending a query to Shaype). 
• Shaype provides the client with the latest PayTo agreement records and pending requests from the MMS.

Modifying a PayTo agreement 

Mandate Status Change  

Shaype provides the ability to change the status of a Mandate by forwarding a change made by the Initiating Party to the MMS. 

• Cancel 
• Suspend 
• Release (un-suspend) 

NOTE: The Initiating Party can only release an agreement if they were the one that suspended the agreement. 

Amend Mandate  

Shaype provides clients with a Mandate Amendment API which must be used to send amendments made by the Initiating Party to the MMS. Shaype forwards the amendment to the MMS. 

The change message must contain either unilateral changes or bilateral changes (not both)

• Bilateral change: Changing the payment terms is a bilateral change (requiring Debtor authorisation). If the change is declined by the Debtor (or it expires) the current agreement terms remain active and the change is archived. 
• Unilateral change: Changing the Initiating Party name, agreement description and/or Creditor account/PayID are unilateral changes. 

See table below for the types of operations possible as amends:

🚧

Character Set Encoding - To comply with industry standard it is required to use Unicode character set

encoded with UTF-8. Any messages containing non-compliant characters will result in a reject mandate.

Recall a pending Mandate Amendment Request  

The Initiating Party can recall a pending Mandate Amendment Authorisation Request (i.e. if the amendment is bilateral). Shaype sends the recall request to the MMS.

Migrating a PayTo agreement 

The PayTo MMS from NPP supports the ability to migrate a Direct Debit agreement to a PayTo agreement. Currently Shaype does not support this out-of-the-box, instead we recommend cancelling the Direct Debit and creating a new PayTo agreement with the same terms. This also allows a customer the opportunity to review the terms, given the faster processing of payments with PayTo, and ensure the agreement still fits their needs.  

PayTo Payments (Initiator flow) 

For a PayTo agreement where the client is the Payment Initiator, and either an adhoc PayTo Payment is made or a scheduled PayTo payment is due: 

1. The Payment Initiator (client) sends a Mandate Payment Initiation Request to Shaype 
   1. This step is for Ad Hoc payments only – payments based on a schedule will be processed automatically by Shaype 
2. Shaype confirms the request is consistent with the PayTo agreement in the MMS. 
3. Shaype sends the Mandate PIR to the Debtor’s bank via the NPP BI. 
4. The Debtor bank responds to valid Mandate PIRs by sending an NPP payment to the Creditor account nominated in the Mandate PIR. 
5. Shaype receives notification of the response to the Mandate PIR from the NPP. 
6. The client receives the response to the Mandate PIR (settled, pending or rejected). 
7. The Creditor customer can view the PayTo payment funds in their account.

Overall flow

1. Trigger payment initiation. This is either:
   1. automatic for fixed frequency payments, or
   2. through the Make Adhoc Payment endpoint for Adhoc (anytime) payments
2. The message to send payment is sent to the core PayTo ecosystem (NPPA PAG)
3. The Debtor party receives the request and responds with an outcome
4. Shaype returns this outcome to the Initiator client in the Make Adhoc Payment endpoint response. Most of the time it is 'final'. It may also show a 'non-final' status.
5. If the status is non-final, the client can call Get Payment instruction status by Mandate ID and Payment Instruction ID for updates to fetch an update using the payment instruction ID. This is only available for 15 days from the instruction date after which point the payment instruction will be archived by the MMS.
   1. Client can also use Search payments instructions by Mandate ID - especially for fixed frequency payments
   2. Client can also wait for a Mandate Payment Event notification (see below)

Status transitions

Status detail

PayTo Notifications Services 

Shaype receives notifications from the MMS for any action made to a PayTo agreement for which the client is the Payment Initiator. Examples of MMS notifications are: 

• PayTo agreement authorisation responses (accepted, declined, expired) 
• PayTo agreement status changes made by the Debtor (suspended, released, cancelled). 

It is up to the client as to if/how they present PayTo Notifications to their customers, including: 

• How the amended data is made available to the customer, and 
• If the customer is informed of mandate suspension/unsuspension, and cancellation by the Debtor 

Notifications may be presented to your customers via SMS, email or in-app push notifications.

Notifications about Payer actions

Notifications about automatic MMS actions

Notifications about payments

• The Mandate Payment Event notification includes payment instruction ID, Mandate ID and final status.
• It is sent for all payment instructions when the final status is known
• After triggering the payment initiation the client can check the Get Payment instruction status by Mandate ID and Payment Instruction ID endpoint if the final status notification is not received.

Check industry coverage

As of May 2023 PayTo is in a phase of partial roll-out across the industry. This means many institutions won't yet offer mandate authorisation capability to their customers. Shaype provides a service to check support for PayTo by BSB. It is recommended that you check this for your target debtor customer before sending a mandate creation request. See 'Check if BSB supports PayTo' endpoint below.

List of endpoints and key flows

Create Mandate and receive authorisation outcome

• Check if BSB supports PayTo (GET/v1/payto/supported-bsbs/{bsbNumber})
• Create Mandate (POST/v1/payto/initiator/mandates) >
• Receive notification: MandateCreateConfirmed
  • (Receive notification: MandateCreateDeclined)

Amend mandate details (eg Account details)

• Amend Mandate by Initiator (PUT/v1/payto/initiator/mandates/{mandateId})

Amend mandate payment terms (eg frequency, amount)

• Amend Mandate payment terms (PATCH/v1/payto/initiator/mandates/{mandateId}/payment_terms)

Suspend / unsuspend (release) a mandate

• Suspend Mandate by Initiator (PATCH/v1/payto/initiator/mandates/{mandateId}/suspend)
• Release Mandate by Initiator (PATCH/v1/payto/initiator/mandates/{mandateId}/release)

Cancel a mandate

• Cancel Mandate by initiator (PATCH/v1/payto/initiator/mandates/{mandateId}/cancel)

Initiate Payment

(note – AdHoc payments only – scheduled payments will be initiated automatically by Shaype

• Make Adhoc Payment (POST/v1/payto/payments/adhoc)
• Receive notification of NPP payment (https://developer.shaype.com/reference/notifynotificationusingpost - Transaction Event object - will contain mandate ID and payment instruction ID if a mandate-related payment
• See https://developer.shaype.com/page/build-in-progress-payto-transaction-status-updates#notificationsfor details of update to Mandate Payment Event object