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.
Bank Account Types: We've standardized values for account types:
India
nro for Non-Resident Ordinary Account.
nri for Non-Resident Indian.
nre for Non-Resident Emigrant.
resident remains unchanged.
Colombia
cacc for checking
svgs for savings
oth for other
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.
COP & HNL Payments We no longer require the accountType for these payments.
IDR Payments
When paying IDR to an individual, we now require the countryOfResidence
When paying IDR to a corporate, we now require the corporateCountryofRegistration
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.
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 info@sendpayments.com 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.
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.
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.
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.
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 when 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.
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.
