Fintech with room to evolve
Getsby offers virtual payment cards through a mobile app. We built the software users rely on to buy, top up and manage their cards. Its architecture allows financial service providers to be replaced and money flows to be traced. That gives Getsby a foundation for developing the product further, with visibility into what happens to each transaction.
Buy, top up and manage virtual payment cards in one app.
- Industry
- Fintech
Team
The challenge
One payment app, several financial providers
Creating a virtual payment card, adding money and using it should be a straightforward process. Getsby brings those actions together in an app used primarily on phones. The software is at the heart of the business: this is where customers register, buy cards and make payments.
Behind that single app are several financial providers. They handle services including identity verification, payments and card issuance. Getsby depends on their services, while users experience the whole as one product. Our brief was to build a coherent application that connects Getsby's own product logic with those external processes.
Room for the next step
A financial product keeps evolving. Users expect different payment options, a provider changes its service, or an existing integration proves unsuitable for how people use the app. Those changes can reach deep into the application. Switching payment providers, for example, can affect how a purchase is processed and how its status is reported.
We therefore accounted for replacing integrations from the outset. We wanted to avoid embedding a provider so deeply in the software that switching would require rebuilding the application. Getsby needed to retain the ability to choose services that fit its product. That shaped how we divided the software and where we placed boundaries between its parts.
The question behind the brief
The freedom to switch providers
Which parts belong to Getsby, and which belong to an external provider? Drawing that distinction mattered more than trying to predict which provider would be the best choice several years later. The product needed room for a different choice without requiring us to start again.
We placed registration, identity verification and payments in separate parts of the application. Within each part, we keep the provider's requirements inside the integration wherever possible. It translates what Getsby needs into the way the provider works. The rest of the product uses the operations and statuses we have defined for Getsby.
Making a targeted change to payment processing
The value of that design became clear when the app entered international use. One payment route did not complete payments reliably enough. The differences involved combinations of banks, cards and currencies that had not appeared in our own tests. This needed to be resolved: users had to be able to complete their purchases, and failed payments created support and recovery work.
We first worked with the payment provider to establish whether the existing route could be improved sufficiently. When that did not deliver the required result, we could move processing to another provider. Because the integration had a defined boundary, most changes stayed within the payment part of the application. We did not have to rebuild the logic for buying and managing cards.
The trade-off behind that flexibility
That separation takes deliberate work. For each integration, we need to establish which data and statuses the rest of the application needs, and which details matter only to that provider. This requires more thought during development. If provider-specific details still spread throughout the code, the benefit disappears as soon as something changes.
Connecting a new provider therefore remains development work. The benefit lies in the scope and predictability of the change: we know which part needs to change and which interfaces with the rest of the application must be preserved. At Getsby, that gave us room to reconsider a provider based on real use, without also redesigning registration and card management.
Technology that makes the difference
Making every money flow traceable
In a payment app, it must be possible to explain what happened to a transaction. Which action did the user start, what request did we send for it, and how did the financial provider process it? Those questions matter when an outcome is unclear or a user does not recognise a payment.
We accounted for traceability when designing the money flows. The records preserve the connection between the intended action and the external provider's processing. That gives us a concrete trail to follow during an investigation and a basis for discussing any discrepancy with the provider.
A request ID connects the steps
Every request to the banking integration receives a unique request ID. We store it together with the intention behind the request: which action did we want to carry out? The same ID helps locate that request at the financial provider. We can compare our records with the provider's and establish that we are looking at the same operation.
This matters particularly when it is not immediately clear whether an action has completed. An error on our side does not, by itself, tell us what happened on the other side. Sending another request may be the wrong next step. We first need to investigate what has already been processed. The recorded intention and request ID give us a starting point.
Logging becomes part of managing the money flows. It helps us investigate unclear entries and give a provider specific information. Their team can investigate a request using a concrete reference and the operation associated with it.
Preserving the context around a transaction
Financial records do not tell the whole story when a user disputes a transaction. We can therefore also examine relevant account events together. When did someone log in, which device did they use, and when were card details viewed? Together, those records help us reconstruct the events around a transaction.
This gives us leads to investigate, without treating every unusual event as an explanation. An audit trail does not automatically prove who performed an action. Its value lies in checking possible explanations against what was actually recorded. In financial software, that information needs to be available when a question arises.
What it made possible
Building further on the same foundation
Getsby has a mobile web app where users buy, top up and manage their payment cards. Its architecture has proved useful when replacing external services. We could change payment routes while retaining the existing product logic. And when questions arise about transactions, we have records to investigate how they were processed.
We use that foundation for the next steps too. Our work continues through ongoing development and maintenance and support. Experience from using the app helps us decide with Getsby which integrations, features or checks need attention.
Checking the effects of a change
Being able to change one part separately is only useful if we can also check that the whole still works. We use an extensive automated test suite for this. It helps us check existing behaviour when making a change, including outside the part we are working on. We also review the change manually on staging and, where available, use the provider's test environment to exercise the integration.
Our experience with international payments also showed the limits of those checks. Our own test accounts cannot cover every combination users bring to the product. After a rollout, we therefore follow processing in production too: do payments complete, and does the outcome match what we expect? Tests and monitoring complement each other, and we use what we learn to improve the software further.
What we take forward
What Getsby teaches us
Depending on financial service providers calls for deliberate choices in your own software. These three considerations proved particularly valuable at Getsby.
Keep providers replaceable
We could replace payment routes because their integrations were kept separate. The logic for buying and managing cards could stay in place.
In future projects
We establish which knowledge about a provider belongs within its integration. This keeps the provider from unnecessarily shaping the rest of the product.
Record the intention too
Investigating a money flow requires records of both the intended action and its processing. A unique request ID connects those records.
In future projects
We design the records for important actions alongside the actions themselves. Missing information often cannot be recovered after the event.
Testing continues after launch
International use introduced payment combinations we could not check with our own test accounts. Production behaviour gave us additional information about the integrations.
In future projects
We combine checks before a release with monitoring the process afterwards. That includes checking whether a payment actually completes.
Ewout
Dependent on external integrations?
Does your product need to keep working as providers, payment routes or user needs change? Tell us where you are running into difficulties. We can help you work through the technical choices and ongoing development.