How webhooks put the ‘embedded’ into embedded finance

Embedded finance is beginning to realise its potential, from money transfers to instant savings to automated account reconciliation. Yet these systems can’t properly function without webhooks. Sent via the internet, a webhook connects one information system with another. From automating data flows to integrating different systems, webhooks have long been the unsung heroes of the digital economy.  

At OpenPayd, webhooks connect our services with our clients’ systems. They allow our clients to build more complex messaging flows around their banking and payments. Without them, embedded finance would fall flat. Virtual IBANs allow you to store each customer’s funds in a unique account, but without webhooks, many of the supplementary services that people expect are impossible. Updating a customer’s cash balance in a business’s internal ledger when a payment arrives, sending the customer an in-app notification that they’ve received the payment, flagging failed payments with their operations team - all of these depend on webhooks. 

Given the importance of user experience (UX) in attracting and keeping users, developing and deploying the right webhooks can make all the difference. With intelligently-designed webhooks, you can build digital products with deeper functionality, better UX, increased responsiveness, and fewer headaches. The benefits accrue for staff, too. Well-placed webhooks can reduce operational headaches, customer complaints, and laborious or piecemeal processes. Reducing the workload on operations from manual processes gives them more time to focus on what counts: your core offering.

Over the years, our clients have developed and deployed a wide variety of webhooks. The use cases are evenly split - about half are built to improve the user experience (for example, enabling notifications like confirming receipt of payments), and half are enabling back-office processes. 

Whatever the use case, it starts by setting up a webhook that’s triggered by a specific occurrence in the OpenPayd system. That webhook sends a message to the client’s back-end software via an endpoint URL they set up. That message provides a dump of all the relevant information for the specific webhook. From there, our clients’ developers will build scripts to process the data provided by the webhook, allowing them to complete tasks like sending clients a notification on receipt of payment.

To showcase the webhooks we offer, the sort of flows that our clients build, and how they improve user experience and data flows, we’ve put the most popular under the microscope:

Transaction status updates

Keeping customers in the loop while their transactions are being processed is a classic use case. From pay-ins, to payouts, internal transfers between OpenPayd accounts and Foreign Exchange, our clients can use different webhooks to fire when a transaction is processing, completed, failed, or cancelled. So that, whatever the outcome, both user and platform are kept up to date on what’s happening.

Account status updated

Across the user lifecycle, customer accounts undergo a number of steps. This webhook can alert you to when an account is ‘Pending’ (when its specific IBAN or account number is in the process of being assigned by our banking partners), ‘Active’ (ready for transactions), ‘Failed’, ‘Suspended’ (temporarily inactivated and unavailable for transactions), or ‘Closed’ (permanently inactive). These updates allow our clients to build accompanying internal data flows - so they can track when an account is first activated and notify the client that they can begin making pay-ins. 

If you want to explore our webhook functionality in more detail, check out our interactive demo here, or visit our sandbox to get first-hand experience using our platform.

Webhooks like these make it possible to embed financial services into other products. Yet being tools of interoperability, they depend on both the host system’s payload transmission, and upon individual platforms’ translation of those messages for their customers where necessary. Sometimes, for whatever reason, a webhook message will be unsuccessful. This is where our retry mechanism comes into play. If the Webhook receives anything other than an HTTP 200 OK status code (confirming that the system has received a message) from the endpoint, it will retry repeatedly for 24 hours (or until our client intervenes), helping to prevent unnecessary failures and maintain continuity of services. 

Features like these help to keep customers online and services ticking along - which is why the humble webhook makes such a difference.