Schedule payment

post

https://sandbox.pismolabs.io/corporate/v2/scheduled-payments

Schedule payments for a specified future date (schedule_datetime). For more information, refer to Schedule payment overview.

The payload for this request is similar to that of the Post payment endpoint with the exception of the (schedule_datetime) property.

See Data and reporting for more information about events and setting up event notifications.

For more information on payments operations, see Corporate Banking Launch Reference.

NOTE:

This endpoint requires an account token - an access token encoded with a Pismo 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:

See Data and reporting for more information about events and how to set up event notifications.

Recent Requests

Time	Status	User Agent
Retrieving recent requests…

Loading…

Body Params

Request body

amount

object

required

Amount

tracking_id

string

required

length between 1 and 43

A unique payment tracking number provided by the client. If an existing tracking_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 tracking_id.

soft_descriptor

string

length between 0 and 100

Brief description that helps to identify a particular transaction on the bank statement.
NOTES:

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

object

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).
To post a transfer, you must provide both credit and debit objects, representing the credit and debit legs of the operation, respectively.

debit

object

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 endpoint.
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.

metadata

object

Key-value pairs containing data intended for storage in the Pismo system.
NOTES:

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.

skip_account_date_validation

boolean

Defaults to false

If FALSE, the payment_datetime is validated against the account creation date and time. If TRUE, the validation is skipped.

force_post

boolean

Defaults to false

If true, the transaction is executed regardless of the accounts balance or state.
To post a forced transfer, you must specify both credit and debit, and set force_post to true.
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.
NOTE: Forced transfers from an earmark balance are not supported when credit, debit, or earmark_id are specified.

validation_rules

object

Rules that determine which validations are executed during the payment process.
Available validation rules:

LEDGER
ACCOUNT_STATUS

payment_datetime

date-time

Date and time of the payment. Specifying a payment_datetime value impacts the account balance history.
Notes:

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

date

Specifying a business_date value impacts the account balance history.
Notes:

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

length between 1 and 20

Alphanumeric channel code identifier

instant_clearing

boolean

Whether the funds are available when the payment is posted (true) or not (false).

schedule_datetime

date-time

required

The date and time when the transaction is scheduled to occur. Required for scheduled payments. Format = yyyy-mm-dd:hr:mm:ss.

Responses

403

The request has been lost

Schedule payment

Changelog

Support

Pismo is here to help

201Created

400Bad request

401Unauthorized

500Internal Server Error