Post multi-leg payment (deprecated)

Enables users to submit payments with multiple legs to the platform. The payments are processed asynchronously and must contain at least two legs, but no more than twenty.

The payload contains debits and credits lists. These lists include legs that follow the requirements of the credit and debit objects in the Post a payment endpoint.

See the Examples drop-down menu for a sample payload.

NOTES:

• A single tracking ID must be provided. This is referred to as the original tracking ID.
• A child tracking ID is generated for each leg. These tracking IDs are created by combining a control suffix with the original tracking ID. The authorization event generated by each leg includes the same corporate_metadata attribute that contains an original_tracking_id field. This field establishes the connection between the individual leg and the original tracking ID associated with the initial multi-leg payment request.
• If the account has any reason-based force payment restrictions, a force operation (force_post set to true) 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 find the correct reason IDs, refer to the List account status reasons endpoint.
• This endpoint does not support forced transfers from an earmark balance.

Error handling for multi-leg payments
The multi-leg payment endpoint is specifically designed to handle a list of payment legs. If any legs within the request encounter an issue during processing, the entire operation is rolled back to maintain data integrity.

A rollback is a resource-intensive operation and leaves a trace of reversal transactions to compensate for the legs that were executed successfully. Therefore, extensive validation should be done before accepting a request in order to minimize rollback scenarios. This also provides the client with an early indication that the operation might fail due to an invalid input. Because of these considerations, this endpoint follows a unique error handling approach compared to other endpoints in the API.

Error response structure

When validation errors occur in one or more legs within a request, the endpoint returns a structured error response providing comprehensive information about the issues encountered. This response consists of two parts:

1. Generic error message:

• The generic error message is the WMLP0005 error code. It does not provide specific details about individual legs. This message is intended to give the client an immediate indication that the input is invalid.

2. List of leg-specific errors:

• Following the generic error message, the endpoint returns the same leg payload along with an errors attribute containing a detailed list of the errors associated with each leg.

In addition to leg-specific errors, there might be errors related to the entire request. For example, when a multi-leg payment request exceeds the maximum allowed number of legs, a standard error response including only the code and message attributes is returned. Refer to the examples provided for different error types and their corresponding error codes.

Each leg generates the following events:

• Authorization created
• Account balance changed
• Account balance changed (Availables)
• Transaction created
• Accounting entry created
• If flex controls are configured, the following event is triggered:
  • Flex control evaluated

Additionally, the following events are generated for multi-leg payments:

• Multi-leg payment lifecycle created
• Multi-leg payment lifecycle status changed

See the Data and reporting guide for more information on events and setting up event notifications.