PayID
Overview
A PayID is a unique identifier (also known as an alias) that is linked to a bank account that can be used for instant, secure payments between bank accounts at participating banks. The PayID identifier is typically easier to remember and more convenient to share in comparison to a BSB and account number. A PayID can be an email address, a telephone number, an ABN/ACN/ARBN/ARSN, or an organisation identifier.
PayIDs can only be registered against accounts that are NPP enabled with transfers using PayID therefore should happen almost instantly, most in under a minute if you have used the correct PayID, even between different banks and on weekends and public holidays. In some instances, there may be additional security checks by certain banks that may prevent the transfers being instant.
A single PayID can only be linked to one account at a time, it cannot be shared between financial institutions and cannot be registered to multiple accounts.
PayID Management
This section aims to detail the various PayID types and states as well as highlighting all of the endpoints used to manage PayIDs registered via Shaype.
PayID Types
Any PayID that is registered to an account must only be done so where the PayID being used can be clearly associated to the customer attempting to registered it. For example a phone number or email should have been confirmed via 2 factor authentication (2FA) as being operated by the customer or the business number used has been confirmed as being registered to that business.
| Type | Type Name | Description | Examples |
|---|---|---|---|
| TELEPHONE | Phone number | Consists of a “+” followed by the country code (from 1 to 3 characters) then a “-“ then a number between 1-9 and then any combination of numbers | +61-423765879 |
| Consists of a character string with a maximum length of 256 characters in lower case. This must include the “@” symbol with leading and trailing characters and no white spaces. | [email protected] | ||
| INDIVIDUAL_AUSTRALIAN _BUSINESS | Australian Business Number | Consists of a nine to eleven digit number. This be either the ABN, ACN, ARBN or ARSN depending on the type of legal entity the customer is operating. | 601428737 |
| ORGANISATION | Organisation Identifier | The Identifier must include the company/organisation name and both/either the description of the business/ trade / product / campaign and/or geographic location. | aardvark plumbing mosman nsw snackspotvending 10shelley lvl08 sydney nsw |
Organisation Identifier
This type of PayID is largely unused in the industry as it is not a standard identifier for a business, best practice is to use a AUBN type for PayIDs associated to business accounts.
PayID States
| State | Description |
|---|---|
| ACTIVE | The PayID is registered and is able to receive payments. |
| DISABLED | A PayID can be disabled at any time (e.g. if fraud is suspected). Whilst disabled, the PayID is still linked to the bank account but the PayID cannot be used to make payments to the bank account. |
| PORTABLE | A PayID can be placed in this state if a customer wishes to link their PayID to another account at a different financial institution while still being able to receive payments to the PayID during that time. The customer’s other financial institution will be able to register this PayID within 14 days of being placed in this portable state. If the PayID isn’t registered with this period it will automatically return to an Active state. |
| DEREGISTERED | A PayID cannot receive Payments and is no longer linked to any bank account. A deregistered PayID cannot be reactivated; however, it can be be re-registered again with the same or different account at any point. |
PayID Record Removal
The NPP Addressing Service will automatically remove a PayID record after the record has been in deregistered state for 90 days.
PayID State Model
The below diagram captures the various state transitions of a PayID (provided by NPP).
APIs
PayID Resolution
- PayID resolution API is used to search for a PayID in the NPP Addressing Service to return the associated PayID and linked bank account details. This is also used to provide users a mandatory confirmation step before attempting to make payment using a PayID.
- Endpoint to return the PayID and account details for the provided PayID value.
Client should resolve the payID to allow users who wish to send a payment using PayID that involves displaying the name associated with the PayID. PayID’s can change at any point therefore any attempt to make a payment using PayID should always resolve the PayID.
Client should not expose any of the account details (
accountDetails) on your client facing UI at any point and this information must be treated as strictly confidential. Only the PayID and name (payIdOwnerCommonName) should be visible in the confirmation step before attempting payment.
API Reference:Resolve PayID to bank account
Get PayID details
- Get the PayID details for an account registered. Note, this differs from the Resolve PayID to bank account endpoint as you can only retrieve details of PayID’s if the account belongs to you. You will not get the details of PayID registered externally.
Resolve PayID differences
This differs from the Resolve PayID to bank account endpoint as you can only retrieve the status and statusDetails of PayID’s registered by you.
API Reference: Get PayID details
Check PayID Availability
- Checks if a value is available for PayID registration. If it is not available for registration this indicates it is held against another account. The customer will need to contact the financial institution where the account that it's currently linked resides and either de-register or make portable the PayID to make it available for registration elsewhere.
API Reference: Check PayID availability
Get PayID de-register history
- Endpoint to retrieve the de-registration details for a given PayID.
API Reference:Get PayID de-register history
Update PayID details
- This function allows the registered name against the PayID to be updated as well as value that can be assigned for use as a ‘nickname’ or particular identifier (most useful if an account has multiple PayIDs registered against it).
API Reference: Update PayID details
Update PayID Status
- Allows a previously registered PayID status to be updated. Refer to the PayID state model to understand the possible state transitions.
Deregistered state
A PayID in a DEREGISTERED state cannot have its status updated, the PayID must be registered again for it to be useable.
API Reference: Update PayID status
Get PayIDs by Account ID
- Returns all PayIDs and details associated with a particular customer's account.
API Reference: Get PayIDs by Account ID
Register a PayID
- Allows the registration of a PayID with a particular customer's account.
OwnerName registration
The ownerName that is provided in the registration call must be reflective of the account holder name as this information will be visible and used by customers as a validation check when sending funds from another financial institution.
API Reference: Register PayID
Cash Transfers using PayID
As a PayID can only be registered to an account enabled to accept NPP cash transfers, any transfer using a PayID will only be sent via NPP.
Cash Transfer parameters
When making a Payment to a PayID you must use the the PAY_ID type so that the transaction can be associated with a PayID payment. Using the PayID account details from the Resolve PayID to bank account API and executing a transfer of type ACCOUNT should be avoided.
Recommendation
We recommend resolving the PayID before making a transfer via PAY_ID. There are two main reasons for resolving the PayID before initiating the transfer:
- To verify that the resolved details match those of the intended recipient.
- To ensure the PayID is in an appropriate state to receive funds.
APIs:
UI/UX treatment of cash transfers using PayID
If offering the ability to allow your customers to send cash transfers to external accounts using a PayID you must make sure the following UI/UX behaviour is adhered to in your process.
Prior to any transfer submission being made, you must include a step in your UX that contains a confirmation step to allow users who wish to send a payment using PayID that involves the customer entering the PayID, a lookup being performed to retrieve the PayID details, with only the name associated with the PayID being displayed to the customer for them to confirm this is the party they wish to make payment to.
You must not expose any of the account details (accountDetails) on your customer facing UI at any point and this information must be treated as strictly confidential. Only the PayID (as entered by the customer) and name (payIdOwnerCommonName) can be visible before attempting payment as well as in any transactional details after the payment is made.
PayID association to an account can change at any point therefore every attempt to make a payment using PayID must always have this confirmation step, regardless if the customer has previously made a payment using it.
Updated 5 months ago