openapi: 3.0.0
servers:
- url: https://api.mpay.com.au
description: Production URL
- url: https://api.m-pay.com.au
description: Sandbox URL
info:
description: |
# Introduction
<p>
Monoova has developed a powerful payments engine which allows you to receive, manage and pay funds in AUD in Australia automatically.
This service is made available to Monoova’s clients through a set of easy-to-use RESTful APIs with JSON payloads described in this document.
The central idea is to reduce the cost, risk and effort normally associated with managing complex money movements so that you can focus on growing your business.
</p>
<p>
Our clients can receive and reconcile funds via Realtime transfers (NPP), direct credits/debits, BPAY and cards.
They can then manage those funds by building virtual account/wallet hierarchies to get bespoke reporting, reconciliation and much more.
And finally, our clients can pay funds via Realtime transfers (NPP) direct credits and BPAY.
As new technologies become available (e.g. NPP Mandated payments) we will make additional methods of receiving, managing and paying available.
</p>
<p>
All information flows are real-time.
Moving money between various Monoova accounts is also real time.
All money flows in and out of the Engine are as fast as the banking system allows.
</p>
<p>
The sandbox environment is open to everyone who signs up on our <a href="https://sandbox.monoova.com/user/login" target="_blank">Sandbox Portal</a> at no cost.
The sandbox environment allows you to test out the functionality of our API in a consequence free development environment.
Access to the live environment is granted once you have (1) gone through our compliance process and (2) had formal sign-off on your sandbox integration.
</p>
<p>
Monoova regularly releases additive changes to our API, as well as new versions of the API when a breaking change would occur.
To ensure your integration does not break due to these additive changes, we recommend not validating the entire schema, or the position of a parameter within the schema.
</p>
<br/><br/>
<p> <strong> Note:</strong> Please note we do not accept TLS 1.0 or 1.1 connections</p>
# Getting started
>
- Sign on to our <a href="https://sandbox.monoova.com/user/login" target="_blank">Sandbox Portal</a>
- Get your sandbox API key under **MANAGE > ACCOUNTS** in the Sandbox Portal
- [Authenticate](#section/Authentication)
- Browse this document to find the functions you need
- Begin experimenting with your first API calls by sending HTTP requests to the endpoints described in this document
- Use the provided examples in the document as guidance
# Authentication
All RESTful APIs in this document use BASIC Authentication (except those in public/v1) in two scenarios either
- <strong> API KEY </strong>
- <strong> OneShotSecurityToken </strong><br><br>
> **Sandbox Authentication Credentials**
<table>
<tr>
<th>Field</th>
<th>Value</th>
</tr>
<tr>
<td>Username</td>
<td>API Key (obtained from the <a href="https://sandbox.monoova.com/user/login" target="_blank">Sandbox Portal</a>) </td>
</tr>
<tr>
<td>Password</td>
<td>leave blank when using API key; Monoova will provide password for OneShotSecurityToken</td>
</tr>
<tr>
<td>Base URL</td>
<td>https://api.m-pay.com.au/</td>
</tr>
</table> <br>
> **Live Authentication Credentials**
This will be provided by Monoova after a technical review. <br>
<table>
<tr>
<th>Field</th>
<th>Value</th>
</tr>
<tr>
<td>Username</td>
<td>API Key (obtained from the Production Portal; Production credentials will be supplied by Monoova) </td>
</tr>
<tr>
<td>Password</td>
<td>leave blank when using API key; Monoova will provide password for OneShotSecurityToken</td>
</tr>
<tr>
<td>Base URL</td>
<td>https://api.mpay.com.au/</td>
</tr>
</table> <br>
When using the LIVE Engine, your Sign-In Account is given five (5) attempts to authenticate your credentials.
On the fifth failure your Sign-In Account is locked for one (1) hour.
The returned data will indicate that your account is locked and the time in UTC that the account will be unlocked.
If you require the account to be unlocked on the LIVE system you may contact your Monoova representative and at his or her discretion they will unlock the account.
See the API routes in Security to manage Passwords and Tokens. <br><br>
<h3> UserName/Password </h3>
Using this scenario, you can configure BASIC Authentication with the following <br> <br>
<li> <strong> UserName </strong> - API Key (obtained from the <a href="https://sandbox.monoova.com/user/login" target="_blank">Sandbox Portal</a>) Production credentials will be supplied by Monoova when you have demonstrated successful implementation of the API on our Sandbox environment.</li>
<li> <strong> Password </strong> - When using your API Key, no password is required.
If the key is compromised, it can be re-rolled via the <a href="https://sandbox.monoova.com/user/login" target="_blank">Sandbox Portal</a>. </li> <br>
# Feedback
We value your feedback on our API. Please fill out the form <a href="https://ncv.microsoft.com/8eaKX3fsiJ" target="_blank">here</a> to share your feedback.
version: v5.29
title: Monoova Payments API
contact:
name: Monoova Support
email: support@monoova.com
url: https://www.monoova.com
x-logo:
url: 'https://movdpwebsiteprodae.blob.core.windows.net/images/Monoova-Primary-Logo-Black-RGB.png'
altText: Monoova logo
tags:
- name: Receive and Pay
description: <P>
With our API, you receive funds from both outside and inside the Monoova Payments Engine.
From outside the Engine, e.g. from your customers or your own bank account, you can receive and reconcile funds via
</P>
<ul>
<li> Direct credits </li>
<li> Direct debits </li>
<li> BPAY </li>
<li> NPP </li>
</ul>
<p>
From inside the engine, you can receive funds from either your own virtual accounts and wallets or those belonging to others.
These are real-time transactions.
Once you have cleared funds in our Engine you can decide to pay recipients both outside and inside the Monoova Payments Engine.
To recipients outside, you can send money via
</p>
<ul>
<li> Direct credits </li>
<li> BPAY </li>
<li> NPP </li>
</ul>
<p>
Recipients in the Engine receive your funds in real time straight into their own virtual accounts and wallets.
As always, we provide you with comprehensive reports on all your money moves. You will find more information on reporting,
balance queries and many other management tools in the <a href="/payments#tag/Manage"> Manage </a> section.
</p>
- name: Financial
x-displayName: Financial / Payments
description: |
<h3> Overview </h3>
<p> The Financial APIs enable you to process credits and debits, including transferring funds within Monoova to a Ledger Account, an mWallet (for BPAY transactions), or an mAccount (our virtual account). You can send payments to external Australian bank accounts using a BSB and account number, token, or PayID, and make BPAY payments using a biller code and CRN. </p>
<p> The APIs also allow you to debit Australian bank accounts using Direct Debit, and retrieve the status of transactions. </p>
- name: BPAY
description: <h3> Overview </h3>
The BPAY APIs do not perform any financial transactions and are used to validate BPAY information that is used in the <a href="/payments#operation/TransactionExecute"> /financial/v2/transaction/execute </a> API.
The <a href="/payments#operation/TransactionValidate"> /financial/v2/transaction/validate </a> APIs also validates BPAY information using the same sub-system as documented in this section before performing any financial transactions.<br>
<p> <strong> Important Notes </strong> </p>
<li> By design, BPAY validation can be time sensitive. If you cache valid BPAY information for later use, it may become invalid due to time expiry.</li>
<li> By design, BPAY validation can be amount sensitive. If you cache valid BPAY information for later use and change the amount to pay then this could be invalid.</li>
<li> BPAY validation should be performed immediately before calling the <a href="/payments#operation/TransactionExecute"> /financial/v2/transaction/execute </a> API to perform the bill payment.
You have the option of calling <a href="/payments#operation/TransactionValidate"> /financial/v2/transaction/validate </a> (The first validation error will be returned which may not be a BPAY error) </li>
- name: Verify
description: <h3>Overview</h3>
<h3>Bank Account Ownership Verification</h3>
<p>The purpose of this API is to verify access to a bank account or PayID details, which has several compliance and risk-mitigation applications.</p>
<p>If the NppCreditPayID method is used, the API response will include the PayID name. In scenarios where the PayID is either unidentified or not configured, you can verify if the payer/payee has access to the account using a secret code.</p>
<p>By passing the BSB and account number, the account verification API will credit a target bank account with a secret code in the remitter name and lodgement reference. This code can only be viewed by someone who has access to the target bank account by accessing and viewing their bank statement. The code can then be submitted against our records, and if it matches, Monoova will persist a verification token against that specific account.</p>
<h4>How it works</h4>
<ol>
<li>Initiate a verification transaction on the target bank account.</li>
<li>Monoova will credit the target bank account with a 1c amount and a secret remitter code (may take up to 48 hours for the code to show on the target bank account).</li>
</ol>
<p>Below image is how a sample verification code appears on a bank statement. In YELLOW is the code your client will need to return, in BLUE is your remitter name. For NPP verification transactions, the secret code can also be found in the lodgement reference.</p>
<img src="https://movdpwebsiteprodae.blob.core.windows.net/images/bank_ref.png" alt="bank-ref">
<ol>
<li>Owner of the target bank account views the statement to obtain the secret code.</li>
<li>Submit the secret code to Monoova via POST <a href="/payments#operation/VerifyAccountValidate">verify/v1/aba/validate</a>. In the sandbox, use code "555555" to test successful validation of an account verification.</li>
<li>If the submitted code and amount are correct, the target bank account is designated as verified.</li>
</ol>
- name: Automatcher (Bank Account Receivables)
description: <h3> Overview </h3>
<p>
Having customers paying you by bank transfer might be easy for your customers but contains a reconciliation risk for you.
If your customer mistypes or forgets the reference to go with the payment, you might not know whom the payment is from.
Orphaned transactions can be challenging and costly to handle. The solution is our receivables API.
We allow you to assign a specific account number to each payer so you know for a fact where the received funds originated, regardless of whether they remembered to type the reference.
</p>
<p>
Specifically, the bank-account receivables APIs allow the creation and maintenance of bank account numbers for the purpose of receiving and reconciling funds via direct credit. Once an account number is created, payments may be made via any banking institution in Australia to the BSB and account number provided by us to you.
These account numbers can be toggled active/inactive and linked to a client provided unique ID.
Once a transaction is received, Monoova provides reporting on the details of each item, and makes the funds available for disbursement in your Sign-in mAccount.
Authentication is the same as for the rest of Monoova’s APIs.
</p>
- name: Whitelisting for Automatcher (Bank Account Receivables)
description: <h3> Overview </h3>
<p>
This feature enables whitelisting of bank accounts when receiving funds in automatcher accounts. Funds received from a non-whitelisted account will be automatically returned. Using this feature, funds received can be limited to pre-approved bank accounts only.
</p>
<p> There are 2 criteria that can be set when whitelisting bank account numbers. </p>
<p> Inbound transaction will only be accepted from: </p>
<p> 1. An account that matches a whitelisted account name; AND/OR <br/>
2. An account that matches a whitelisted BSB and account number </p>
<p> If pre-defined criteria are not met, the transaction will be returned to the sender automatically. If enabled, each automatcher account has its own separate whitelist. </p>
<p> You have the option to establish a webhook subscription to receive a notification when a payment is declined as a result of whitelist restrictions. </p>
<p> To subscribe to a webhook use the <a href="/payments#tag/Subscriptions"> Subscriptions </a> APIs. Event name: <strong>InboundDirectCreditRejections</strong></p>
- name: PayID
description: <h3> Overview </h3>
<p>
A PayID is an alias for a bank account number that makes paying into account easier.
A PayID can be an email address, phone number or ABN.
PayIDs are issued and associated with our <a href="/payments#tag/Automatcher-(Bank-Account-Receivables)"> /receivables </a> bank accounts to allow your users a simpler way of sending you money.
Once a PayID has been registered against a bank account, when a payment is made to that ID, the funds will arrive in your receivables account number.
Currently we only support email PayIDs via the API.
</p>
- name: Reconciliation Rules
description: <h3> Overview </h3>
<p>
This feature enables customers to specify the criteria for accepting incoming NPP and DE payments in real time. The customer will be able to advise Monoova about the exact amount they expect to receive in their ABA/PayId in an agreed timeframe. This information would be used to determine whether to accept or reject a payment.<br/><br/>
There are 2 criteria that can be set when specifying the reconciliation rules. Inbound transactions will only be accepted if
<ul>
<li>Bsb - Account Number and amount matches an active reconciliation rule. OR</li>
<li>PayId and amount match an active reconciliation rule</li>
</ul>
If pre-defined criteria are not met, the transaction will automatically be returned to the sender. <br/><br/>
These rules will not be applied to NPP PayTo Receivables.<br/>
</p>
- name: Tools
description: <h3> Overview </h3>
The APIs in the tools/v1/ section represent utilities that you may find useful while consuming the other APIs offered as part of the Engine other APIs.
- name: Manage
description:
To maximise the benefits of payments automation, you may choose to make use of our kit of management tools.
Here, you will find information on APIs related to reporting, security features and the management of our virtual account, the so-called mAccount.
We have a number of new features coming and will keep you updated as they appear.
Our aim is to allow you to automate fully the management of your funds.
- name: Subscriptions
description: The endpoints in this section allow subscription and management of webhooks for the purpose of receiving transaction notifications.</br>
- name: Webhooks
description: The examples of webhooks for the purpose of receiving transaction notifications.
<table>
<tr><th>Event name</th><th>Notification sent when</th> </tr>
<tr><td> NPPReceivePayment </td><td> Payment received via NPP rail. </td></tr>
<tr><td> PayToReceivePayment </td><td> Payment received as initiated through PayTo. </td></tr>
<tr><td> InboundDirectCredit </td><td> Payment received via direct entry rail. Note funds settled in batch via BECS settlement windows. </td></tr>
<tr><td> InboundDirectDebit </td><td> Received 3rd party request to direct debit automatcher account. </td></tr>
<tr><td> DirectEntryDishonour </td><td> A direct debit request / direct credit payout has been dishonoured. </td></tr>
<tr><td> PendingInboundRtgsImt </td><td> RTGS/IMT transactions are received. </td></tr>
<tr><td> InboundRtgsImtStatus </td><td> The status of an RTGS/IMT transaction changes. </td></tr>
<tr><td> NppReturn </td><td> An NPP payment is returned. </td></tr>
<tr><td> NppPaymentStatus </td><td> The status of a pending NPP payment is updated. </td></tr>
<tr><td> InboundDirectCreditRejections </td><td> An inbound direct credit is rejected. </td></tr>
<tr><td> NPPCreditRejections </td><td> NPP payment intended for an ABA/PayId is rejected. </td></tr>
<tr><td> DirectDebitClearance </td><td> Daily when direct debit transactions are cleared. </td></tr>
</table>
<br/>
- name: Reports
description: <h3> Overview </h3>
The APIs in the reports/v1 section help you keep track of balances and transactions.
Payments automation is only helping you relax if you know where exactly your money is at any one point in time.
- name: Token
description: <h3> Overview </h3>
<p>
Using tokens is a way of increasing the security around sensitive information. A token can be used to obfuscate debit and credit details.
The details of a token (its payload) are stored encrypted on the Engine servers.
The tokening system has been designed such the generated token has no mathematical or algorithmic connection to the secret data held as the payload.
The token is a random number that is manifested as a GUID.
Currently two types of payloads can be held within the tokening system
</p>
<ul>
<li> Australian Bank Account </li>
<li> BPAY details </li>
</ul>
<p>
Other payload types can be added if required.
For example, if you have asked the user to enter their bank-account details on your website you can use the security/v1/createOneShotSecurityToken API to embed an OneShotSecurityToken in your page.
Using this OneShotSecurityToken you can call the appropriate token/v1/create API passing the details.
This way, the customer’s payload details are never passed through your server.
</p>
- name: Security
description: <h3> Overview </h3>
<p>
The security/v1 APIs allows you to manage security tokens.
This gives you an alternative to using signIn API KEY for BASIC authentication for each API call.
Security tokens come in two forms
</p>
<ul>
<li> <strong> OneShotSecurityToken </strong> </li>
<li> <strong> SecurityToken </strong> </li>
</ul>
<p>
The two security tokens operate in exactly the same way.
The token is used to replace your UserName when configuring BASIC Authentication.
Should you provide a password anyway, it will be ignored. Each token type has an expiry time between 1 and 15 minutes. The expiry time cannot be extended.
</p>
<p>
As the name implies, a OneShotSecurityToken can only be used once. The token is deleted on its first use or when it expires, whatever is sooner.
</p>
<p>
A SecurityToken can be used multiple times until it expires. The expiry time of a SecurityToken can be extended.
</p>
<p>
Please note that security tokens discussed in this section have nothing in common with the token/v1 APIs described elsewhere in this document.
Security tokens provide secure sign-in from a web page; token/v1 APIs tokenize sensitive information.
</p>
- name: mAccount
description: <h3> Overview </h3>
The mAccount is the name we have given our virtual account.
It is at the centre of anything you do with our Payments Engine.
In many ways, your mAccount(s) is you in the Engine,
this is where you get authenticated, where your funds flow in and out, and where you get your reports.
It is also the building block for a bespoke ecosystem of virtual accounts which you can build in the Engine.
And though we call it an account, it can just as easily be used as a wallet.
The APIs in this section do not perform financial transactions. Instead, they are used to manage mAccount information in the Engine.
The /financial/v2/transaction API verifies mAccount information using this subsystem before performing a transaction.
- name: mWallet
description: <h3> Overview </h3>
mWallet is the name we have given to the digital wallet required for our BPAY payments. For any other digital-wallet uses, we recommend our mAccount.
The APIs in this section do not perform any financial transactions.
They are used to manage mWallet information used by the Engine.
The /financial/v2/transaction API verifies mWallet information using this subsystem before performing the transaction.
- name: Public Endpoints
description: ''
- name: Ledger Account
description:
'Monoova allows virtual ledgers to be created and linked to an Automatcher account number and optional PayID that can be used to track funds received and paid.
Moving funds in and out of ledgers is accomplished by utilising the Monoova PayTo and financial APIs. In the financial/execute call, populate “ledgerAccountNumber” in the mwallet fields, either in the disbursement object to transfer funds, or in the source object to withdraw.'
x-tagGroups:
- name: 'Receive and Pay'
tags:
- Financial
- Verify
- Automatcher (Bank Account Receivables)
- Whitelisting for Automatcher (Bank Account Receivables)
- Ledger Account
- Reconciliation Rules
- PayID
- Tools
- name: 'BPAY'
tags:
- BPAY
- mWallet
- name: 'Manage'
tags:
- Subscriptions
- Webhooks
- mAccount
- Reports
- Security
- Token
- name: 'Public Endpoints'
tags:
- Public Endpoints
security:
- BasicAuth: []
paths:
# bpay
'/bpay/v1/validate/{billerCode}':
get:
tags:
- BPAY
summary: Validate a BPAY transaction
description:
This API validates the BPAY Biller Code and optionally the BPAY Customer Reference Number and Amount. For a complete BPAY validation the BPAY Biller Code, BPAY Customer Reference Number and Amount must be supplied.
When fully validated a BPAY financial transaction should be made as soon as practicable as some BPAY combinations are date sensitive. BPAY validation uses the BPAY subsystem error codes. <br/>
Sample URL: https://api.mpay.com.au/bpay/v1/validate/{billerCode}?custRef={CRN}&amount={amount}
operationId: BPAYValidate
parameters:
- name: billerCode
in: path
required: true
description: This is the BPAY biller code that was requested. billerCode must be numeric
schema:
type: string
example: '857763'
maxLength: 10
- name: custRef
in: query
required: false
description: BPAY Customer Reference Number. If this field is empty this denotes that the customerReferenceNumber is variable for each bill and should not be reused.
schema:
type: string
example: '6279059700000505'
maxLength: 20
- name: amount
in: query
required: false
description: Bill amount to be validated. <strong> Note if CustRef is not provided, amount will not validate as it is dependent on both the CRN and Biller. </strong> The maximum value of the field is $9999999999.99.
schema:
type: number
example: '100'
maxLength: 13
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/DTO.ValidateBPAYResponse_V1'
'400':
description: Bad request
'500':
description: Internal Server Error
'/bpay/v1/biller/{billerCode}':
get:
tags:
- BPAY
summary: 'Get BPAY biller code details'
description: This API returns extended information for the BPAY biller. Status will be “UnknownBillerCode” if Biller Code is invalid.
operationId: BPAYGetBiller
parameters:
- name: billerCode
in: path
required: true
description: This is the BPAY biller code that was requested. billerCode must be numeric
schema:
type: string
example: '857763'
maxLength: 10
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/DTO.BPAYBillerResponse_V1'
'400':
description: Bad request
'500':
description: Internal Server Error
'/bpay/v1/receipts':
post:
tags:
- BPAY
summary: 'Get BPAY receipts'
description: This API returns the list of BPAY receipts.
<br/> <strong> Note:</strong> Filters - One of the below options should be provided by customer.
<br/> 1) uniqueReferenceNumber <br/> 2) billerCode + referenceNumber + date
operationId: BPAYGetReceipts
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/bpay.receipts'
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/DTO.BPAYReceiptResponse_V1'
'400':
description: Bad request
'500':
description: Internal Server Error
'/bpay/v1/billers':
get:
tags:
- BPAY
summary: Search for BPAY billers
description:
This API returns an array of BPAY billers matched to the case insensitive search string. The system matches on the billerLongName and billerShortName.
Use skip and take to page through result set. Skip and take will be changed back to their defaults if they are over-range. Status will be “UnknownBillerCode” if there are no matches.
operationId: BPAYGetBillers
parameters:
- name: search
in: query
required: false
description: The search string
schema:
type: string
example: 'pty%20ltd'
- name: skip
in: query
required: false
description: The actual number of records skipped.
schema:
type: number
example: '0'
- name: take
in: query
required: false
description: The number of records that were requested.
schema:
type: number
example: '50'
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/DTO.BPAYBillersResponse_V1'
'400':
description: Bad request
'500':
description: Internal Server Error
'/bpay/v1/history/{accountNumber}':
get:
tags:
- BPAY
summary: Get a wallet's BPAY History
description: This API returns the mWallets history of BPAY payments.
The returned history list is sorted by the count property of the BPAYHistoryItem descending.
operationId: BPAYGetHistory
parameters:
- name: accountNumber
in: path
required: true
description: associated 'mWallet' 16 digit number
schema:
type: integer
example: 6279059700022400
maxLength: 16
minLength: 16
- name: take
in: query
required: false
description: The number of records that were requested.
schema:
type: integer
example: '50'
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/DTO.BPAYHistoryResponse_V1'
'400':
description: Bad request
'500':
description: Internal Server Error
'/bpay/v1/bpayInReport/{date}':
get:
tags:
- BPAY
summary: BPAY Receivables Report
description:
Returns a report of all received BPAY transactions for the day with associated details.
If requested multiple times on the current date (calendar day, AEDT), the report is cumulative.
E.g. if, on the same day, a report is requested at 10am and another one at 1pm,
the report at 1pm will contain all the transactions already contained in the 10am report, in addition to any new transactions.
<br/> <br/>
The report is an application/octet-stream, columns are comma separated.
Where a comma(,) or double quote(") is present in any of the below fields,
the field will be encased in double quotes and/or escaped as per <a href="https://tools.ietf.org/html/rfc4180" target="_blank">RFC4180</a><br>
Columns are as follows:
<style type="text/css">
.tb { table-layout:auto; width:100px;!important }
.td { overflow:hidden; white-space:nowrap; text-overflow:ellipsis; !important}
</style>
<table class="tb">
<tr>
<td class="td"> Transaction Id </td>
<td class="td"> Batch Id </td>
<td class="td"> BPAY Settlement Date </td>
<td class="td"> Payment Accepted DateTime </td>
<td class="td"> Payment Type </td>
<td class="td"> Payer Institution Code </td>
<td class="td"> Payer State </td>
<td class="td"> Biller Code </td>
<td class="td"> Customer Reference Number </td>
<td class="td"> Payment Method </td>
<td class="td"> Amount </td>
<td class="td"> Transaction Reference Number </td>
</tr>
<tr>
<td class="td">
<br/> <br/>
Monoova generated Unique ID.<br/>
Integer.<br/>
<br/> <br/> <br/>
</td>
<td class="td">
Payment Batch ID. <br/>
Payments come in batches <br/>
throughout the day. <br/>
Integer.<br/>
</td>
<td class="td">
AEDT, Sydney. <br/>
Max 27 chars.
</td>
<td class="td">
AEDT, Sydney. <br/>
Max 27 chars.
</td>
<td class="td">
Possible values: <br/>
'Payment', 'Error Correction', 'Reversal'.
</td>
<td class="td">
PayerInstitutionCode. <br/>
Max 3 chars.
</td>
<td class="td">
PayerState <br/>
Max 3 chars.
</td>
<td class="td">
BillerCode <br/>
Max 10 chars.
</td>
<td class="td">
CustomerReferenceNumber <br/>
Max 20 chars.
</td>
<td class="td">
PaymentMethod <br/>
Max 3 chars. <br/>
</td>
<td class="td">
Amount, <br/>
2 decimal places <br/>
for cents. Max 12 chars.
</td>
<td class="td">
TransactionReferenceNumber. <br/>
Max 21 chars.
</td>
</tr>
</table>
operationId: BPAYReceivablesReport
parameters:
- name: date
in: path
required: true
description: Format: 'yyyy-MM-dd'. The date for which Monoova received the BPAY Receivable transactions.
schema:
type: string
example: '2020-11-01'
- name: skip
in: query
# --- truncated at 32 KB (490 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/monoova/refs/heads/main/openapi/monoova-payments.yml