SendPayments

## Send Payments API

The Send Payments API provides a flexible way to manage domestic and international payments. 


It's designed to be flexible, allowing a broad range of use cases. This document provides information on the endpoints offered by Send and how to interact with them. You can use these end points to create your own custom workflows or you can implement the workflows we have documented on the Send website.

API Reference and Guides

Overview & End to end flow

Authentication

Accounts

Wallets

Trades

Payments

Webhooks

Sandbox endpoints are only valid in our demo environment and can be used to simulate events you would not normally have control over.

Sandbox

Important points

Blank

User Guides

Send Partner API

Production

422 Error Message List

/accounts/{accountId}

/accounts/{accountId}/authorised-representatives

/accounts/{accountId}/recipients

/accounts/{accountId}/trades

/accounts/{accountId}/wallets

/accounts/corporate

/accounts/individual

Andorra

Argentina

Austria

Australia

/auth

Authenticating Webhooks

Available Currencies

Batch Trades

Belgium

Bermuda

Brazil

Brunei

Bulgaria

Canada

Chile

China

Collections & Pagination

Colombia

Country Payout Guides

Croatia

Cyprus

Czech Republic

Data Types

Denmark

Endpoints

Estonia

Example Routing Codes And Ibans

Fiji

Finland

France

Germany

Greece

Guatemala

Guernsey

Honduras

Hong Kong

Hungary

Iceland

Idempotent Requests

India

Indonesia

Ireland

Isle of Man

Israel

Italy

Japan

Jersey

Kenya

Latvia

Liechtenstein

Lithuania

Luxembourg

Macau

Malaysia

Malta

Mauritius

Mexico

Monaco

Netherlands

New Zealand

Nicaragua

Norway

Panama

Papua New Guinea

/payin-addresses

/payment-addresses/{paymentAddressId}

Payment Reasons

/payments/{paymentTransactionId}

/payments/payout

/payments/reason-codes

/payments/transfer

Peru

Philippines

Poland

Portugal

Qatar

/quotes

/quotes/{quoteId}

/rate-sheets

/rate-sheets/{rateSheetId}

/recipients

/recipients/{recipientId}

/recipients/{recipientId}/payment-addresses

Romania

Saint Kitts And Nevis

Samoa

San Marino

/sandbox/accounts/{accountId}

/sandbox/payins

/sandbox/recipients/{recipientId}

Saudi Arabia

Status Codes & Error Messages

Serbia

Singapore

Slovakia

Slovenia

South Africa

South Korea

Spain

Sweden

Switzerland

Taiwan

Thailand

Trinidad And Tobago

Turkey

United Arab Emirates

United Kingdom

Vanuatu

Vietnam

Zambia

/payments

Testing In The Sandbox

/trades/batch

/trades/batch/{batchId}

/trades/batch/{batchId}/entries

/trades/batch/{batchId}/submit

Trade Settlement and Cut-offs

/trades

/trades/{tradeTransactionId}

/wallets

/wallets/{walletId}

/wallets/{walletId}/payin-addresses

/wallets/{walletId}/payins

/wallets/{walletId}/payins/{payinId}

Webhook Delivery And Sequencing

Webhook Payloads

/webhooks

/webhooks/{webhookId}

## Cut-off Times

This table will provide information on the relevant cut-off times for each currency group. Please note that cut-off times are always in AEST/AEDT time (whichever is in effect). When calculating the cut-off time for a trade, please note that the most restrictive cut-off time is applicable. *ie a T+0 trade between AUD|NZD would have a cut-off time of 12:30pm*. 

> 🚧 Out of Hours Bookings
>
> The cut-off times below are all based around working days in Sydney Australia. Send allows booking of trades after hours and on non-working days (ie public holidays/weekends) and will manage the settlement date of these trades as outlined in the "Pulling it all together" section below.

<Table align={["left","left","left"]}>
  <thead>
    <tr>
      <th style={{ textAlign: "left" }}>
        Category
      </th>

      <th style={{ textAlign: "left" }}>
        Available Tenor(s)
      </th>

      <th style={{ textAlign: "left" }}>
        Cut-off(s)
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td style={{ textAlign: "left" }}>
        Same Day Value
      </td>

      <td style={{ textAlign: "left" }}>
        T+0
      </td>

      <td style={{ textAlign: "left" }}>
        4:45pm\
        (except SGD and NZD which is 12:30pm)
      </td>
    </tr>

    <tr>
      <td style={{ textAlign: "left" }}>
        Same Day Value
      </td>

      <td style={{ textAlign: "left" }}>
        T+1  
      </td>

      <td style={{ textAlign: "left" }}>
        12:00am
      </td>
    </tr>

    <tr>
      <td style={{ textAlign: "left" }}>
        Same Day Value
      </td>

      <td style={{ textAlign: "left" }}>
        T+2
      </td>

      <td style={{ textAlign: "left" }}>
        12:00am
      </td>
    </tr>

    <tr>
      <td style={{ textAlign: "left" }}>
        Next Day Value
      </td>

      <td style={{ textAlign: "left" }}>
        T+1
      </td>

      <td style={{ textAlign: "left" }}>
        1:30pm\
        (Except THB which is 12:30pm)
      </td>
    </tr>

    <tr>
      <td style={{ textAlign: "left" }}>
        Next Day Value
      </td>

      <td style={{ textAlign: "left" }}>
        T+2
      </td>

      <td style={{ textAlign: "left" }}>
        2:30pm
      </td>
    </tr>

    <tr>
      <td style={{ textAlign: "left" }}>
        Spot
      </td>

      <td style={{ textAlign: "left" }}>
        T+2
      </td>

      <td style={{ textAlign: "left" }}>
        1:30PM\
        (Except FJD which is 10:00am and PGK which is 12:30pm)
      </td>
    </tr>
  </tbody>
</Table>

> **Same Day Value:** AUD, CAD, CHF, CNY, CZK, DKK, EUR, GBP, HKD, HUF, MXN, NOK, NZD, PLN, SEK, SGD, TRY, USD, ZAR
>
> **Next Day Value:** AED, BGN, BHD, BWP, CLP, GHS, IDR, INR, ISK, JPY, KES, KRW, KWD, KZT, MAD, MYR, OMR, PHP, QAR, RON, RSD, SAR, THB, TND, TWD, UGX, VND, ILS
>
> **Spot:** AFN, ALL, AMD, ANG, AOA, ARS, AZN, BAM, BBD, BDT, BIF, BMD, BND, BOB, BRL, BSD, BZD, COP, CRC, CVE, DJF, DOP, DZD, EGP, ERN, ETB, FJD, GEL, GMD, GNF, GTQ, GYD, HNL, HTG, IQD, JMD, JOD, KGS, KHR, KYD, LAK, LKR, LSL, MGA, MNT, MOP, MUR, MVR, MWK, MZN, NAD, NGN, NIO, NPR, PEN, PGK, PKR, PYG, RWF, SBD, SCR, SLL, SRD, SZL, TOP, TTD, TZS, VUV, WST, XAF, XCD, XOF, XPF, ZMW

> 🚧 A Note on Currency Categories and Settlement Cut-offs
>
> Please note that whilst currencies are specified above in various categories these categories are for the purposes of simplification. Your agreement with Send may categorise currencies into different segments. This will have no impact on that currencies cut-off as specified above, unless explicitly mentioned.

## Settlement Dates

## What is a settlement date?

The `settlementDate` of a trade is the date that the trade will actually occur. This is the date that the specified `fromWallet` will be debited and the corresponding `toWallet` or `recipient` will be credited. Importantly, the `settlementDate` is the point at which the wallet *MUST* be funded in order to avoid any potential trade cancellations and associated fees. 

> 📘 Trade `settlementDate` vs Payment `paymentReleaseDate`
>
> When booking a linked trade and payment, usually the `settlementDate` and `paymentReleaseDate` will be the same. However depending on when the trade is specifically funded and the time taken to process the Payout, the `paymentReleaseDate` may change. This is usually when booking trades into exotics where, due to liquidity restrictions, the payment may only be able to be released up to 2 days after funding of the trade. Another example is if a Trade is booked right before a cut-off, in this instance the Trade may settle, however the payment could miss its cut-off and be sent the following day.

## Calculating the Settlement Date

Calculating the `settlementDate` is a function of the cut-off time for a **trade**, when the **trade** was booked and at what **tenor** the **trade** is booked. The table below will assist you in preemptively understanding what a `settlementDate` might be before a trade is booked, but Send will also always provide the `settlementDate` in the trade response. Please note that no matter what the `settlementDate` is, Send will always honour the quoted **rate** (or **ratesheet**) used to book a trade provided it has not expired. 

| Applicable Tenor | Booking Time   | Settlement Date                                             |
| :--------------- | :------------- | :---------------------------------------------------------- |
| T+0              | Before Cut-Off | 90mins from `now` or the cut-off time (whichever is sooner) |
| T+0              | After Cut-Off  | 9:30am the *next* **Business Day**                          |
| T+1              | Before Cut-Off | 9:30am the *next* **Business Day**                          |
| T+1              | After Cut-Off  | 9:30am the *following* **Business Day**                     |
| T+2              | Before Cut-Off | 9:30am the *following* **Business Day**                     |
| T+2              | After Cut-Off  | 9:30am the *subsequent* **Business Day**                    |

## Pulling it all together

If we run some examples through this model it will help to make sense of how the fields hang together. 

**Scenario 1 - AUD to NZD Trade**

| Requested Tenor | AUD Cutoff | NZD Cutoff | Trade Booked At | Settlement Date  | Explanation                                                                                                                                                                        |
| :-------------- | :--------- | :--------- | :-------------- | :--------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| T+0             | 4:45pm     | 12:30pm    | 12pm Friday     | 12:30pm Friday   | Trade booked before cut-off (12:30pm) and therefore settles to sooner of 90mins from NOW or Cut-off.                                                                               |
| T+0             | 4:45pm     | 12:30pm    | 12:31pm Friday  | 9:30am Monday    | Trade is booked after the most restrictive cut-off (12:30pm) and therefore defaults to settling at 9:30am the next business day (which cannot be Sat or Sun).                      |
| T+1             | 12:00am    | 12:00am    | 12:01pm Friday  | 9:30am Monday    | Trade is booked before the T+1 cut-off (12:00am) meaning the trade is due to settle at 9:30am the next business day.                                                               |
| T+2             | 12:00am    | 12:00am    | 12:30am Sunday  | 9:30am Wednesday | Trade is booked in the early hours on a Sunday morning. This means that the T+2 tenor will initiate from 9:30am on Monday. Therefore the Trade will settle on Wednesday at 9:30am. |

**Scenario 2 - AUD to AFN Trade**

| Requested Tenor | AUD Cutoff | AFN Cutoff | Trade Booked At  | Settlement Date  | Explanation                                                                                                                                                                                                                                                                                                                                                                                          |
| :-------------- | :--------- | :--------- | :--------------- | :--------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| T+0             | 4:45pm     | 1:30pm     | 11am Monday      | 9:30am Wednesday | Since AFN is a SPOT only currency, Sends system will ingest the T+0 request but then augment it to T+2 since this is the only valid tenor. As such, and since the trade was booked *before* cut-off, it will settle in 2 business days on Wednesday.                                                                                                                                                 |
| T+1             | 12:00am    | 1:30pm     | 1:31pm Friday    | 9:30am Wednesday | Since AFN is a SPOT only currency, Sends system will ingest the T+1 request but then augment it to T+2 since this is the only valid tenor. As such, and since the trade was booked *after* cut-off, it will settle in 2 business days from the next valid business day. Since the trade was booked on Friday, the next valid business day is a Monday, therefore the trade will settle on Wednesday. |
| T+2             | 12:00am    | 1:30pm     | 1:29pm Wednesday | 9:30am Friday    | Trade is booked before cut-off and therefore will settle in the normal T+2 window.                                                                                                                                                                                                                                                                                                                   |

<LeaveUsADiscussionBoardPost />

Fetches a rate for a given currency pairing. Rates can be used to calculate the buy and sell amounts of a client trade and can be cited to subsequently book it in.

Fetches a quote for a given currency pairing. Quotes can be used to calculate the buy and sell amounts of a client trade and can be cited to subsequently book it in.

The trade endpoint executes a trade between two currencies which is executable immediately. Payments can be optionally linked for currencies not supported by wallets or where there is a 1:1 coupling between trade and payment.

Retrieves a previously created rate sheet.

Retrieves all trades for a specific account.

Trades are the means by which Wallets (and thereby, the associated Account) exchange one currency for another. The exchange rate for a trade can either be locked in using a rate sheet or calculated at the market rate when booking.

The trade batch create endpoint creates an entry for individual trades to be created against for batch booking

The trade batch entries retrieval endpoint retrieves a paginated list of the entries that the batch contain

The trade batch entries endpoint adds individual trades against a batch for submission on the same rate-sheet

The trade batch submission endpoint attempts to submit the batch and all batch-items for booking

The trade batch retrieval endpoint retrieves a previously created trade batch without entries. This can be used to check the status of a batch, and the total amount of successful or failed submissions

The trade batch marks a batch and all entries for deletion

Send Legacy API

Sections

Batch Trades

What made this section unhelpful for you?

Endpoints

What made this section unhelpful for you?