Pay via Check lets you send funds from a Passport Account as a physical check mailed to a recipient's address. It's useful when electronic payout methods (ACH or Wire) aren't available or aren't preferred, and when you need to include printed remittance information alongside the payment. For the full field list, jump to the Request reference.

Unlike ACH or Wire, Check does not support one-time destinations: the recipient's mailing address must already be registered in Passport, either as a saved mailing address or on a Contact, before you create the transaction.

Common use cases

• Pay vendors or suppliers by mailed check
• Send a check to a saved payee managed as a Contact
• Mail funds to your own registered mailing address
• Record a check issued outside Passport for reconciliation

Make your first payout

The fastest way to see a check payout work: send the minimal request below, then track the result. This pays a saved payee (Contact) with just the required fields; the full set of options is in the Request reference further down.

POST /v1/customer/id/{id}/transaction

{
  "externalId": "check-first-payout-001",
  "method": "CHECK",
  "amount": "1500.00",
  "purpose": "Vendor Payment",
  "source":      { "account": { "externalId": "passport-account-001" } },
  "destination": {
    "contact": {
      "externalId": "vendor-contact-001",
      "mailingAddress": { "externalId": "vendor-address-001" }
    }
  }
}

You'll get back a transaction with status: SCHEDULED. Store the returned id (and your externalId); you'll use them to track the check and for any follow-up actions, such as a stop request.

Scenarios

Every check payout follows the same path (submit, validate, print, mail, settle), and the only thing that changes is the destination (and whether you're recording an externally issued check). Pick the scenario that matches the problem you're solving.

sequenceDiagram
    participant You as Your application
    participant PCE as PCE
    participant Mail as Print & mail provider
    You->>PCE: POST /transaction (unique externalId)
    PCE->>PCE: Validate request
    PCE-->>You: 201 Created (status: SCHEDULED)
    PCE->>Mail: Print & dispatch check (PROCESSING, IN_DELIVERY)
    Mail-->>PCE: Delivery confirmation
    PCE-->>You: Webhook (DELIVERED, COMPLETED, or FAILED/STOPPED)

The status values above are described under Statuses.

Before you begin (all scenarios)

• The Passport Account you're paying from is active and has enough balance to cover the payout.
• The destination is already registered in Passport (a saved mailing address or a Contact). Check payouts don't accept inline, one-time bank or address details.

Each scenario below adds one requirement specific to its destination.

Scenario 1: Pay a vendor or payee you pay regularly

(third-party recipient saved as a Contact)

Use this when you're mailing a check to someone other than yourself (a vendor, supplier, or contractor) and you'll pay them again. You save their mailing details once as a Contact, then reference the Contact on every payout.

You'll also need: the recipient saved as a Contact with a linked mailing address. See Save Payees as Contacts.

Request

POST /v1/customer/id/{id}/transaction

{
  "method": "CHECK",
  "type": "REGULAR",
  "amount": "2200.00",
  "purpose": "Vendor Payment",
  "source":      { "account": { "externalId": "passport-account-001" } },
  "destination": {
    "contact": {
      "id": "4019600",
      "mailingAddress": { "id": "1048888" }
    }
  },
  "processingDetail": { "deliveryMode": "TWO_DAY", "memo": "Q4 Services" }
}

Response

{
  "resourceName": "transaction",
  "url": "/v1/customer/id/4225975/transaction/id/230491610",
  "id": 230491610,
  "externalId": "check-contact-2dd0",
  "status": "SCHEDULED",
  "statusDate": "06/30/2026 14:20:55",
  "amount": 2200,
  "method": "CHECK",
  "purpose": "Vendor Payment",
  "type": "REGULAR",
  "transactionClass": "SEND",
  "statusReason": "On User Request",
  "source": {
    "account": { "resourceName": "account", "id": 9915272, "url": "/v1/customer/id/4225975/account/id/9915272" }
  },
  "destination": {
    "contact": { "resourceName": "contact", "id": 4019600, "url": "/v1/customer/id/4225975/contact/id/4019600" }
  }
}

You'll track this transaction through to delivery and settlement with webhooks; see Track the transaction below.

Scenario 2: Mail a check to an address you maintain

(pre-registered mailing address)

Use this when the check should go to a mailing address you already manage in Passport, for example your own registered address or an address you maintain directly, rather than a third-party payee saved as a Contact. You reference the saved mailing address by id, and optionally name the payee printed on the check.

You'll also need: the destination mailing address registered via POST /v1/customer/id/{id}/mailingAddress. Optionally, a registered payor address to print as the return address.

Request

POST /v1/customer/id/{id}/transaction

{
  "externalId": "check-address-001",
  "method": "CHECK",
  "type": "REGULAR",
  "amount": "1500.00",
  "purpose": "Vendor Payment",
  "source": {
    "account":      { "externalId": "passport-account-001" },
    "payorAddress": { "id": "6249852" }
  },
  "destination": {
    "address":   { "id": "6249852" },
    "payeeName": "Acme Supplies Inc"
  },
  "processingDetail": { "deliveryMode": "STANDARD", "memo": "Invoice #INV-2024-001" }
}

Response

{
  "resourceName": "transaction",
  "url": "/v1/customer/id/4225975/transaction/id/230491621",
  "id": 230491621,
  "externalId": "check-address-001",
  "status": "SCHEDULED",
  "statusDate": "06/30/2026 16:04:30",
  "amount": 1500,
  "method": "CHECK",
  "purpose": "Vendor Payment",
  "type": "REGULAR",
  "transactionClass": "SEND",
  "statusReason": "On User Request",
  "source": {
    "account": { "resourceName": "account", "id": 9915272, "url": "/v1/customer/id/4225975/account/id/9915272" }
  },
  "destination": {
    "address": { "resourceName": "address", "id": 6249852, "url": "/v1/customer/id/4225975/mailingAddress/id/6249852" }
  }
}

Track it through to delivery and settlement with webhooks; see Track the transaction below.

Scenario 3: Record a check issued outside Passport

(externally issued check, type: EXTERNAL)

Use this to record a check that was issued outside the platform (for example, reconciling a check your team cut manually) so the debit is reflected against the Passport Account. Set type to EXTERNAL and provide the date the check was issued in processingDetail.checkIssueDate. The destination is still a registered mailing address.

You'll also need: the destination mailing address registered, and the original check's issue date.

Request

POST /v1/customer/id/{id}/transaction

{
  "externalId": "check-external-4c2e",
  "method": "CHECK",
  "type": "EXTERNAL",
  "amount": "100.00",
  "purpose": "ICLDebitAutoMatch",
  "source":      { "account": { "id": "4035159" } },
  "destination": {
    "address":   { "id": "1209279" },
    "payeeName": "Jane Smith"
  },
  "processingDetail": {
    "memo": "Manual check reconciliation",
    "checkIssueDate": "10/14/2025"
  }
}

Response

{
  "resourceName": "transaction",
  "url": "/v1/customer/id/4225975/transaction/id/230491633",
  "id": 230491633,
  "externalId": "check-external-4c2e",
  "status": "SCHEDULED",
  "statusDate": "06/30/2026 20:02:50",
  "amount": 100,
  "method": "CHECK",
  "type": "EXTERNAL",
  "purpose": "ICLDebitAutoMatch",
  "statusReason": "On User Request",
  "destination": {
    "address": { "resourceName": "address", "id": 1209279, "url": "/v1/customer/id/4225975/mailingAddress/id/1209279" }
  }
}

Track it through to settlement with webhooks; see Track the transaction below.

Track the transaction

Subscribe to webhooks or GET the transaction to follow a check through printing, delivery, and settlement without polling. Because a check settles only after it's printed, mailed, and delivered, watch for the status change rather than assuming success on submit. The statuses, the webhook payload, and the event types all live in Transaction lifecycle.

Request reference

The complete set of fields for the create-transaction request. Scenarios above use subsets of these.

Core parameters

Destination types

The destination object takes one of two shapes; both reference a destination already registered in Passport. Check payouts do not accept inline, one-time details.

Registered mailing address (mail to an address you maintain, Scenario 2)

Saved Contact (pay a third party you've saved, Scenario 1)

Processing detail

The processingDetail object carries additional processing instructions. Optional as a whole, but certain fields may be required depending on your program's configuration (set by your Program Manager, the platform partner you onboarded through).

External check fields

These apply only when type is EXTERNAL (see Scenario 3).

Validation

The prerequisites above are the validations, and PCE enforces them when you submit. A submission is checked synchronously; if a check fails, the request returns an error and no transaction is created. Submission checks:

• Required fields are present and correctly formatted.
• The source Passport Account is active and has enough balance to cover the payout.
• The destination resolves to a registered mailing address or a saved Contact (no inline, one-time details).

Other conditions can only be judged once the check is in flight, such as an inactive or blocked account, a compliance hold, or a delivery failure. These surface after creation as PENDING, FAILED, or STOPPED; see Statuses. For error codes, see Error Codes and Messages.

Delivery modes

Check payouts support three delivery modes, which determine how and when the physical check is delivered to the recipient.

Statuses

Pay via Check uses the shared transaction lifecycle for the common statuses (SCHEDULED, PROCESSING, COMPLETED, FAILED, PENDING, CANCELLED), their reasons, and how to track. Check adds delivery-specific statuses:

If a check fails or is stopped

A check moves to FAILED when it can't be processed within the allowed interval (for example insufficient funds, a blocked account, or an OFAC verification failure). A PENDING check is on hold because an account is inactive or blocked, or OFAC/CIP verification is incomplete. After a check is printed, you can raise a stop request, which moves it to STOPPED, if it's lost or incorrect. Resolve the underlying issue and, where needed, submit a new check. For specific reason codes, see Error Codes and Messages.

Go live

Before you move from sandbox to production, confirm:

• Your webhook endpoint is subscribed and validating signatures.
• Idempotency is tested; retries with the same externalId don't create duplicate checks.
• Failure, return, and stop-request paths are tested in the sandbox (see the FAILED and STOPPED status reasons).
• Delivery modes (STANDARD, TWO_DAY, OVERNIGHT) behave as expected for your program.
• Destinations (mailing addresses and Contacts) are registered ahead of time; there are no one-time check destinations.

Best practices

General practices (set a unique externalId, subscribe to webhooks, test in sandbox) are in Getting Started. Specific to paying via check:

Next steps

See also

• Save Payees as Contacts: save the payees you mail checks to
• Pay via ACH and Pay via Wire (Domestic): electronic payout methods
• Transfer funds: move money between accounts you own
• Error Codes and Messages: resolve a failed or stopped check