The Tech Tales. How we built localised multi-currency payouts

Supporting all payment types within our platform is a key part of our product vision at OpenPayd. That’s why late last year we started to roll out new localised payout functionality in dozens of currencies for OpenPayd customers.

To put it simply, this functionality allows our clients to make a payment to a recipient in dozens of currencies. It allows them to merge the foreign exchange and payment into a single transaction.

Here, I wanted to share why we built the solution and how we did it. But before we get into that, this is what you need to know about the multi-currency payouts our clients can access at OpenPayd. 

Multi-currency payouts in a nutshell

Let’s start with the basics. At OpenPayd we offer single-currency accounts either in Euro or GBP and multi-currency accounts that have a single IBAN, but can hold up to 12 different currencies behind that IBAN (with more on the way). Those accounts can receive payments, hold a balance and make payouts in every currency the account is set up to hold.

But sometimes our clients will need to make payments out of their OpenPayd accounts in a currency we don’t currently support. Traditionally, this payout would be sent as an international transfer via the SWIFT network, which takes a few days and can be very expensive, especially for regular or small-value payments. 

The multi-currency payout solution we’ve built fills these gaps. It offers payouts in dozens of different currencies (we’re working towards 100) and those payouts use local payment rails to reach the recipient, rather than an international transfer. All of this can be done with an API call to our system, or through our client dashboard.

So if a client needs to start making payouts in a currency like Australian Dollars, the process will go like this: 

1. Our client asks the OpenPayd Operations team to enable AUD payouts.

2. We add an AUD payout wallet to their dashboard in the OpenPayd platform.

3. The client sets up a beneficiary using the recipient’s bank account information. Because it’s a local payment, we ask for the BSB Number of the recipient bank, rather than a SWIFT code. 

4. The client initiates an exchange from their existing OpenPayd account to the AUD payout wallet. 

5. At this point, our client receives an FX rate so they know how much of the currency they will receive. 

6. Our client now has AUD in their AUD payout wallet within the OpenPayd platform.

From here, the process is just like any other payment:

1. They select the beneficiary, the amount, the payment rail and provide any reference information.

2. Once that information is entered, they can initiate the payment. 

From there, the payout will go to the beneficiary. How long that takes will depend on which local payment rails are available to the recipient’s bank, but it will almost certainly be cheaper and more secure than an international transfer.

So that’s what it looks like to a user on our client-facing portal (The process is broadly the same for API integrations, but each of these steps will be done via an API call instead). Here’s how we built the technology to make this possible.

Why we built multi-currency payouts

From a product perspective, we knew that building FX capabilities without payouts wouldn’t work for our clients - we had to provide a full payment journey. And because we’re building the OpenPayd offering to offer every payment rail to our customers - supporting more currencies helps us get there. 

Secondly, we knew from our competitor research that a lot of our competitors only offered the G10 currencies, but they don’t provide the breadth of services that we aspired to offer. We knew that a lot of clients and prospects might have specific payment needs in currency pairs that our competitors don’t support.

Finally, we knew clients were facing considerable costs with their international payments, and that localised payouts would help reduce that expense. By working with our banking partner and using their onshore accounts to make local currency payouts, we can significantly reduce those payment costs.

How we built it

We first made the ticket for this project on July 22nd last year, with a first transaction completing on the 17th of October – about three months from when we first started work until the first live transaction.

Across those three months, we had nine devs and four QAs working on this functionality at different stages. These included:

1. We first defined the use case for the product 

2. Then for the first major component of the project, we built the integration with our banking provider. This integration took about two months.

3. And then we spent about a month working to complete the integration with our customer-facing API and our back-office functionality so everything was merged into the interface our customers were already integrated with.

It’s this last step where we’re adding the greatest value. Our banking partner for this service has their own API which our clients could, in theory, connect to directly. But what we bring to the table is the chance to integrate that multi-currency payout into their existing payment infrastructure and payment flows, without our clients having to lift a finger. 

By bridging that gap, we’re delivering on the product vision. And with the new multi-currency payouts, we’re now able to manage many more payments, in many more currencies, all through the OpenPayd platform.