Consumer payments
Fintech Web and Mobile Application Case Study
Waiu
The challenge
Waiu is a dine now, pay later payment service, which means a diner discovers it, decides to trust it and uses it inside the space of a meal. That put an unusual weight on the surfaces the company had not yet built. It needed a website, a web application and a mobile application, and the ordinary way those get built is separately, by whoever is available, with the marketing site treated as a brochure and the applications treated as engineering. For a consumer payment product that separation is expensive, because a diner who has just read the proposition on the website and then opens an application that looks and behaves like a different company has been given a reason to hesitate at precisely the wrong moment.
The approach
We treated the three as one product with three surfaces. The brand work and the interface work were done together rather than in sequence, so the language, the visual system and the flow a customer follows are the same whether they arrive at the website, the web application or the mobile app, and the website is where a customer starts using the service rather than a page that points at somewhere else. The applications were built to the same specification of what the service does and how it explains itself, which is what makes the mobile app read as the same product a diner was persuaded by ten minutes earlier.
The outcome
Waiu ended up with a single point of entry for its customers rather than three properties to keep in step. The website draws traffic from a range of sources and functions as the hub where a customer learns what dine now, pay later means and then goes on to use it, instead of a landing page that hands the customer to an unrelated application. Because the surfaces were specified together, a change to how the service is described is a change to one product rather than a synchronisation exercise across three.
Consumer fintech is judged in the first two minutes, and most of the damage is done at the seams, the moment the marketing site hands the customer to the application and the tone changes.
What “dine now, pay later” actually has to arrange
Three parties have to agree inside the length of a meal. The diner wants to pay later, the restaurant wants to be paid, and a lender has to be willing to extend the credit. Waiu sits in the middle and makes that look like one action.
The service is not a payment method. It is a brokerage that has to resolve, at the table, which lender will fund this particular diner at this particular restaurant. That is why the product is a credit line application, a merchant identification step and a payment, presented as a single flow.
The system integrates several consumer lenders rather than one, so a diner who is not eligible with the first has somewhere else to go. Waiu does not underwrite. It collects the profile the lender needs — identity, employment and income details, and the diner’s explicit consent — and passes it on. The lender approves a limit, holds the repayment schedule and collects the money.
Why the seam between the surfaces is where trust is lost
A diner meets this proposition on the website, decides to try it, and opens the application. If the application looks and reads like a different company, they have been handed a reason to hesitate at the exact moment they are being asked to trust a stranger with a credit decision.
That is the argument for treating the website, the web application and the mobile app as one product with three surfaces rather than three projects. The brand work and the interface work were done together, and the website is where a customer starts using the service rather than a page that points at somewhere else.
Where continuity is actually enforced
Continuity across surfaces survives only where it is structural. Visual guidelines drift; the copy a customer reads at a decision point is the part that must not.
So the sentence a diner sees when a payment cannot go through is decided in the API rather than written separately into each client. The lender returns a technical code; the service maps it to a readable message, a heading and a key telling the client which screen to show. A declined payment explained in the lender’s vocabulary is the point at which a consumer product loses somebody, and it is not a screen worth writing twice.
The same holds for the walk-through content, the introductory screens and the help material: they are served by the platform, so changing how the service explains itself is one change rather than a synchronisation exercise.
Two money flows that are easy to conflate
What the diner owes and what the restaurant is owed are different things on different clocks, and they need to stay separate in the model.
The diner’s obligation belongs to the lender, with the schedule and the due date the lender’s to hold. The restaurant’s settlement is Waiu’s own — a transaction carries its settlement state and settlement reference from the moment it is created, so a merchant’s question about a specific meal is answered by looking at that transaction rather than by reconciling two systems at month end.
Building the site and the applications as one piece of work is not a design preference. For a product asking a stranger to trust it with a payment, continuity across the surfaces is part of the proposition, and it is the sort of decision that is cheap in an MVP build and expensive to retrofit afterwards.