The check life cycle after submission
The process of issuing a check typically involves ClaimCenter and one or more downstream systems. Initially, the check passes through some processing within ClaimCenter. At some point, the check is "submitted" to the downstream system.
The Claim API has several endpoints that advance a check in its lifecycle after it has been submitted. The following diagram identifies the most common statuses used in the check life cycle, the most common ways checks flow through the life cycle, and the endpoints used to advance the check to each status.
Note the following:
- When a "Requesting" check is managed entirely by APIs, it most commonly moves to
"Requested" using the POST
/acknowledge-submissionendpoint. There are endpoints that can move a "Requesting" check directly to "Pending stop" or "Pending void", but these are less common routes.
- Once a check is "Requested", the three most common outcomes are:
- The check moves to "Issued" (the check is sent) and then "Cleared" (the check is cashed).
- The check moves to "Pending stop" and then "Stopped".
- The check moves to "Pending void" and then "Voided".
The previous diagram does not exhaustively list every possible transition. For example, a check that is "Issued" can move to "Pending stop", and a check that is "Pending stop" can moved to "Issued". This diagram identifies only the most common paths. For a complete discussion of all possible transitions, see the Application Guide.
Also, there are some life cycle statuses that you cannot advance a check to through Cloud API. This includes:
- Pending transfer
If you attempt to advance a check from one status to another in a way that is not possible,
the call fails and Cloud API returns an error message indicating the operation is not
possible. For example, if you attempt to call POST
/mark-cleared on a check
that is "Requesting", Cloud API returns the following message:
"The 'mark-cleared' operation is not currently available for this check"
Advancing a check beyond submission through Cloud API
To advance a check to a given status, use the corresponding endpoint as described in the following table.
|Status To Advance To||Endpoint|
When using these endpoints, you do not need to provide a request body.
For example, suppose check cc:601 on claim cc:400 has a status of "Requesting". The following payload advances the check to the "Requested" status.
POST claim/v1/claims/cc:400/checks/cc:601/acknowledge-submission <no request body>
Then, the following payload advances the check to the "Issued" status.
POST claim/v1/claims/cc:400/checks/cc:601/mark-issued <no request body>
Finally, the following payload advances the check to the "Cleared" status.
POST claim/v1/claims/cc:400/checks/cc:601/mark-cleared <no request body>
You can also view the status of a given check through the ClaimCenter user interface. Navigate to the claim and then, in the left-hand side bar, click. This shows a list of checks for the claim and the status of each check.
The check life cycle and composite requests
Within a composite request, you cannot create or modify financial objects. This includes use of
the check life cycle endpoints (such as POST
/mark-issued). However, within
a composite request, you can GET information on financial objects.