Post payment

Enables users to submit payments to the platform. It supports posting debits and credits to an account, as well as facilitating fund transfers between accounts.

To post a credit you must provide a credit object with valid credit (processing_code) and destination (external_account_id) values.

Similarly, 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 that represent the credit and debit legs of the operation. If you provide an earmark_id value inside the debit object, the transferred amount is withdrawn directly from the earmark balance.

To post a forced transfer, you must set both credit and debit along with the force_post property to true.
Note: This does not support forced transfers from earmark balance.

See the Examples drop-down menu for sample payloads for each of these payment types.

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

NOTES:

  • This endpoint requires an account-specific access token. Getting an account token requires you to call the Get OpenID access token endpoint with an external account ID. Tokens can expire quickly, which can result in an Unauthorized message.
  • The metadata field is updated to include 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 and any other type mismatch results in an error as mapped under responses section.
  • If you make a single leg earmark payment (debit) or transfer from earmark balance, the events Authorization created and Transaction created are generated with one additional field:
    • The metadata (Authorization created) or details (Transaction created) field is updated to include corporate_metadata with the following fields:
      • authorization_type: Included to identify the payment type as corporate-earmark-payment or corporate-earmark-transfer.
  • If you make a forced transfer (debit and credit info provided, and force_post set to true):
    • The events Authorization created and Transaction created are generated with additional fields:
      • The corporate_metadata inside metadata (authorization-event-1) or the details (creation-1) fields are updated to include:
        • authorization_type: Included to identify the payment type as corporate-force-transfer in the debit authorization event.
        • credit_tracking_id: Included in the corporate_metadata debit event to identify the credit operation tracking ID.
        • debit_tracking_id: Included in the corporate_metadata credit event to identify the debit operation tracking ID.
    • The response returns only authorization_id from debit.
    • If the account has any reason-based force payment restrictions, the operation fails. The reasons that restrict force credit or debit operations are:
      • Credit Only - No Force Debit Allowed
      • Debit Only - No Force Credit Allowed
      • Any - No Force Allowed
      • Manual - No Force Allowed
    • To get respective reason IDs, refer to the List account status reasons endpoint.
  • If you make an earmark payment transfer (debit, credit), the events Authorization created and Transaction created are generated with additional fields:
    • The corporate_metadata inside metadata Authorization created or the details in Transaction created are updated to include:
      • earmark_id: Included to identify the payment type as corporate-earmark-transfer in the consumer authorization event.
      • credit_tracking_id: Included in the corporate_metadata debit event to identify the credit operation tracking ID.
      • debit_tracking_id : Included in the corporate_metadata credit event to identify the debit operation tracking ID.
    • The response body returns only authorization_id from debit. The authorization_id from credit is generated asynchronously.

Each payment operation created generates the following events:

Language
Authorization
Bearer
JWT
Click Try It! to start a request and see the response here!