Check

Check payments let merchants record paper checks as a tender type in the Checkout API. Like cash, these transactions are primarily for reporting and reconciliation — the merchant still needs to take each physical check to the bank for deposit.

Although checks and ACH both draw from a customer’s bank account, checks are more manual, slower to clear, and carry their own fraud and rejection risks.

Prerequisites and limitations

• Prerequisites: Access to the PCE /payment API and a merchant account configured for Checkout.
• Limitations: Check transactions are reporting-only in PCE. The merchant must still physically deposit the checks at the bank. Funds can be reversed later if the check is fraudulent, returned, or stopped.

Checks vs. ACH

Both check and ACH payments use bank account information, but the flows are very different:

• Checks (this page):

  • Customer hands the merchant a physical check.
  • The merchant records the payment in PCE and then takes the check to the bank to deposit it.
  • Clearing time and risk are tied to traditional paper check processing.

• ACH:

  • Merchant (or customer through a virtual terminal) enters bank details electronically.
  • The ACH processor handles debits and deposits — no trips to the bank.
  • Still subject to returns and fraud, but the movement of funds is automated.

When to Use Check Payments

Use check tender when:

• You want to offer checks as an additional payment method alongside cards, ACH, and cash.
• You need check payments to appear in the same reports and reconciliation flows as other tender types.
• Your business regularly receives checks and wants a consistent way to log them in PCE.

Things to Keep in Mind

• Reporting-only tender: PCE does not deposit check funds for you. The merchant must manually deposit checks to their bank account.

• Risk and reversals: Checks and ACH share common drawbacks:

  • It can take several days to learn a check is fraudulent or has insufficient funds.
  • Customers can request a stop payment on a check even after receiving goods or services.
  • Merchants risk delivering products or services and then having the check reversed later.

• Operational impact: Merchants should factor check risk and delay into their fulfillment process, especially for high-value or service-based transactions.

Make a Check Payment Request

Check payments are created by posting to the /payment endpoint with tenderType set to "Check" and bank account details in the bankAccount object.

Endpoint

Steps

1. Set up the HTTP request

   • Use the POST method.
   • Call the /payment endpoint in the correct environment (sandbox or production).

2. Add authentication and headers

   • Send your username and password in the Authorization header using Basic auth.

     • Encode username:password as Base-64 and prefix with Basic .

   • Set the Content-Type header to application/json.

3. Provide bank account and contact details

   In the bankAccount object, the required fields can vary based on your merchant fraud settings. Generally:

   • contact.name is always required.
   • contact.phone and checkNumber are optional, but recommended for better traceability.

   Example payload:

   JSON

   {
     "merchantId": "4xxx0",
     "tenderType": "Check",
     "bankAccount": {
       "checkNumber": "123",
       "contact": {
         "name": "John Doe",
         "phone": "3432423423"
       }
     },
     "amount": 0.01
   }

   Key fields:

   • merchantId: Your merchant identifier.
   • tenderType: "Check" for check payments.
   • bankAccount.checkNumber: Optional check number.
   • bankAccount.contact.name: Name of the person or business on the check (required).
   • bankAccount.contact.phone: Optional phone number for follow-up.
   • amount: Check amount to record.

4. Verify the response

   • A successful request returns HTTP 201 Created.
   • The payment object’s status field should be Approved when the check payment record is created.