---
title: "Schedule payment"
method: POST
path: "/corporate/v2/scheduled-payments"
tags: ["Payments"]
---

# Schedule payment

`POST /corporate/v2/scheduled-payments`

## Request

- Base URL: `https://sandbox.pismolabs.io/passport`
- URL: `https://sandbox.pismolabs.io/passport/corporate/v2/scheduled-payments`
- Auth: none declared

Schedule payments for a specified future date (`schedule_datetime`). For more information, refer to [Schedule payment overview](https://developers.pismo.io/pismo-docs/docs/scheduled-payments).

The payload for this request is similar to that of the [Post payment](https://developers.pismo.io/pismo-docs/reference/corporate-v2-post-payments) endpoint with the exception of the (`schedule_datetime`) property.

See [Data and reporting](https://developers.pismo.io/pismo-docs/docs/data-reporting-overview) for more information about events and setting up event notifications.

For more information on payments operations, see [Corporate Banking Launch Reference](https://developers.pismo.io/pismo-docs/docs/corporate-banking-launch-reference).

NOTE:
- This endpoint requires an account token - an access token encoded with an external account ID. Tokens can expire quickly, which can result in a `401 Unauthorized` message.
- For scheduled payments, validation of the transaction occurs only during the execution of the scheduled payment.

This endpoint generates the following events:
- [Platform authorization created](https://developers.pismo.io/events/docs/platform-authorization-platform-authorization-1)
- [Account balance changed](https://developers.pismo.io/events/docs/availables-change-available-1)
- [Current scheduled payment status displayed](https://developers.pismo.io/events/docs/corporate-schedule-payment-1)

See [Data and reporting](https://developers.pismo.io/pismo-docs/docs/data-reporting-overview) for more information about events and how to set up event notifications.

## Request body

- ScheduledPaymentV2Request
  - `amount` number, double, required: Fee amount.
  - `tracking_id` string, required: Customer created tracking ID. Must consist of alphanumeric characters (a-z, A-Z, 0-9), hyphens (-), and colons (:), with a length from 1 to 128. The Pismo platform uses this field to implement idempotency and prevent duplicates.
  - `soft_descriptor` string: Brief description that helps to identify a particular transaction on the bank statement.<br> <b>NOTES</b>: - To be able to send different `soft_descriptor` information for each payment leg in transfer operations, the `soft_descriptor` can be included in the primary or leg field. A conflict between the primary and a leg field results in an error as mapped in the responses section.
  - `credit` RequiredCreditTransaction: Credit transaction. To post a credit, you must provide a `credit` object with a valid credit processing code (`processing_code`) and destination (`external_account_id`).<br> To post a transfer, you must provide both credit and debit objects, representing the credit and debit legs of the operation, respectively.
    - `external_account_id` string, required: External ID of the account to which the transaction is posted.
    - `processing_code` string: Processing code for posting credit transactions. The code must have a credit balance impact. You can retrieve a list of the organization processing codes using [List processing codes](https://developers.pismo.io/pismo-docs/reference/get-processing-code-by-tenant).
    - `soft_descriptor` string: Brief description that helps to identify a particular transaction on the bank statement.<br> <b>NOTES</b>: - To be able to send different `soft_descriptor` information for each payment leg in transfer operations, the `soft_descriptor` can be included in the primary or leg field. A conflict between the primary and a leg field results in an error as mapped in the responses section.
    - `metadata` MetadataPayment: Key-value pairs containing data intended for storage in the Pismo system.<br> <b>NOTES</b>: - The `metadata` field includes a `corporate_metadata` object with the following fields: - `credit_external_account_id`: Included in the `corporate_metadata` field when it's provided in the credit leg. - `debit_external_account_id`: Included in the `corporate_metadata` field when it's provided in the debit leg. - `earmark_id`: Included in the `corporate_metadata` field when it's provided in the debit leg. - The `corporate_metadata` attribute must be an object. A type mismatch results in an error as mapped in the responses section. - To be able to send different `metadata` information for each payment leg in transfer operations, the `metadata` can be included in the primary or leg field. A conflict between the primary and a leg field results in an error as mapped in the responses section.<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](https://developers.pismo.io/pismo-docs/reference/get-started-with-pismo-apis).
  - `debit` RequiredDebitTransaction: Debit transaction. To post a debit you must provide a `debit` object. If you provide an `earmark_id` value inside the `debit` object, the payment amount is withdrawn directly from the earmark balance. The earmark ID is generated by the [Create earmark](https://developers.pismo.io/pismo-docs/reference/post-corporate-v2-earmarks) endpoint.<br> To post a transfer, you must provide both `credit` and `debit` objects, representing the credit and debit legs of the operation, respectively. If you provide an `earmark_id` value inside the `debit` object, the transferred amount is withdrawn directly from the earmark balance.
    - `external_account_id` string, required: External ID of the account to which the transaction is posted.
    - `processing_code` string: Processing code to be used for posting the debit transaction. List the organization processing codes in [List processing codes](https://developers.pismo.io/pismo-docs/reference/get-processing-code-by-tenant) endpoint.
    - `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.
    - `soft_descriptor` string: Brief description that helps to identify a particular transaction on the bank statement.<br> <b>NOTES</b>: - To be able to send different `soft_descriptor` information for each payment leg in transfer operations, the `soft_descriptor` can be included in the primary or leg field. A conflict between the primary and a leg field results in an error as mapped in the responses section.
    - `metadata` MetadataPayment: Key-value pairs containing data intended for storage in the Pismo system.<br> <b>NOTES</b>: - The `metadata` field includes a `corporate_metadata` object with the following fields: - `credit_external_account_id`: Included in the `corporate_metadata` field when it's provided in the credit leg. - `debit_external_account_id`: Included in the `corporate_metadata` field when it's provided in the debit leg. - `earmark_id`: Included in the `corporate_metadata` field when it's provided in the debit leg. - The `corporate_metadata` attribute must be an object. A type mismatch results in an error as mapped in the responses section. - To be able to send different `metadata` information for each payment leg in transfer operations, the `metadata` can be included in the primary or leg field. A conflict between the primary and a leg field results in an error as mapped in the responses section.<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](https://developers.pismo.io/pismo-docs/reference/get-started-with-pismo-apis).
  - `metadata` MetadataPayment: Key-value pairs containing data intended for storage in the Pismo system.<br> <b>NOTES</b>: - The `metadata` field includes a `corporate_metadata` object with the following fields: - `credit_external_account_id`: Included in the `corporate_metadata` field when it's provided in the credit leg. - `debit_external_account_id`: Included in the `corporate_metadata` field when it's provided in the debit leg. - `earmark_id`: Included in the `corporate_metadata` field when it's provided in the debit leg. - The `corporate_metadata` attribute must be an object. A type mismatch results in an error as mapped in the responses section. - To be able to send different `metadata` information for each payment leg in transfer operations, the `metadata` can be included in the primary or leg field. A conflict between the primary and a leg field results in an error as mapped in the responses section.<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](https://developers.pismo.io/pismo-docs/reference/get-started-with-pismo-apis).
  - `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.
  - `force_post` boolean: If `true`, the transaction is executed regardless of the accounts balance or state.<br> To post a forced transfer, you must specify both `credit` and `debit`, and set `force_post` to `true`.<br> Reason-based force payments: If the account has any reason-based force payment restrictions, and the operation violates any of those restrictions, it 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. - `CREDIT_ONLY_NO_FORCE_DEBIT_ALLOWED`: Only credits and force credits are allowed. - `FORCE_CREDIT_ONLY`: Debits, credits, and force debits are not allowed. - `FORCE_DEBIT_ONLY`: Debits, credits, and force credits are not allowed. - `DEBIT_ONLY_NO_FORCE_CREDIT_ALLOWED`: Only debits and force debits are allowed. - `NONE_NO_FORCE_ALLOWED`: Debits, credits, force debits, and force credits are not allowed.<br> <b>NOTE</b>: Forced transfers from an earmark balance are not supported when `credit`, `debit`, or `earmark_id` are specified.
  - `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
  - `instant_clearing` boolean: Whether the funds are available when the payment is posted (`true`) or not (`false`).
  - `schedule_datetime` string, required: Date to schedule the process. RFC 3339 value, i.e., "2023-04-12T23:20:50.52Z".

## Response `201`

Created

- ScheduledPaymentResponse
  - `id` string: ID used to reference the scheduled payment for subsequent operations.

## Other responses

- `400`: Bad request
- `401`: Unauthorized
- `403`: The request has been lost
- `500`: Internal server error

---

[API](https://skmtc.dev/pismo/apis/platform-authentication.md) - [All operations](https://skmtc.dev/pismo/apis/platform-authentication/llms.txt) - [OpenAPI document](https://skmtc.dev/pismo/apis/platform-authentication/revisions/935b62e16de4?raw)
