Skip to main content
POST
Push funds via check by mail

Reissuing a check

Neither Check Stop nor Check Cancel reissues a disbursement. Both are terminal for the original, and no method resends a check. A reissue is always a new disbursement, submitted as a new Process request with a new participant_unique_id1. Take care not to conflate the two identifiers. A Check Stop or Check Cancel request carries the original participant_unique_id1, because that is part of how the check is located. The reissue that follows carries a new one, because it is a new disbursement. Which method you use to close out the original determines when it is safe to reissue. In both cases the API response is acceptance, and the webhook event is the confirmation — what differs is how the instruction reaches the bank, and therefore how long confirmation takes.
Wait for the confirming webhook before reissuing. Receipt of check.stopped or check.canceled is what confirms a check presented for fulfillment will no longer be accepted — the API response alone does not. Reissuing before then risks paying twice, and the exposure is widest with Check Cancel, where confirmation waits on the batch.
Because of that delay, Check Cancel suits cases where the check will not be presented in the interim — most safely at routed status with reason code 73 (Check Not Printed), where no physical check exists yet. If the check may already be in the recipient’s hands, use Check Stop.
Banking days, not business days. Check Cancel batches move on banking days — excluding weekends and federal bank holidays. If check.canceled has not arrived by the end of the next banking day, contact support with the original participant_unique_id1 before reissuing rather than treating the silence either way.
Managed disbursement flows. Where the original was staged through Notify rather than submitted directly, the reissue re-enters the recipient experience — the recipient is notified again, authenticates, and selects a payment method. They may choose something other than check the second time.

Body

application/json
participant_id
integer
required

Unique participant identifier assigned by Ingo.

Example:

12345

account_type
enum<string>
required

Always CK for check by mail disbursements.

Available options:
CK
Minimum string length: 1
Example:

"CK"

amount
number<float>
required

Amount of the transaction.

Required range: x >= 0.01
Example:

500

source_of_funds
enum<integer>
required

Funding source indicator: 1 = Cash, 2 = Check, 3 = Combo of Cash & Check, 4 = Corp Disbursement.

Available options:
1,
2,
3,
4
Example:

4

participant_unique_id1
string
required

Participant assigned transaction ID for the process request. Value must be unique and may not contain NPI data. Used for idempotency — a duplicate value returns an idempotent response without initiating a new push request. Appears on daily reconciliation reports.

Required string length: 1 - 255
Example:

"35a792a5-39e6-46fa-add1-419a75d3aa9a"

timestamp
integer<int64>
required

Unix timestamp of the request.

Example:

1597862420

version
integer
required

API version of the request. Current version is 11.

Example:

11

customer_account_token
string
required

Token representing the account number and customer data as provided in the response from a previous Verify API call.

Required string length: 1 - 255
Example:

"6218c726-3989-40ab-af84-fa6f4c932cb6"

recipient_phone
string | null

Recipient phone number.

Maximum string length: 25
Example:

"5551234567"

participant_unique_id2
string | null

Optional second participant assigned transaction ID. Does not appear on daily reconciliation reports.

Maximum string length: 255
Example:

"2d4ebd46-616b-4212-bc54-1f7f68514e1a"

check_memo_data
string | null

Optional memo line printed on the check. Maximum 30 characters.

Maximum string length: 30
Example:

"Invoice #12345"

remittance_memo_data
string | null

Optional remittance memo data included with the check mailing. Maximum 193 characters.

Maximum string length: 193
Example:

"Payment for services rendered Q2 2026"

store_id
string | null

Client assigned store ID. Required for Retail client participants.

Maximum string length: 255
Example:

"STORE-001"

clerk_id
string | null

Client assigned clerk ID. Required for Retail client participants.

Maximum string length: 255
Example:

"CLK-007"

terminal_id
string | null

Client assigned terminal ID. Required for Retail client participants.

Maximum string length: 255
Example:

"TERM-042"

ledger
object

Required for clients configured for ledger service. Exclude entirely if not applicable to your integration.

Response

Payment accepted successfully

status
integer

Numeric code describing the status of the API request. 100 = Success.

Example:

100

client_message
string

Text description associated with the status code.

Example:

"Success"

data
object