Overview

We've made some exciting updates to simplify trust account creation, resolve bugs, and refine payment and validation requirements. These changes aim to make your experience smoother, ensure data accuracy, and better support international payouts.

Version Impacted: V2.0
Date Effective: 15/01/25

Key Updates

Account Management

• Simplified Trust Account Creation:
  • We've removed the isActingAsTrustee and trust fields. Now, you can create trusts by setting up a corporate account with the account type trust.
• Bug Fixes:
  • Resolved an issue that blocked ratesheet creation without a trading account ID.
  • Fixed invalid values for corporateRegistrationType in /accounts/corporate. Correct values are now abn and acn.

Trades and Quotes

• Validation Updates:
  • buyAmount and sellAmount in /trades now must be greater than 0 (no more zeros or negatives allowed).
  • buyAmount and sellAmount in /quotes are also restricted to values greater than 0.
  • requestedTenor in /trades now accepts T+0, T+1, and T+2 instead of T0, T1, and T2.

International Payouts

• Field Requirement Adjustments:

  • We've refined requirements for phoneNumber, email, taxIdentifier, and corporateRegistrationNumber when making SWIFT payouts to certain countries.
  • Example: In Argentina, a phone number is now only required for ARS payouts, while it’s recommended (but not mandatory) for other currencies.
  • Check the updated table for full details.

• Indian Bank Account Types: We've standardized values for Indian account types:

  • nro for Non-Resident Ordinary Account.
  • nri for Non-Resident Indian.
  • nre for Non-Resident Emigrant.
  • resident remains unchanged.

• Payment Reason Codes (Philippines): All codes are now 10 digits. For example, 910100005 is now 0919100005.

• New Zealand Payouts:

  • Local payouts now accept accountReference of 9-10 digits (was 10).
  • SWIFT payouts now accept accountReference of 15-16 digits (was 16).

• BRL Payments: We’ve added branchCode and bankCode to the Payment Address object. For BRL SWIFT payments, a 3-7 digit agency code is now required in the branchCode field.

Other stuff

• Fixed bugs with webhook functionality and corporate account creation.
• Improved performance for cold starts to reduce wait times.

📘

Got Questions?

Got questions or concerns about this change? Head over to our Discussion Board and leave us a note.

Overview

API 2.0 is officially out of ALPHA and into BETA (thank you to all our Alpha testers) which means we're opening up our sandbox environment to anyone who wants access. With this rollout comes a few additional tweaks to the spec and a whole host of backend bug fixes.

Version Impacted: V2.0

Date Effective: 4th of October 2024

Want Access to the Sandbox?

If you are interested in trying out the Send Payments API please reach out to us at [email protected] with the subject line "API Integration" and our sales team will get in touch with you!

BETA Improvements

The following tweaks are updates we've made from our most recent Alpha version into our fresh Beta version.

• Updated the auth pattern for webhooks, see our guide here. Please note that webhooks are not available in the sandbox, we aim to release them on the 10th of October
• Removed the requirement in API docs to add a bearerToken when using the /auth endpoint. This prevented users from testing the API from the dev site but was not enforced for postman testing.
• Updated the sandbox URL. The new BETA URL is: partner-api-demo.uat.sendpayments.dev...
• Removed some fields from post request payloads that were redundant or could be inferred from other fields (ie removing the need to supply both a fromWalletId and a tradingAccountId when creating a trade)
• Added some additional query parameters to GET endpoints to help with filtering
• Updated post/accounts/corporate to explicitly call out the mandatory fields (ie authorisedRepresentative, countryOfRegistration etc)
• Added in magic values, allowing transactions with certain values to be auto-failed/passed
• Added externalReference to more endpoints

Bug Fixes

• Fixed issues where optional fields on post/recipients were being forced despite the country guideline not mandating it for the recipients country.
• Fixed some issues with the payments/reason-codes endpoint
• Fixed an issue which caused some valid trades to fail being created

📘

Got Questions?

Got questions or concerns about this change? Head over to our Discussion Board and leave us a note.

Overview

To help better manage funds coming into the Send platform, we have made a couple of minor tweaks to Pay-ins.

Version Impacted: V2.0

Date Effective: 10th of August

Impacted Endpoints:

• POST/sandbox/payins
• GET/wallets/{walletId}/payins
• GET/wallets/{walletId}/payins/{payinId}

Reference Field

Previously, the reference field was only available via our payin webhooks. This has been updated to now also be included in the GET Payin endpoints for easier reconciliation.

Sandbox Improvements

We have uplifted the Payin Sandbox endpoint to now include sourceDetails, remitterDetails and reference. This will help with testing of these fields. Note The exact format of these 3 fields is dependent on the sending bank combined with rails you choose to use (NPP vs Swift vs BECS/ACH) We highly recommend some penny tests in production to ensure any logic you have built off of these fields works as intended.

Other Enhancements

We've made a couple of minor tweaks to some other endpoints including:

• Made recipientId and paymentAddressId mandatory when you add the payment object to POST/trades.
• Updated GET/payments/reasonCodes to GET/payments/reason-codes.

📘

Got Questions?

Got questions or concerns about this change? Head over to our Discussion Board and leave us a note.

Overview

A variety of minor enhancements are being made to our payment endpoints to help improve payment routing, reduce payment failures and provide additional clarity when integrating.

Version Impacted: V2.0

Date Effective: 2nd of August 2024

Impacted Endpoints:

• Payment Addresses
• Recipients
• Payouts
• Transfers

Summary of changes

• Made clientAddressName optional in paymentAddresses
• Added more helper text to the recipients endpoint to assist in understanding which fields are conditionally mandatory/optional
• Simplified the transfer endpoint by removing unnecessary fields
• Added some additional fields to the response for payments such as payoutType and paymentDate
• Added the ability to add an externalReference to a paymentAddress

📘

Got Questions?

Got questions or concerns about this change? Head over to our Discussion Board and leave us a note.

Overview

We're making a number of small changes to the API 2.0 specification to bring it up to industry best practises. These changes, whilst extensive, are all fairly minor and have no material impact on how the API is used.

Version Impacted: V2.0

Date Effective: 26 of July 2024

Updates to endpoint paths

We have updated all our endpoint names to make collections pluralised as is industry best practise in addition to hyphenating path names where multiple words exist. This has no impact on the functionality of each endpoint but helps to ensure clarity when reading the specification.

Updates to nested GET responses

We are updating how our GET endpoints response where nested objects existing (for example, payinAddresses are nested underneath wallets and paymentAddresses are nested underneath recipients). Since there are use cases where a wallet or recipient has a large number of nested sub-objects, we will be removing the sub-objects from the GET endpoint of the parent object (ie removing payinAddresses from GET/wallets/{walletId}). This is to prevent issues with payload size and unnecessary data transmission when the sub-objects are not required. These sub-objects can still be obtained using the relevant GET endpoints (for example, to get payinAddresses you can use GET/wallets/{walletId}/payin-Addresses).

Impacted Objects:

• wallets and nested payinAddresses
• recipients and nested paymentAddresses
• trades and nested payouts

Updates to sensitive information in GET responses

In many instances, sensitive information is required to be given to Send through our POST endpoints in order to onboard a new account, or verify a new recipient. This sensitive information is handled with the upmost care once within Sends systems. In order to prevent any possibility of sensitive information leaks, Send will be removing this information from our GET endpoints. Send will however, still provide critical operational information in the GET responses, including: status, contact information and other non-sensitive data.

Impacted Endpoints:

• All Accounts Endpoints
• All Recipient Endpoints

Other minor changes

Along with the above updates, we've made a bunch of other minor quality of life improvements to our API2.0 spec. They are detailed below.

• Added the ability to assign a payout an externalReference when creating it through POST/Trades.
• Updated GET request pagination metadata naming (functionality remains the same).
• Updated birthDate in POST/accounts/individual to dateOfBirth.
• Made the physicalAddress.postCode field within POST/recipients to now be optional.
• Fixed a typo on the description of POST/sandbox/payins.
• Added the trust.registrationNumber and trust.physicalAddress fields to our POST/Accounts endpoints.
• Updated the description on GET/rate-sheets/{rateSheetId}.
• Updated the description on GET/payment.
• Removed the need to supply a walletId and currency in the payinAddress object when you are creating a wallet and payinAddress together.
• Removed trust.trustTrustees from our POST/Accounts endpoints.
• Added a new list endpoint for fetching paymentAddresses - GET/recipients/{recipientId}/paymentAddresses.
• Updated the DELETE/Webhooks 204 success response to include no response body.
• Updated the payment status list to include the full list of possible payment statuses and to bring it into line with our payment status guide.
• Added the optional field accountName within the paymentAddress object.
• Made reference options in the post/payment/payout endpoint.
• 
  

📘

Got Questions?

Got questions or concerns about this change? Head over to our Discussion Board and leave us a note.

Overview

We are making some minor updates across a number of our endpoints based off of customer feedback to help streamline both integration and transaction flows when live. Please let us know if you have any questions.

Version Impacted: V2.0

Date Effective: 21 of June

Impacted Endpoints:

• Accounts
• Trades
• Wallets
• Payments

Changes to Accounts

We've made a number of tweaks to our accounts endpoints to help streamline the onboarding process and hopefully reduce integration effort.

• We've added a new field countryOfBirth to our account endpoints to help streamline the KYC process for new accounts
• To help reduce integration effort, we've removed separate status tracking of Authorised Representatives, instead bundling this up under the account that owns the authorised representative.
• We have removed the ability to add an authorised representative to an individual account. We will be adding this feature back in at a later date if there is demand.

Changes to Trade

A fairly minor one for trade, where we've altered the POST/Trade/Spot endpoint to just be POST/Trade. This helps avoid some confusion around the trade tenor.

Changes to Wallets

We've made a few updates to Wallets and their associated Payins help improve the clarity around their use.

• We've shifted the domicile parameter to now live against the wallet (rather than the payin address). This more accurately represents the flows of funds.
• We've changed the totalBalance field to now be called cashBalance. This now more accurately describes this field, which is the true cash balance of the wallet.

Changes to Payments

• We've created a new endpoint GET/payment/reasonCodes. This enables the retrieval of Reason Codes that can be used for each country when making a payment.
• Also changing in the Payments space is a new field called accountType. This field is only required when making a payout to certain countries.
• Another field we've added is the countryOfResidence to the Recipient. This field is only required whem making a payout to an Individual in certain countries.

General Quality of Life Updates

In addition to the above, we've made some tweaks around the edges of the spec to fix up some errors and help improve readability.

• Fixed an issue where ENUMs were not correctly displaying their available values in the API Spec.
• Added in webhookSecret into the webhook response
• Updated the webhook example payload to include the full list of possible options
• Updated the payload for POST/Wallet too more easily see the ability to create a wallet and payin address at the same time.

📘

Got Questions?

Got questions or concerns about this change? Head over to our Discussion Board and leave us a note.

Overview

In order to clear up some ambiguity and streamline compliance processes for new accounts and recipients some minor field changes are being implemented to our accounts and payments endpoints. These field changes will ensure as much accurate data as possible is available from the offset to reduce potential back and forth when running checks. Additional guides will come in the next few weeks outlining more detail around account/recipient creation to help further improve this area.

Version Impacted: V2.0

Date Effective: 13th of May

Impacted Endpoints:

• POST/payment/transfer
• POST/payment/payout
• POST/recipient
• POST/recipient/{recipientID}/paymentAddress
• GET/payment
• POST/account/individual
• POST/account/corporate
• POST/account/{accountID}/authorisedRepresentative

Changes to Payments

• Added tax to the list of valid payment reasons
• Removed fromTradingAccount and toTradingAccount from transfer requests
• Make references on transfers optional
• Made payment reasons on transfers optional
• Removed fromTradingAccount from payout requests
• Made paymentAddress mandatory when creating a recipient
• Renamed paymentType to payoutType when creating a paymentAddress. This is to support updating paymentType field in GET Payment to now differentiate between payouts and transfers
• Renamed business fields to corporate fields in recipient creation.

Changes to Accounts

• Added the ability to add a primaryIdentification object to Authorised Representatives, Trust Beneficiaries and Trust Trustees
• Updated corporateType Enum
• Updated our corporate fields to now contain the following fields
  • Corporate Name
  • Corporate Business Name
  • Corporate Registration Number
  • Corporate Registration Type
  • Corporate Type
  • Country of Registration

📘

Got Questions?

Got questions or concerns about this change? Head over to our Discussion Board and leave us a note.

Welcome to the developer hub and documentation for Send Payments! You'll see here any new and upcoming changes to our FX API.

In all instances, Send will endeavour to minimise breaking changes to the API or changes which could impact the use of our API even if they are non-breaking. Where breaking changes need to be made Send will issue an updated API version to correspond to the change. Otherwise non-breaking changes will be rolled out on the dates specified in each change update.

If you ever have any questions, please head over to our Discussion Board where we will help you with any enquiries.