---
title: "Post multi-leg payment"
method: POST
path: "/corporate/v3/payments/multileg"
tags: ["Payments"]
---

# Post multi-leg payment

`POST /corporate/v3/payments/multileg`

## Request

- Base URL: `https://sandbox.pismolabs.io`
- URL: `https://sandbox.pismolabs.io/corporate/v3/payments/multileg`
- Auth: HTTP bearer

Allow you to submit a payment with multiple legs to the platform. The payments are processed asynchronously and must contain at least two legs, but no more than 20.
The payload contains `debits` and `credits` lists. These lists include legs that follow the requirements of `credit` and `debit` objects in the [Post payment](ref:corporate-v2-post-payments) endpoint.
For information about multi-leg payments, refer to the [Multi-leg payments](doc:multi-leg-payments) guide.
**NOTES**:
  - To find the correct reason IDs, refer to the [List account status reasons](ref:get-accounts-v1-accounts-status-reasons) endpoint.
  - This endpoint does not support forced transfers from an earmark balance.
  - For error handling, see [Error handling mechanism](doc:payment-overview#error-handling-mechanism) in _Payment overview_.
  - **Processing sequence**: Debit legs are always processed before credit legs. Within each group, the sequence is not guaranteed, and the order of execution among debits or among credits is non-deterministic.

Each leg generates the following events:
- [Platform authorization created](https://developers.pismo.io/events/docs/platform-authorization-platform-authorization-1)
- If flex controls are configured, a [Flex control evaluated](https://developers.pismo.io/events/docs/rules-evaluation-requested-1) event is triggered.
Additionally, the following events are generated for multi-leg payments:
- [Multi-leg payment lifecycle created](https://developers.pismo.io/events/docs/corporate-multi-leg-creation-2)
- [Multi-leg payment lifecycle status changed](https://developers.pismo.io/events/docs/corporate-multi-leg-status-change-2)
See [Data and reporting](doc:data-reporting-overview) for more information about events and setting up event notifications.

## Request body

- MultiLegPaymentV3Request
  - `multileg_id` string, required: A unique multileg payment identifier provided by the client. If an existing `multileg_id` already exists in the system, the API returns a `409` error. This field is: - Unique within the Organization. - Immutable — It can't be updated. - Not recyclable — You can't reuse a `multileg_id`.
  - `metadata` MultilegMetadata: Key-value pairs containing data intended for storage in the Pismo system.<br> **Note**: This field must not be used to send Personally Identifiable Information (PII), Payment Card Industry (PCI) data, or any sensitive/regulated information. Metadata fields are intended for operational, non-sensitive data only. For sensitive data, use the specific parameters designed for that purpose. For more information, refer to [Get started with Pismo APIs](ref:get-started-with-pismo-apis).
  - `debits` DebitLegV3Request[]
    - `tracking_id` string, required: A unique payment tracking number provided by the client. If an existing `tracking_id` already exists in the system, the API returns a `400` error.<br> For information about tracking IDs, see [Tracking ID requirement](https://developers.pismo.io/pismo-docs/docs/payment-overview#tracking-id-requirement). This field is: - Unique within the Organization. - Immutable: This field cannot be updated. - Not recyclable: `tracking_id` cannot be reused.
    - `amount` number, float, required: Transaction amount
    - `currency` string, required: 3-letter code in ISO 4217-compliant format for the currency used in the transaction.
    - `external_account_id` string, required: External ID of the account to which the transaction is posted.
    - `processing_code` string: Processing code used for posting the transaction. The code must have a balance impact compatible with the operation type `debit` or `credit`. To list the organization processing codes, use the [List processing codes](https://developers.pismo.io/pismo-docs/reference/get-processing-code-by-tenant) endpoint.
    - `soft_descriptor` string: Brief description that helps to identify a particular transaction on the bank statement.
    - `force_post` boolean: If `true`, the operation is performed regardless of the account status, balance, or state, unless the account is closed.<br> The force operation fails if the account has any reason-based force payment restrictions, and the operation violates any of those restrictions. The reasons that restrict force credit or debit operations are: - `ALL_NO_FORCE_ALLOWED`: Debits and credits are permitted, but force operations are not allowed. - `CREDIT_ONLY_NO_FORCE_DEBIT_ALLOWED`: Only credit and force credit are allowed. - `FORCE_CREDIT_ONLY`: Debits, credits and force debit are not allowed. - `NONE_NO_FORCE_ALLOWED`: Debits, credits, force debits, and force credits are not allowed.
    - `validation_rules` ValidationRules: Rules that determine which validations are executed during the payment process.<br> Available validation rules: - `LEDGER` - `ACCOUNT_STATUS` - `FLEX_CONTROLS` - `RATES`<br> `force` is only supported for `LEDGER`. `override` is supported for `ACCOUNT_STATUS`, `FLEX_CONTROLS`, and `RATES`.
    - `payment_datetime` string, date-time: Date and time of the payment. Specifying a `payment_datetime` value impacts the account balance history.<br> <b>Notes</b>: - The payment datetime is in ISO 8601 format. - You can backdate payments a maximum of 390 calendar days. You can postdate payments a maximum of 10 calendar days.
    - `business_date` string, date: Specifying a `business_date` value impacts the account balance history.<br> <b>Notes</b>: - The business date is in ISO 8601 format. - The business date allows users to designate the balance history cycle in which a payment is posted. - You can specify a `business_date` within the current working day or up to one working day before or after.
    - `channel` string: Alphanumeric channel code identifier
    - `skip_account_date_validation` boolean: If `FALSE`, the `payment_datetime` is validated against the account creation date and time. If `TRUE`, the validation is skipped.
    - `earmark_id` string: ID of the earmark from which the amount is withdrawn. The earmark ID is generated by the [Create Earmark](https://developers.pismo.io/pismo-docs/reference/post-corporate-v2-earmarks) endpoint.
    - `instant_clearing` boolean: Whether the funds are available when the payment is posted (`true`) or not (`false`).
    - `metadata` MultilegMetadata: Key-value pairs containing data intended for storage in the Pismo system.<br> **Note**: This field must not be used to send Personally Identifiable Information (PII), Payment Card Industry (PCI) data, or any sensitive/regulated information. Metadata fields are intended for operational, non-sensitive data only. For sensitive data, use the specific parameters designed for that purpose. For more information, refer to [Get started with Pismo APIs](ref:get-started-with-pismo-apis).
  - `credits` CreditLegV3Request[]
    - `tracking_id` string, required: A unique payment tracking number provided by the client. If an existing `tracking_id` already exists in the system, the API returns a `400` error.<br> For information about tracking IDs, see [Tracking ID requirement](https://developers.pismo.io/pismo-docs/docs/payment-overview#tracking-id-requirement). This field is: - Unique within the Organization. - Immutable: This field cannot be updated. - Not recyclable: `tracking_id` cannot be reused.
    - `amount` number, float, required: Transaction amount
    - `currency` string, required: 3-letter code in ISO 4217-compliant format for the currency used in the transaction.
    - `external_account_id` string, required: External ID of the account to which the transaction is posted.
    - `processing_code` string: Processing code used for posting the transaction. The code must have a balance impact compatible with the operation type `debit` or `credit`. To list the organization processing codes, use the [List processing codes](https://developers.pismo.io/pismo-docs/reference/get-processing-code-by-tenant) endpoint.
    - `soft_descriptor` string: Brief description that helps to identify a particular transaction on the bank statement.
    - `force_post` boolean: If `true`, the operation is performed regardless of the account status, balance, or state, unless the account is closed.<br> If the account has any reason-based force payment restrictions, and the operation violates any of those restrictions, the force operation fails. The reasons that restrict force credit or debit operations are: - `ALL_NO_FORCE_ALLOWED`: Debits and credits are permitted, but force operations are not allowed. - `ALL_NO_FORCE_ALLOWED`: Debits and credits are permitted, but force operations are not allowed. - `DEBIT_ONLY_NO_FORCE_CREDIT_ALLOWED`: Only debits and force debits are allowed. - `FORCE_DEBIT_ONLY`: Debits, credits, and force credits are not allowed. - `NONE_NO_FORCE_ALLOWED`: Debits, credits, force debits, and force credits are not allowed.
    - `validation_rules` ValidationRules: Rules that determine which validations are executed during the payment process.<br> Available validation rules: - `LEDGER` - `ACCOUNT_STATUS` - `FLEX_CONTROLS` - `RATES`<br> `force` is only supported for `LEDGER`. `override` is supported for `ACCOUNT_STATUS`, `FLEX_CONTROLS`, and `RATES`.
    - `payment_datetime` string, date-time: Date and time of the payment. Specifying a `payment_datetime` value impacts the account balance history.<br> <b>Notes</b>: - The payment datetime is in ISO 8601 format. - You can backdate payments a maximum of 390 calendar days. You can postdate payments a maximum of 10 calendar days.
    - `business_date` string, date: Specifying a `business_date` value impacts the account balance history.<br> <b>Notes</b>: - The business date is in ISO 8601 format. - The business date allows users to designate the balance history cycle in which a payment is posted. - You can specify a `business_date` within the current working day or up to one working day before or after.
    - `channel` string: Alphanumeric channel code identifier
    - `skip_account_date_validation` boolean: If `FALSE`, the `payment_datetime` is validated against the account creation date and time. If `TRUE`, the validation is skipped.
    - `instant_clearing` boolean: Whether the funds are available when the payment is posted (`true`) or not (`false`).
    - `metadata` MultilegMetadata: Key-value pairs containing data intended for storage in the Pismo system.<br> **Note**: This field must not be used to send Personally Identifiable Information (PII), Payment Card Industry (PCI) data, or any sensitive/regulated information. Metadata fields are intended for operational, non-sensitive data only. For sensitive data, use the specific parameters designed for that purpose. For more information, refer to [Get started with Pismo APIs](ref:get-started-with-pismo-apis).

## Response `202`

Accepted

- MultiLegPaymentV3Response
  - `multileg_id` string: A unique multileg payment identifier provided by the client. If an existing `multileg_id` already exists in the system, the API returns a `409` error. This field is: - Unique within the Organization. - Immutable — It can't be updated. - Not recyclable — You can't reuse a `multileg_id`.
  - `metadata` MultilegMetadata: Key-value pairs containing data intended for storage in the Pismo system.<br> **Note**: This field must not be used to send Personally Identifiable Information (PII), Payment Card Industry (PCI) data, or any sensitive/regulated information. Metadata fields are intended for operational, non-sensitive data only. For sensitive data, use the specific parameters designed for that purpose. For more information, refer to [Get started with Pismo APIs](ref:get-started-with-pismo-apis).
  - `debits` DebitLegV3Response[]
    - `tracking_id` string: A unique payment tracking number provided by the client. If an existing `tracking_id` already exists in the system, the API returns a `400` error.<br> For information about tracking IDs, see [Tracking ID requirement](https://developers.pismo.io/pismo-docs/docs/payment-overview#tracking-id-requirement). This field is: - Unique within the Organization. - Immutable: This field cannot be updated. - Not recyclable: `tracking_id` cannot be reused.
    - `external_account_id` string: External ID of the account to which the transaction is posted.
    - `amount` number, float: Transaction amount
    - `processing_code` string: Processing code used for posting the transaction. The code must have a balance impact compatible with the operation type `debit` or `credit`. To list the organization processing codes, use the [List processing codes](https://developers.pismo.io/pismo-docs/reference/get-processing-code-by-tenant) endpoint.
    - `soft_descriptor` string: Brief description that helps to identify a particular transaction on the bank statement.
    - `currency` string: 3-letter code in ISO 4217-compliant format for the currency used in the transaction.
    - `force_post` boolean: If `true`, the operation is performed regardless of the account status, balance, or state, unless the account is closed.<br> The force operation fails if the account has any reason-based force payment restrictions, and the operation violates any of those restrictions. The reasons that restrict force credit or debit operations are: - `ALL_NO_FORCE_ALLOWED`: Debits and credits are permitted, but force operations are not allowed. - `CREDIT_ONLY_NO_FORCE_DEBIT_ALLOWED`: Only credit and force credit are allowed. - `FORCE_CREDIT_ONLY`: Debits, credits and force debit are not allowed. - `NONE_NO_FORCE_ALLOWED`: Debits, credits, force debits, and force credits are not allowed.
    - `validation_rules` ValidationRules: Rules that determine which validations are executed during the payment process.<br> Available validation rules: - `LEDGER` - `ACCOUNT_STATUS` - `FLEX_CONTROLS` - `RATES`<br> `force` is only supported for `LEDGER`. `override` is supported for `ACCOUNT_STATUS`, `FLEX_CONTROLS`, and `RATES`.
    - `payment_datetime` string, date-time: Date and time of the payment. Specifying a `payment_datetime` value impacts the account balance history.<br> <b>Notes</b>: - The payment datetime is in ISO 8601 format. - You can backdate payments a maximum of 390 calendar days. You can postdate payments a maximum of 10 calendar days.
    - `business_date` string, date: Specifying a `business_date` value impacts the account balance history.<br> <b>Notes</b>: - The business date is in ISO 8601 format. - The business date allows users to designate the balance history cycle in which a payment is posted. - You can specify a `business_date` within the current working day or up to one working day before or after.
    - `channel` string: Alphanumeric channel code
    - `skip_account_date_validation` boolean: If `FALSE`, the `payment_datetime` is validated against the account creation date and time. If `TRUE`, the validation is skipped.
    - `earmark_id` string: ID of the earmark from which the amount is withdrawn. The earmark ID is generated by the [Create Earmark](https://developers.pismo.io/pismo-docs/reference/post-corporate-v2-earmarks) endpoint.
    - `instant_clearing` boolean: Whether the funds are available when the payment is posted (`true`) or not (`false`).
    - `metadata` MultilegMetadata: Key-value pairs containing data intended for storage in the Pismo system.<br> **Note**: This field must not be used to send Personally Identifiable Information (PII), Payment Card Industry (PCI) data, or any sensitive/regulated information. Metadata fields are intended for operational, non-sensitive data only. For sensitive data, use the specific parameters designed for that purpose. For more information, refer to [Get started with Pismo APIs](ref:get-started-with-pismo-apis).
  - `credits` CreditLegV3Response[]
    - `tracking_id` string: A unique payment tracking number provided by the client. If an existing `tracking_id` already exists in the system, the API returns a `400` error.<br> For information about tracking IDs, see [Tracking ID requirement](https://developers.pismo.io/pismo-docs/docs/payment-overview#tracking-id-requirement). This field is: - Unique within the Organization. - Immutable: This field cannot be updated. - Not recyclable: `tracking_id` cannot be reused.
    - `external_account_id` string: External ID of the account to which the transaction is posted.
    - `amount` number, float: Transaction amount
    - `processing_code` string: Processing code used for posting the transaction. The code must have a balance impact compatible with the operation type `debit` or `credit`. To list the organization processing codes, use the [List processing codes](https://developers.pismo.io/pismo-docs/reference/get-processing-code-by-tenant) endpoint.
    - `soft_descriptor` string: Brief description that helps to identify a particular transaction on the bank statement.
    - `currency` string: 3-letter code in ISO 4217-compliant format for the currency used in the transaction.
    - `force_post` boolean: If `true`, the operation is performed regardless of the account status, balance, or state, unless the account is closed.<br> If the account has any reason-based force payment restrictions, and the operation violates any of those restrictions, the force operation fails. The reasons that restrict force credit or debit operations are: - `ALL_NO_FORCE_ALLOWED`: Debits and credits are permitted, but force operations are not allowed. - `ALL_NO_FORCE_ALLOWED`: Debits and credits are permitted, but force operations are not allowed. - `DEBIT_ONLY_NO_FORCE_CREDIT_ALLOWED`: Only debits and force debits are allowed. - `FORCE_DEBIT_ONLY`: Debits, credits, and force credits are not allowed. - `NONE_NO_FORCE_ALLOWED`: Debits, credits, force debits, and force credits are not allowed.
    - `validation_rules` ValidationRules: Rules that determine which validations are executed during the payment process.<br> Available validation rules: - `LEDGER` - `ACCOUNT_STATUS` - `FLEX_CONTROLS` - `RATES`<br> `force` is only supported for `LEDGER`. `override` is supported for `ACCOUNT_STATUS`, `FLEX_CONTROLS`, and `RATES`.
    - `payment_datetime` string, date-time: Date and time of the payment. Specifying a `payment_datetime` value impacts the account balance history.<br> <b>Notes</b>: - The payment datetime is in ISO 8601 format. - You can backdate payments a maximum of 390 calendar days. You can postdate payments a maximum of 10 calendar days.
    - `business_date` string, date: Specifying a `business_date` value impacts the account balance history.<br> <b>Notes</b>: - The business date is in ISO 8601 format. - The business date allows users to designate the balance history cycle in which a payment is posted. - You can specify a `business_date` within the current working day or up to one working day before or after.
    - `channel` string: Alphanumeric channel code
    - `skip_account_date_validation` boolean: If `FALSE`, the `payment_datetime` is validated against the account creation date and time. If `TRUE`, the validation is skipped.
    - `instant_clearing` boolean: Whether the funds are available when the payment is posted (`true`) or not (`false`).
    - `metadata` MultilegMetadata: Key-value pairs containing data intended for storage in the Pismo system.<br> **Note**: This field must not be used to send Personally Identifiable Information (PII), Payment Card Industry (PCI) data, or any sensitive/regulated information. Metadata fields are intended for operational, non-sensitive data only. For sensitive data, use the specific parameters designed for that purpose. For more information, refer to [Get started with Pismo APIs](ref:get-started-with-pismo-apis).

## Other responses

- `400`: Bad request
- `403`: The request has been lost
- `409`: Conflict
- `500`: Internal Server Error

---

[API](https://skmtc.dev/pismo/apis/banking-transaction-banking.md) - [All operations](https://skmtc.dev/pismo/apis/banking-transaction-banking/llms.txt) - [OpenAPI document](https://skmtc.dev/pismo/apis/banking-transaction-banking/revisions/1334306c9303?raw)