v20260901 Release Notes

01 Sep 2026

Support for deeper client hierarchies

You can now create and manage sub-clients beyond two levels, providing greater flexibility for businesses with more complex client structures.

Endpoint: POST /clients

What’s changing

Previously, client hierarchies were limited to two levels (L1 → L2). Zepto now supports additional levels (L3 and beyond) where enabled for your organisation.

Your existing setup will not change. Client hierarchies will continue to be limited to their currently configured depth unless Zepto enables additional levels for your organisation.

With this change:

• Sub-clients can be created and managed across multiple hierarchy levels.
• Client hierarchies beyond L2 are visible throughout the Zepto Dashboard, including client lists, filters and navigation.
• Suspending or off-boarding a client will prevent new agreement initiation for all clients beneath it in the hierarchy.
• Clients at L3 and deeper currently support PayTo only. Request to Pay (RTP) is not supported beyond L2.
• From API version 20260901, the Clients API supports an optional parent_client_id when creating a client, allowing you to specify its parent and create nested client structures.

What do I need to do?

No action is required for existing integrations. Your current client hierarchy limits remain unchanged.

If your organisation needs to create sub-clients beyond L2, contact Zepto to discuss enabling a deeper client hierarchy.

If you use the Clients API and want to create nested sub-clients, upgrade to API version 20260901 or later and provide parent_client_id when creating the sub-client.

01 Sep 2026

PayTo initiator identified by client_id

Description

From API version 20260901, the initiator on PayTo agreement creation is identified by client_id only. The abn and acn initiator options, which are deprecated on version 20260101, are removed on this version and requests supplying them are rejected.

With this change:

• initiator.client_id attributes the agreement to a specific registered sub-client.
• When the initiator block is omitted, the agreement is automatically attributed to your primary Zepto client record.
• Identity information used in the underlying PayTo payment message — including legal name, ABN and ACN — is always sourced from the registered Zepto client record.
• initiator.name can still be provided by your integration, and must match a name registered on the client.
• The initiating client must be registered with an ABN or ACN.
• The response initiator block always includes client_id on this version. It is null when the agreement is attributed to your primary client.

For Direct Merchants

No integration changes are required.

When creating an agreement without an initiator block, the agreement will automatically be attributed to your Zepto client record. Identity information used in the underlying PayTo payment message will also be sourced from this record.

What do I need to do?

If your integration supplies initiator.abn or initiator.acn, register the sub-client and supply initiator.client_id instead before upgrading to this version.

Endpoint: post_payto-agreements

Example Payload:

{
  "initiator": {
    "name": "Acme Sub-Merchant",
    "client_id": "<L2-uuid>"
  },
  "creditor": {},
  "debtor": {}
}

{
  "id": "<agreement-uuid>",
  "initiator": {
    "name": "Acme Sub-Merchant",
    "legal_name": "Acme Sub-Merchant Pty Ltd",
    "abn": "11223344556",
    "acn": null,
    "client_id": "<L2-uuid>"
  }
}

01 Sep 2026

Removed on version 20260901

Upgrading to API version 20260901 also removes the following. Requests supplying these fields are rejected on this version; no changes are needed while you remain on version 20260101 or earlier.

• risk_level on sub-client creation. The risk level is now derived internally from the merchant category code you supply. Requests including risk_level are rejected, and responses no longer return the field.
• The initiator object on agreement amendments. Amendments no longer accept initiator changes.
• The undocumented relationship parameter on sub-client creation.

What do I need to do?

Stop sending these fields before upgrading to version 20260901.

01 Sep 2026

Introducing Counterparties in PayTo Flow

Background

As part of AP+'s PayTo Liability Framework, Zepto merchants that fall in a high risk profile are required to create “counterparty” records, with one or more “payment accounts”, using the Counterparty API.

Endpoint: POST /counterparties

Key Concepts:

1. counterparty.identity
   Counterparty includes an identity object to capture legal_name and verification data. Accepted verification methods are currently limited to third_party_provider. In the future Zepto may offer an in-house product.

Data collected includes the third party provider name, a reference and the verification timestamp.

While identity is optional in general, it will be required for PayTo high risk clients.

2. counterparty.payment_accounts
   Each counterparty can have one or more “payment accounts” - an account the counterparty can be paid from or to.

Payment accounts types are the same types accepted for PayTo creditors and debtors, including BBAN and PayID aliases.

Each payment account can optionally include a verification object (although required for PayTo high risk clients). Verification methods include:

• Zepto Validate
• Alias Resolution
• Third Party Provider

Payment account uid can be provided in the creditor or debtor object of PayTo API requests.

Learn more about Counterparties here.

01 Sep 2026

Adding identification to existing agreements

Agreements created on earlier API versions carry no client_id or payment_account_uid. A new endpoint lets you add these identifiers to an existing agreement without cancelling and recreating it, so active mandates can continue uninterrupted once counterparty requirements apply to your profile.

Endpoint: POST /payto/agreements/{agreement_uid}/add_identification

With this endpoint you can add, but never change:

• an initiator.client_id — the client's registered details must match the initiator details already on the agreement
• a debtor payment_account_uid — the payment account must belong to a registered counterparty and match the agreement's debtor account details

Identification can only be added once per identifier, and only to agreements that are not in a final state.