> Visit the [About Transactions](https://docs-v2.interchecks.com/reference/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

```bash
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.