Manage account statuses
The status of an account refers to its current state. There are several possible values for account status that all types of account have in common.
Account statuses common to all accounts
The status
field for any account can contain one of the following values:
Status | Description |
---|---|
NORMAL | Account is active. Allows both cash-in and cash-out, based on the limits of thes account. |
BLOCKED | Account is blocked. Allows cash-in only. This is a temporary status, so it is possible to change it to NORMAL or CANCELLED when needed (details below). |
CANCELLED | Account is cancelled. No cash-in or cash-out allowed. This is a final status, so you must use a different endpoint to roll back this status (details below). |
You can use the Update account status endpoint to change the account status to one of the values described previously. See Account status for more information.
Manage inactive/dormant transaction banking accounts
Transaction banking accounts have additional account statuses that you can use to manage inactive/dormant accounts. An account is said to be inactive/dormant if there have been no transactions on it for a certain period of time. The Pismo platform enables you to define three types of dormancy, based on the length of time an account has been idle. These are defined at the division level, as described in the following sections.
Account statuses specific to transaction banking accounts
The additional account statuses for transaction banking are as follows:
INACTIVE
DORMANT
UNCLAIMED
For transaction banking accounts in any of the inactive statuses, a customer-initiated transaction will reactivate the account and send the status back to normal. The account status reasons are a way of controlling what types of transactions are accepted into the account, activating the account as a consequence.
An automated process within the Pismo platform checks for accounts that have been idle for a certain minimum number of days, and, when it finds one, it changes the account status to one of the above values. Generally, an idle account first becomes INACTIVE
; if it remains INACTIVE
long enough, it becomes DORMANT
; and, if it remains DORMANT
long enough, its status changes to UNCLAIMED
. The length of time an account must remain idle before each of these changes occurs depends on your custom settings. You configure this length of time at the same time that you configure the reason to reactivate the account. The next section shows you how to configure these settings.
Configure dormancy statuses and change reasons
When an account has any of these additional statuses, the Pismo platform records the reason accepted to change the status back to NORMAL
. The available account status change reasons for this feature are as follows:
DEBIT ONLY
– Only debits will change the status back toNORMAL
.CREDIT ONLY
– Only credits will change the status back toNORMAL
.ANY
– Any transaction will change the status back toNORMAL
.MANUAL
– The status will only go back toNORMAL
if manually updated.
These parameters must be applied by division, using the Update division endpoint. Instead of passing the reason directly, you pass its reason_id
. To get a list of these IDs, use List account status reasons. The following code illustrates the type of response you should get back when you call this endpoint:
[
{
"code": "01",
"reason_id": 9,
"description": "CREDIT ONLY"
},
{
"code": "02",
"reason_id": 10,
"description": "DEBIT ONLY"
},
{
"code": "03",
"reason_id": 11,
"description": "ANY"
},
{
"code": "04",
"reason_id": 12,
"description": "MANUAL"
}
]
The response is an array of status objects, where each object consists of the code
for the new status, the reason_id
, and the description
.
If a transaction is posted and the current account status is
INACTIVE
,DORMANT
, orUNCLAIMED
, then the account's status should change back toNORMAL
.
When you use the Update division endpoint, you also pass the length of time (in days) an account must be idle, with no transactions, before the status change occurs.
The following code demonstrates how you pass the values for these parameters in the body of the Update division request:
{
"job_params": {
"inactive": {
"days": 60,
"reason_id": 11
},
"dormant": {
"days": 180,
"reason_id": 9
},
"unclaimed": {
"days": 360,
"reason_id": 12
}
}
}
The following table shows how the account status change reason relates to the operation being performed to the account status:
Reason name | Operation | Status of operation |
---|---|---|
Credit Only | Cash-in | Enabled (customer can perform a cash-in credit operation) |
Credit Only | Cash-out | Disabled (customer cannot perform a cash-out credit operation) |
Debit Only | Cash-in | Disabled (customer cannot perform a cash-in debit operation) |
Debit Only | Cash-out | Enabled (customer can perform a cash-out debit operation) |
Any | Cash-in | Enabled (customer can perform a cash-in credit or debit operation) |
Any | Cash-out | Enabled (customer can perform a cash-out credit or debit operation) |
Manual | Cash-in | Disabled (account can only be reactivated manually) |
Manual | Cash-out | Disabled (account can only be reactivated manually)` |
Account status change reasons must be mapped to the Org. This is configured during the setup of the Org. The
INACTIVE
,DORMANT
, andUNCLAIMED
statuses must be assigned an account status change reason to work properly. There's no standard behavior configured for these statuses at the Org level.
Updated 11 months ago