Create Transaction

Visit the About Transactions to learn more about Transaction methods, types, and requests parameters.

Response Codes

102 - Idempotent matched request currently processing

201 - Created, will include a Location response header

200 - Request Succeeded, but entity not created

400 - Bad Request, missing or invalid parameters

409 - Idempotent matched request already processed

422 - Request not process due to business constraints

ACH & RTP Transaction Requests

The initial status from the ACH & RTP transaction request will be PROCESSING.

• ACH
  • The initial PROCESSING status depends on the banking partner processing the ACH funds movement. Our team will discuss the status differences during the integration/onboarding process.
  • ACH transactions can be processed "same day" (business day) or the "standard" 3-5 days. The PAID or FAILED status update will trigger a webhook once the final status is known.
• RTP
  • The roundtrip RTP request could take up to 30 seconds. A webhook will be sent when a definitive status is known.

Card Transaction Requests - Instant Deposit and Instant Funding

Visa and Mastercard networks handle requests with expired cards differently.

• Visa will accept an expiration date in the past and attempt to process the transaction through the issuing bank. The bank will determine whether or not to honor the transaction. A Visa decline may result in action code 54.
• Mastercard will reject the transaction request. For this reason, we will validate the card expiration date before processing through Mastercard. If the card is expired, a 422 status code with ERR_CARD_ACCOUNT_EXPIRED will be returned in the API response.

Transaction ID with Error Response

The transaction_id parameter will not always be present in the error response body. Under certain 400 and 422 scenarios, the response is returned before processing of the transaction occurs.

ACH and AFT Refunds

Transactions can be logically linked by supplying the originating_transaction_id for the CREDIT (payout) transaction. Including the originating_transaction_id will add additional validation checks:

• Does the originating_transaction_id exist?
• Is the amount equal or less than the original transaction?

After processing the refund-oriented transaction, the original transaction status will update to REFUNDED or REFUND_PARTIAL.

ACH_REFUND is its own distinct method to link ACH_FUNDING transactions.

INSTANT_DEPOSIT can be used to link an INSTANT_FUNDING transaction.

API Example

Request

curl --request POST \
     --url https://test.api.interchecks.io/api/v2/payer_id/transactions \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "funding_options": {
    "risk_check": false,
    "user_segment": "DEFAULT"
  }
}
'```

#### Response Codes

- `200`  - Success
- `201`  - Resource Created
- `400`  - Bad Request
- `422`  - Unprocessable Entity

> Required Fields

- **payer_id**: string — Payer ID
- **recipient_id**: string — Recipient ID
- **account_id**: string — Payment Account ID
- **type**: enum — Direction of funds (`CREDIT` or `DEBIT`)
- **method**: enum — Transaction method (e.g., `INSTANT_DEPOSIT`, `ACH_FUNDING`, etc.)
- **amount**: double — Transaction amount
- **reference_id**: string — Transaction reference ID (optional)
- **memo**: string — Transaction memo (optional)
- **email**: string — Email override for ECHECK transactions (optional)
- **meta_params**: string — JSON string for reporting requirements. Please consult with the technical team.
- **originating_transaction_id**: string — Originating Transaction ID for ACH_REFUND transactions.
- **funding_options**: object — Required for funding transactions.
- **location**: object — Possibly required for compliance purposes.
- **Idempotency-Key**: string — Uniquely generated key.