Written by Alex Mifsud, CEO and Co-founder of Weavr.
You learn something every day. When is embedded not actually embedded?
I recently spent some time looking closely at embedded finance solutions – not just the home page, but actually going through the developer guides and APIs. I discovered that a number of self-described embedded solutions were actually third-party hosted applications that allowed a logo and a background colour to be applied to an existing UX, sometimes with the ability to feature certain of the application pages within iFrames.
Why does this matter? It means that the embedder has very little scope to design the user experience, including the user flow, the layout of the financial elements within their own UX, in the way they truly want. They can provide the lipstick, but the pig is, well, the pig that you’re given.
We’ve been here before. History doesn’t quite repeat, but it certainly rhymes. The first (and second, and third) e-commerce payment pages were hosted pages, because websites couldn’t be trusted with managing the complexity and with guaranteeing the data security standards needed for handling sensitive card data. In the case of embedded finance, what needs to be protected is often illegitimate access to financial accounts and other instruments like debit cards, and the potential for financial loss without the protection of chargebacks. In addition, along with PCI-DSS compliance, there are forms of Strong Customer Authentication to contend with.
For card acceptance, the alternative to hosted pages was initially card acquiring APIs, but soon this was only available to merchants that where PCI-DSS certified, an onerous and expensive undertaking and out of reach for most merchants. Then Stripe came along and started to offer some slick alternatives to keep the merchant out of scope for PCI purposes while still giving them the means – using code snippets and embeddable components – to create a truly embedded experience.
Fast forward to Embedded Finance. Or should I say Pseudo Embedded Finance?
A few months back, we published a blog suggesting questions that embedders should ask BaaS providers – see “10 questions for BaaS suppliers” if you are curious. This is another one to add to that list, and I it goes like this, unpacked for simplicity:
- Can you place sensitive financial UX elements – both inputs (such as a banking password) and outputs (such as the full card number or PAN) – wherever you want in your UX workflows and layout, or do you have to embed within an iFrame a ‘mini app’ created by the BaaS provider that has a pre-built workflow and a pre-built layout?
- When it comes to Strong Customer Authentication, for account access or to give approval for payment transactions, how exactly is that going to be embedded into your app? This is a feature that is going to be used all the time by your customers and if there is any friction or ugliness there it will show. Does the BaaS provider have a really embedded solution that you can style and place where you want in your UX, or does it involve downloading their app with your logo on it?
- When communications go out to your customers – telling them that their balance has changed, or that they’ve just accepted new terms – is that email going out with your design, with an email address and links associated with your domain or those of your BaaS provider.
These things probably don’t matter if you are just knocking off a proof of concept. But if you are Apple-like obsessed with your customer experience and your brand then all these limitations and compromises will jar. In this case, Pseudo-Embedded simply won’t do.
If you want to continue the conversation surrounding embedded finance, please reach out on LinkedIn or click the ‘Talk to an expert’ button at the top of this page.
