DEVELOPER GUIDE

Initiating a Zepto Validate (CoP) lookup

This article with guide you on how to initate a validate lookup.

Overview

When a dispute is raised by the bank, Zepto creates the investigation, notifies your platform, and requests merchant action.

Warning

Make sure you submit evidence before the due date. Missing the deadline may result in the case being closed or rejected.

Success

Once accepted, the action request is completed and the dispute workflow progresses accordingly.

Important

Rejecting an action request without the correct review may cause avoidable operational issues.

Tip

Retrieve the investigation first, then inspect the active action request so you can present the right next step to your merchant.

Parameters

When initiating an alias lookup, you’ll need to specify the following request parameters:

Parameters	Description
`uid`	Supplied unique identifier for CoP lookup.
`account_identifier`: `type`* (required)	`bban`
`account_identifier`: `value`* (required)	The BSB and Account Number (e.g. `123456-0987654321`)
`party_name`* (required)	The party name to validate against the account.
`requester: id`* (required)	A unique identifier of the end customer.

Requester Information

The requester object (i.e. id) is used as a way of enforcing enumeration controls based on the end-user requesting this CoP lookup. This is done as an integral component of Zepto's strategy for preventing fraudulent activities and safeguarding against enumeration attacks, ultimately ensuring the security of the end customer's data.

How you populate requester.id depends on your platform architecture. The value should represent the most meaningful actor you want limits to apply to.

Common implementation patterns:

Scenario	Recommended `requester.id`
Platform supports multiple organisations, each with individual users	Use a unique identifier for each individual user within the organisation
Organisation accesses the platform through a shared login	Use a unique identifier for the organisation
End user performs lookup as self-service	Use a stable internal identifier for that end user journey, such as a session ID, invitation ID, customer reference, or similar internal ID

Endpoint

POST /cop/account/validate

Request Payload

{
  "uid": "byronsurf_cop_request_123456",
  "account_identifier": {
    "type": "bban",
    "value": "062000-11111111"
  },
  "party_name": "Murray Watego",
  "requester": {
    "id": "AdminUser1234"
  }
}

Response

Upon submission, a response will show one of the following:

Successful: 200 response with match outcome
Failed:
- 404 Requested resource not found with corresponding detail
- 422 Unprocessable entity with corresponding detail

Notable Fields

Value	Description
`result`	`match` `close_match` `no_match` `account_closed`
`match_name`	The name matched from the Data Holder.
`insights`: `risk_score`	A proprietary risk score from 0 to 100, where 100 indicates the highest risk. (🚧 Alpha - Additional information coming soon)
`insights`:`is_joint`	`True` or `False`
`insights`:`suggested_payment_channels`	`npp.sct` `de.dc`