Impacted Endpoints Details
Domestic NPP 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 will 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 NPP 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 payments
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.