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.


Check life cycle after submission

Note the following:

  • When a "Requesting" check is managed entirely by APIs, it most commonly moves to "Requested" using the POST /acknowledge-submission endpoint. 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:

  • Denied
  • Pending transfer
  • Transferred

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
Requested POST /claims​/{claimId}​/checks​/{checkId}​/acknowledge-submission
Issued POST​ /claims​/{claimId}​/checks​/{checkId}​/mark-issued
Cleared POST /claims​/{claimId}​/checks​/{checkId}​/mark-cleared
Pending stop POST /claims​/{claimId}​/checks​/{checkId}​/request-stop
Stopped POST /claims​/{claimId}​/checks​/{checkId}​/mark-stopped
Pending void POST /claims​/{claimId}​/checks​/{checkId}​/request-void
Voided POST​ /claims​/{claimId}​/checks​/{checkId}​/mark-voided

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 Financials > Checks. 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.