---
title: R10 changes affecting your integration
slug: r10-integration
docTags:
createdAt: 2026-10-25T23:28:26.690Z
---
Release 10 (R10) is a mandatory industry-wide change to Australia's real-time payments infrastructure, driven by Australian Payments Plus (AP+). It includes changes to NPP payment standards and the related harmonisation of Osko.
For Monoova clients, R10 introduces changes to payment messaging and data requirements that will require changes to impacted integrations.
### Main change areas
- The main industry changes include the harmonisation of Osko and Single Credit Transfer, adoption of the 2024 ISO 20022 messaging standard, and new message attributes supporting Payday Super, PayTo and IPS payment changes.
- Some changes introduce new API versions or response fields. Other changes affect processing behaviour or test data without changing Monoova's client-facing schema.
### Does R10 affect me?
**All clients using NPP or PayTo** may be impacted. The level of change depends on the products and payment flows used by each integration.
| **Who may be impacted** | **What may change** |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Domestic NPP receivables | New report versions and new optional fields in reporting and payment notifications to support R10 use cases. |
| PayTo | Changes apply across PayTo receivables, mandate management and payment initiation. Some requests will be rejected if merchant category codes are missing. |
| Domestic NPP payables and returns | Underlying processing will change; direct impact is expected to be limited. |
| Confirmation of Payee | A new Confirmation of Payee endpoint, with new error messages and a request code that is now mandatory. We recommend moving before R10 go-live. |
| IPS payments | R10 changes apply to IPS, with detailed requirements still being finalised. IPS requirements and testing guidance will follow before 30 November 2026. |
# Key details
### Domestic receivables
New optional report and webhook fields will support Payday Super, batch identification and source PayID visibility for PayTo receipts. The new report versions use the same request filters as the current versions, and existing columns remain. The rollout date for multi-credit transfer (MCT) is not yet confirmed.
| **Report or webhook** | **Replaces** | **Fields added** |
| ------------------------------ | --------------------------- | ---------------------------------------------------------------------------------------------------------- |
| receivables/v7/report | receivables/v6/report | PayrollPaymentDate
PaymentPurposeCode
BatchIdentification |
| paytoreceivables/v2/report | paytoreceivables/v1/report | PayrollPaymentDate
PaymentPurposeCode
BatchIdentification
SourcePayId
SourcePayIdType |
| Receive Payment webhook | Existing webhook | PayrollPaymentDate
PaymentPurposeCode
BatchIdentification |
| PayTo Receive Payment webhook | Existing webhook | PayrollPaymentDate
PaymentPurposeCode
BatchIdentification
SourcePayId
SourcePayIdType |
- PayrollPaymentDate is populated (YYYY-MM-DD) only for super contributions with category purpose code PENS.
- PaymentPurposeCode and BatchIdentification are populated only when the sending institution includes them.
- SourcePayId and SourcePayIdType show the payer's PayID on PayTo receipts where the agreement was set up against a PayID, and only where source account details are enabled for your account.
- Your integration should accept these fields when present and continue to work when they are missing.
### PayTo mandate management
Mandate changes include sub-merchant identifiers, ISO-aligned purpose codes and merchant category codes in some scenarios. They apply to both the synchronous and asynchronous agreement endpoints.
- Sub-merchant ID: a new optional subMerchantId identifies the specific merchant on an agreement. It must be active and belong to your account; inactive or unknown values are rejected. Agreements without it are created as they are today.
- Merchant category codes: new optional payeeMCCCode and ultimatePayeeMCCCode fields are checked against your allowed codes. They are mandatory where the purpose code is OTHR, PERS, RETL, UTIL, UBIL, GAMP or GAMB and your mAccount has no default MCC.
- Responses and webhooks: the agreement retrieval APIs and the Payment Agreement Notification webhook include these fields when they hold a value. Retrieval by date range can be filtered by subMerchantId.
New ISO-compliant purpose codes replace three legacy codes, and a new refund code is added. New codes can be used from 4 May 2027. Legacy codes still be used for new agreements until 2 December 2027, and from 3 December 2027 new agreements must use the new codes. Existing agreements created with legacy codes do not need to be changed and keep working until they are cancelled or expire.
| **Legacy code** | **New code** | **Description** |
| ---------------- | ------------- | ---------------------- |
| MORT | HLRP | Mortgage payments |
| UTIL | UBIL | Utility payments |
| GAMP | GAMB | Gambling payments |
| – | REFU | Refund payments (new) |
### PayTo payment initiation
Payment instructions gain new optional fields. Instructions without them continue to work, subject to the MCC rules.
| **Field** | **How it works** |
| --------------------------------------- | ----------------------------------------------------------------------------------- |
| payrollPaymentDate | For super contributions. Only accepted where the agreement's purpose code is PENS. |
| subMerchantId | Must be active and must match the sub-merchant on the agreement. |
| payeeMCCCode
ultimatePayeeMCCCode | Checked against your allowed codes. If left out, your mAccount default is used. |
| batchInformation | Optional. If included, clientBatchIdentification is mandatory. |
Payment instruction retrieval can be filtered by subMerchantId and clientBatchIdentification, and the payment status webhook includes the new fields.
For organisation payees, payments under agreements with purpose code OTHR, PERS, UTIL, GAMP or RETL must carry MCC codes. We are backfilling MCC data for existing active agreements. Where an agreement has no MCC and your mAccount has no default, the payment can be blocked. If this applies to you, check with your Monoova representative that a default MCC is set up for your mAccount.
### Domestic payables and returns
No schema change is expected, but underlying processing will become asynchronous. We'll keep the experience synchronous for you, and no material delays are expected. Pending transactions may be more visible for a short time after go-live and will continue to show in existing reports and webhooks until the final outcome is received. NPP Verification will work as it does today; pending-state handling is outside R10.
### Confirmation of Payee
We are moving Confirmation of Payee to a new version of the API as part of R10. If you use Confirmation of Payee, we recommend moving to the new version before R10 go-live on 7 February 2027. To move across, you'll need to:
- Update the endpoint URL to the new Create Account Validation endpoint: https\://developer.monoova.com/api/create-account-validation
- Handle the new error messages, which are listed on the developer page.
- Include requestPurposeCode in every request. It is now mandatory, and the allowed values are listed on the developer page.
Confirmation of Payee lookups are included in the R10 test pack.
### IPS
Payables and receivables requirements remain under review and will be confirmed in specific guidance before testing opens on 30 November 2026. IPS is not covered by the current test pack.
****