Validate Payments

POST 
/v1/payments/validate

Required States: ACTIVE

In order to validate a payment successfully, the following criteria must be met:

• The party must be ACTIVE
• The debtor account must be ACTIVE
• The appropriate counterparty details
• The payment amount must be within the party's available balance
• A valid financial institution identifier must be provided.

Validate payment details validates the request and ensures basic criteria are met before the payment is initiated. The operation will return a payment status report with the status of the payment request.

This endpoint facilitates financial transactions using the ISO 20022 standard, which ensures interoperability and standardized communication. This is achieved with $.paymentInformation[0] serving as the base entry point for the ISO 20022 envelope.

The endpoint supports various payment types, including BPAY, DES, and NPP payments and scheduled payments. Each of these variants, requiring specific data elements for validation. The ISO 20022 standard is used to capture details such as the payment method and requested execution date.

By using the ISO 20022 standard, the REST endpoint structures financial messages in a consistent and well-defined manner. This allows for easier processing, validation, and exchange of payment information with other systems adhering to the standard. The following sections outline the input parameters and how they are utilised for each payment type.

BPAY Payments
For BPAY payments, the payment request will be validated to ensure the counterparty, available balance, etc. are all valid values.

JSON Path	Example	Description (BPAY Payment)
$.paymentInformation[0]	...	Alias: Payment Information. Contains details for a single payment instruction. This will be referred to as payInfo.
$.paymentInformation[0].creditTransferTransactionInformation[0]	...	Alias: Credit Transfer Transaction. Contains the specifics of the financial transaction (amount, identifiers). This will be referred to as transferInfo.
transferInfo.paymentIdentification.instructionIdentification	31790028-6a3b-447e-a947-7c1c0cf0b1aa	Unique identifier assigned by the initiating party to the payment instruction, not directly relevant to BPAY but useful for tracking.
transferInfo.paymentIdentification.endToEndIdentification	91387989089	Customer Reference Number (CRN) for the BPAY payment. This is the identifier the party will use to identify their payment. Must be numeric and between 1 and 99 digits.
transferInfo.amount.instructedAmount.value	10.0	The amount of the BPAY payment in AUD.
transferInfo.paymentTypeInformation.serviceLevel[0].code	NURG	Service Level code. May not be specific to BPAY.
transferInfo.creditorAgent.financialInstitutionIdentification .clearingSystemMemberIdentification.clearingSystemIdentification.proprietary	AU_BPAY_BILLER_CODE	Indicates the type of clearing system identifier used. For BPAY this is AU_BPAY_BILLER_CODE
transferInfo.creditorAgent.financialInstitutionIdentification .clearingSystemMemberIdentification.memberIdentification	0000023796	The BPAY Biller Code. This identifies the organisation being paid.
payInfo.debtor.name	Zoila Macejkovic	Name of the initiating party (payer). Informational, but not directly used in BPAY processing.
payInfo.debtorAccount.identification.other.identification	c924e1a6-d3fe-4dad-9df4-7ac514f26c84	Identifier for the debtor's (payer's) account, the identifier for the payer's account, as assigned by the platform.
payInfo.paymentInformationIdentification	31790028-6a3b-447e-a947-7c1c0cf0b1aa	Unique identifier for the payment information block. Useful for internal tracking.
payInfo.paymentMethod	TRF	Payment Method of Payment. TRF should be indicated for all payment types.
payInfo.requestedExecutionDate.date	2025-03-21	The date on which the payment is to be executed. Important for scheduling payments; for BPAY it dictates when the payment will be lodged. Must be today for immediate Payments, or in the future for future payments.

BPAY Payments (With Payee)
For BPAY payments with a payee, the payment request will be validated to ensure the counterparty, available balance, etc. are all valid values. The request is essentially the same as a standard BPAY payment, but without the endToEndIdentification value with the addition of the payee details. The payee structure is outlined below:

JSON Path	Example	Description (BPAY Payment)
transferInfo.ultimateCreditor.identification. privateIdentification.other[0].identification	4ee0e22d-90dd-466b-b6f9-34e5ff4fcb18	This represents the Payee ID in the request, the Debtor (Payer) is paying an existing stored Payee.
transferInfo.ultimateCreditor.identification. privateIdentification.other[0].identificationSchemeName	AIIN	This represents the Identification Scheme Name.

Direct Entry (DE) Payments
For direct entry payments, the payment request will be validated to ensure the counterparty, available balance, etc. are all valid values. The request is essentially the same as a standard BPAY payment but the endToEndIdentification value holds the transaction reference. The request is outlined below:

JSON Path	Example	Description (Direct Entry Payment)
$.paymentInformation[0]	...	Alias: Payment Information. Contains details for a single payment instruction. This will be referred to as payInfo.
$.paymentInformation[0].creditTransferTransactionInformation[0]	...	Alias: Credit Transfer Transaction. Contains the specifics of the financial transaction (amount, identifiers). This will be referred to as transferInfo.
transferInfo.paymentIdentification.instructionIdentification	a21fa6ce-1367-4fd5-bfc1-cd4fbf1555df	Unique identifier assigned by the initiating party to the Credit Transfer Transaction, useful for tracking.
transferInfo.paymentIdentification.endToEndIdentification	back-end Test	Description of the Direct Entry.
transferInfo.amount.instructedAmount.value	1.0	The amount of the Direct Entry payment in AUD contained in Credit Transfer Transaction.
transferInfo.paymentTypeInformation.serviceLevel[0].code	NURG	Service Level code found in Credit Transfer Transaction. May not be specific to Direct Entry.
transferInfo.creditorAgent.financialInstitutionIdentification. clearingSystemMemberIdentification.clearingSystemIdentification.proprietary	AUBSB	Indicates the type of clearing system identifier used in Credit Transfer Transaction. For Direct Entry this is AUBSB
transferInfo.creditorAgent.financialInstitutionIdentification. clearingSystemMemberIdentification.memberIdentification	932000	The BSB of the creditor (payee) found under Credit Transfer Transaction.
transferInfo.creditorAccount.name	Sincere Howell	Name of the Creditor associated to Credit Transfer Transaction.
transferInfo.creditorAccount.identification.other.identification	100443029	The account number of the creditor (payee). Associated to Credit Transfer Transaction
payInfo.debtor.name	Gerard Terry	Name of the initiating party (payer). Found in Payment Information
payInfo.debtorAccount.identification.other.identification	c924e1a6-d3fe-4dad-9df4-7ac514f26c84	The identifier for the payer's account, as assigned by the platform. Contained in Payment Information.
payInfo.paymentInformationIdentification	a21fa6ce-1367-4fd5-bfc1-cd4fbf1555df	Unique identifier for the Payment Information block. Useful for internal tracking.
payInfo.paymentMethod	TRF	Payment Method. TRF should be indicated for all payment types in Payment Information.
payInfo.requestedExecutionDate.date	2025-03-21	The date on which the payment is to be executed. Found in Payment Information. For immediate payments this should be today's date, but for scheduled payments the value needs to be in the future.

Direct Entry Payments (With Payee)
For DE payments with a payee, the payment request will be validated to ensure the counterparty, available balance, etc. are all valid values. The request is essentially the same as a standard DE payment, but without the creditorAccount element. The payee structure is outlined below:

JSON Path	Example	Description (BPAY Payment)
transferInfo.ultimateCreditor.identification. privateIdentification.other[0].identification	4ee0e22d-90dd-466b-b6f9-34e5ff4fcb18	This represents the Payee ID in the request, the Debtor (Payer) is paying an existing stored Payee.
transferInfo.ultimateCreditor.identification. privateIdentification.other[0].identificationSchemeName	AIIN	This represents the Identification Scheme Name.

New Payments Platform (NPP) Payments
NPP Payments provide a real-time payment service that allows parties to make payments between accounts at different financial institutions. The payment request will be validated to ensure the counterparty, available balance, etc. are all valid values. NPP differs from the other payment types as it supports both domestic (BSB and account) and PayID payments. Utilise the table below and the provided examples to understand the structure of the payment request. The request structure is outlined below:

JSON Path	Example Value	Description	Scenario Specific
$.paymentInformation[0]	...	Alias: Payment Information. Contains details for a single payment instruction. This will be referred to as payInfo.	No
payInfo.creditTransferTransactionInformation[0]	...	Alias: Credit Transfer Transaction. Contains the specifics of the financial transaction (amount, identifiers).This will be referred to as transferInfo.	No
transferInfo.paymentIdentification.instructionIdentification	e8de2157-1a9e-48fe-bb2e-bac572f82174	A Universally Unique Identifier (UUID) generated by the system initiating the payment request. This ID uniquely identifies the payment instruction within your system.	No
transferInfo.paymentIdentification.endToEndIdentification	virtual Test	An identifier that's passed unchanged from the initiating party to the ultimate beneficiary. This allows end-to-end tracking of the payment. Should be unique per payment, and useful for reconciliation.	No
transferInfo.amount.instructedAmount.value	1.0	The monetary value of the payment, specified in the relevant currency.	No
transferInfo.paymentTypeInformation.instructionPriority	HIGH	Indicates the urgency of the payment. Common values include HIGH for real-time payments, and potentially NORM for less urgent transfers depending on the system's capabilities.	No
transferInfo.paymentTypeInformation.serviceLevel[0].code	URGP	URGP is commonly used for high priority payments via NPP. This refers to the priority of the payment with URGP indicating a desire for immediate processing.	No
transferInfo.paymentTypeInformation.serviceLevel[0].proprietary	X2P1	This field is crucial for specifying the NPP overlay service used for the transaction. X2P1 indicates an OSKO (PayID) based payment, leveraging the NPP's fast settlement capabilities.	Yes (PayID)
transferInfo.creditorAccount.name	Philip Hammes	The name associated with the creditor's account, which helps in identifying the recipient.	No
transferInfo.creditorAccount.identification.other.schemeName.proprietary	AU_PAYID_EMAIL	Specifies the scheme used to identify the creditor's account using PayID. Other possible values: AU_PAYID_TELEPHONE, AU_PAYID_ABN.	Yes (PayID)
transferInfo.creditorAccount.identification.other.identification	tclarke@example.com.au	The actual identifier for the creditor's account, in this case it's an email address PayID. Other examples: 0400000000 (telephone) or 12345678900 (ABN).	Yes (PayID)
paymentInformation[0].debtor.name	Aubree Kub	The name of the party initiating the payment (the payer).	No
paymentInformation[0].debtorAccount.identification.other.identification	c924e1a6-d3fe-4dad-9df4-7ac514f26c84	A system-generated identifier for the debtor's account.	No
paymentInformation[0].paymentInformationIdentification	e8de2157-1a9e-48fe-bb2e-bac572f82174	A unique identifier for this payment information block, useful when grouping multiple transactions within a single payment request.	No
paymentInformation[0].paymentMethod	TRF	Specifies the method of payment, with TRF typically standing for "Transfer".	No
paymentInformation[0].requestedExecutionDate.date	2025-03-24	The date on which the payment is intended to be executed.	No
transferInfo.ultimateCreditor.identification.privateIdentification.other[0].identification	4ee0e22d-90dd-466b-b6f9-34e5ff4fcb18	A unique identifier that represents the payee in the system. This could be a customer ID or another internal identifier used to reference the payee.	Yes - Payee Payments
transferInfo.ultimateCreditor.identification.privateIdentification.other[0].identificationSchemeName	AIIN	Indicates the type of identification being used for the payee. In this case, AIIN refers generally to an alias.	Yes - Payee Payments
transferInfo.ultimateCreditor.identification.privateIdentification.other[0].schemeName.code	CUST	A code that further elaborates on the identification scheme. Here the system is defining the identification as a customer.	Yes - Payee Payments

Scheduled Payments
For scheduled payments, the payment structure is the same as outlined above for all payment types. The payment request contains two additional components that separate it from immediate payments.

• The requestedExecutionDate value will contain a value greater than the current date.
• A standing order instruction will be incorporated into the payment request.This will define the frequency and, optionally, the end date of the payment recurrence.

There are three primary scheduled payment variants that can be initiated:

• Future Dated: One off payments scheduled for a future date.
• Recurring: Payments that occur at regular intervals with an undefined end date.
• Recurring with end date: Payments that occur at regular intervals with a defined end date.

The following table outlines the JSON structure for a scheduled payment request:

JSON Path	Example	Description (Supplementary Data for Standing Order)
$.supplementaryData[0]	...	Alias: Supplementary Data. Contains additional information regarding the payment. In this case Standing Order specific details.
$.supplementaryData[0].envelope	...	Alias: Envelope. Container for the standing order details.
$.supplementaryData[0].envelope.standingOrder	...	Alias: Standing Order. Details specific to the standing order.
$.supplementaryData[0].envelope.standingOrder.frequency	WEEK	The frequency of the standing order. The following are valid values: YEAR Payment is made annually FRTN Payment is made every fortnight SEMI Payment is made twice a year MNTH Payment is made monthly QURT Payment is made quarterly (every 3 months) TOMN Payment is made every two months (6 times a year) WEEK Payment is made every week
$.supplementaryData[0].envelope.standingOrder.toDate	2025-05-02	The end date of the standing order. This relates to the Standing Order.

Request

Responses

200

OK

400

Schema validation failed (GEN000000) or Missing instruction identifier (PAY000005) or Invalid CRN for recurring payment (PAY000007) or Payment routing input invalid (CRT000001)

401

Missing or invalid authentication token (GEN001002) or Role unauthorized (GEN001006) or Tenant context could not be resolved (AUT001001)

403

External application access denied (AUT003001) or Party not in required status (PAR003001) or Party not authorized (PAY003001)

404

Party not found (PAR004001) or No open binding for the debtor account (CRT004005) or Account not found (PAY004004) or Payee not found (PAY004005) or PayID alias not found (PAY004003) or Issuer not found (PAY004008)

412

Invalid execution date (PAY012001) or Insufficient funds (PAY012002)

422

Unsupported payment type (PAY022007) or Missing BPAY details (PAY022004) or Missing BBAN details (PAY022005) or Missing NPP details (PAY022006) or Payment token not found (PAY022002)

500

Payment service unavailable (PAY100001) or General internal server error (GEN100000) or Service error (GEN100001)

503

All connector targets are currently unhealthy (CRT103001)