Fintech met ruimte voor verandering
Getsby biedt virtuele betaalkaarten aan via een mobiele app. We bouwden de software waarmee gebruikers hun kaarten aanschaffen, opwaarderen en beheren. De technische basis houdt ruimte om financiële dienstverleners te vervangen en maakt geldstromen achteraf herleidbaar. Zo kan Getsby verder bouwen aan het product, met zicht op wat er met iedere transactie gebeurt.
Virtuele betaalkaarten aanschaffen, opwaarderen en beheren vanuit één app.
- Branche
- Fintech
Team
De uitdaging
Eén betaalapp, meerdere financiële partijen
Een virtuele betaalkaart aanmaken, er geld op zetten en ermee betalen: voor een gebruiker hoort dat een overzichtelijk proces te zijn. Getsby brengt die handelingen samen in een app die vooral op de telefoon wordt gebruikt. De software vormt daarmee de kern van het bedrijf. Hier worden klanten geregistreerd, kaarten aangeschaft en betalingen verwerkt.
Achter die ene app werken verschillende financiële partijen. Ze verzorgen onder meer de identiteitscontrole, de betaling en de uitgifte van kaarten. Getsby is afhankelijk van hun dienstverlening, terwijl de gebruiker het geheel als één product ervaart. Onze opdracht was om daar een samenhangende applicatie van te maken, waarin de eigen productlogica en de externe processen goed op elkaar aansluiten.
Ruimte voor de volgende stap
Een financieel product blijft zich ontwikkelen. Gebruikers verwachten andere betaalmogelijkheden, een leverancier wijzigt zijn dienstverlening of een bestaande koppeling blijkt niet goed genoeg aan te sluiten op het gebruik. Zulke veranderingen raken al snel de kern van de applicatie. Een andere betaalprovider kan bijvoorbeeld gevolgen hebben voor de manier waarop een aankoop wordt afgehandeld en hoe de status daarvan wordt teruggegeven.
Daarom hielden we bij de bouw al rekening met het vervangen van koppelingen. We wilden voorkomen dat een keuze voor een leverancier zo diep in de software terechtkwam dat een overstap een verbouwing van de hele applicatie zou worden. Getsby moest kunnen blijven kiezen welke dienstverlening bij het product past. Dat bepaalde hoe we de software indeelden en waar we grenzen tussen onderdelen aanbrachten.
De vraag achter de vraag
De vrijheid om van leverancier te wisselen
Welke onderdelen horen bij Getsby zelf, en welke bij een externe dienstverlener? Dat onderscheid was belangrijker dan vooraf proberen te voorspellen welke leverancier over een paar jaar de beste keuze zou zijn. Het product moest ruimte houden voor een andere keuze, zonder dat we daarvoor opnieuw moesten beginnen.
We brachten registratie, identiteitscontrole en betaling onder in afzonderlijke delen van de applicatie. Binnen zo'n onderdeel houden we de afspraken met een leverancier zoveel mogelijk in de koppeling zelf. Die vertaalt wat Getsby nodig heeft naar de manier waarop de leverancier werkt. De rest van het product gebruikt de handelingen en statussen die we voor Getsby hebben gedefinieerd.
Gericht kunnen ingrijpen bij een betaalprovider
De waarde van die opzet werd zichtbaar toen de app internationaal in gebruik kwam. Bij een van de betaalroutes werden betalingen niet betrouwbaar genoeg afgerond. Het verschil zat in combinaties van banken, kaarten en valuta die tijdens onze eigen tests niet naar voren waren gekomen. Dat vroeg om een oplossing: gebruikers moesten hun aankoop kunnen voltooien, en mislukte betalingen brachten support- en herstelwerk mee.
We onderzochten eerst samen met de betaalprovider of de bestaande route voldoende kon worden verbeterd. Toen dat onvoldoende resultaat gaf, konden we de afhandeling bij een andere partij onderbrengen. Doordat de koppeling was afgebakend, bleef de aanpassing grotendeels binnen het betaalonderdeel. We hoefden de logica voor het aanschaffen en beheren van kaarten niet opnieuw op te zetten.
De afweging achter die flexibiliteit
Die scheiding ontstaat niet vanzelf. Per koppeling moeten we bepalen welke gegevens en statussen de rest van de applicatie nodig heeft, en welke details alleen voor die leverancier relevant zijn. Dat vraagt extra denkwerk bij de bouw. Als leveranciersspecifieke details toch overal in de code worden gebruikt, verdwijnt het voordeel zodra er iets verandert.
Een nieuwe provider aansluiten blijft dus ontwikkelwerk. De winst zit in de omvang en de voorspelbaarheid van die wijziging: we weten welk onderdeel moet worden aangepast en welke afspraken met de rest van de applicatie behouden moeten blijven. Bij Getsby gaf dat de ruimte om een leverancierskeuze te herzien op basis van praktijkervaring, zonder ook registratie en kaartbeheer opnieuw te ontwerpen.
Techniek die het verschil maakt
Iedere geldstroom kunnen reconstrueren
Bij een betaalapp moet achteraf uit te leggen zijn wat er met een transactie is gebeurd. Welke handeling heeft de gebruiker gestart, welk verzoek hebben wij daarvoor verstuurd en hoe heeft de financiële partner dat verwerkt? Die vragen worden belangrijk zodra de uitkomst onduidelijk is of een gebruiker een betaling niet herkent.
We hebben die herleidbaarheid vanaf de inrichting van de geldstromen meegenomen. De registratie bewaart de samenhang tussen de bedoelde handeling en de verwerking door de externe partij. Zo hebben we bij onderzoek een concreet spoor om te volgen en kunnen we ook met de leverancier bespreken waar een verschil is ontstaan.
Een request-ID verbindt de stappen
Elk verzoek aan de bankkoppeling krijgt een uniek request-ID. Dat bewaren we samen met de bedoeling van het verzoek: welke handeling wilden we uitvoeren? Hetzelfde ID helpt vervolgens om dat verzoek terug te vinden bij de financiële partner. We kunnen daardoor onze registratie naast die van de leverancier leggen en controleren of we het over dezelfde handeling hebben.
Dat is vooral van belang wanneer niet direct duidelijk is of een handeling is afgerond. Een foutmelding aan onze kant vertelt op zichzelf nog niet wat er aan de andere kant is gebeurd. Opnieuw een verzoek versturen kan dan de verkeerde vervolgstap zijn. We moeten eerst kunnen onderzoeken wat al is verwerkt. De vastgelegde bedoeling en het request-ID geven daarvoor het vertrekpunt.
Zo wordt logging onderdeel van het beheer van de geldstromen. Het helpt ons om onduidelijke boekingen uit te zoeken en om een leverancier gerichte informatie te geven. Die kan een verzoek onderzoeken aan de hand van een concrete referentie en de handeling die daarbij hoort.
De context rond een transactie bewaren
Een financiële registratie vertelt niet het hele verhaal wanneer een gebruiker een transactie betwist. Daarom kunnen we ook relevante gebeurtenissen binnen het account in samenhang bekijken. Wanneer is iemand ingelogd, vanaf welk apparaat en wanneer zijn kaartgegevens bekeken? Samen helpen die gegevens om de gebeurtenissen rond een transactie te reconstrueren.
Dat geeft ons aanknopingspunten voor onderzoek, zonder dat iedere afwijking meteen een verklaring is. Een audittrail bewijst bijvoorbeeld niet automatisch wie achter een handeling zat. De waarde zit in het kunnen toetsen van mogelijke verklaringen aan wat daadwerkelijk is vastgelegd. Juist bij financiële software moet die informatie beschikbaar zijn op het moment dat een vraag zich voordoet.
Wat het mogelijk maakte
Verder bouwen op dezelfde basis
Getsby heeft een mobiele webapp waarin gebruikers hun betaalkaarten aanschaffen, opwaarderen en beheren. De technische opzet heeft zich inmiddels bewezen bij het vervangen van externe dienstverlening. We konden betaalroutes aanpassen terwijl de bestaande productlogica behouden bleef. En wanneer er vragen zijn over transacties, beschikken we over gegevens om de verwerking te onderzoeken.
Die basis gebruiken we ook voor de volgende stappen. De samenwerking loopt door in structurele doorontwikkeling en onderhoud en support. Ervaringen uit het gebruik van de app helpen ons om samen met Getsby te bepalen welke koppelingen, functies of controles aandacht nodig hebben.
Veranderingen gericht controleren
De mogelijkheid om een onderdeel afzonderlijk aan te passen is pas bruikbaar als we ook kunnen controleren of het geheel blijft werken. Daarvoor gebruiken we een uitgebreide geautomatiseerde testsuite. Die helpt om bij een wijziging bestaande werking te controleren, ook buiten het onderdeel waaraan we werken. Op staging beoordelen we de wijziging daarnaast handmatig; waar beschikbaar gebruiken we de testomgeving van de leverancier om de koppeling te doorlopen.
De ervaring met internationale betalingen liet ook zien waar die controles ophouden. Onze eigen testrekeningen dekken niet iedere combinatie die gebruikers in de praktijk meebrengen. Daarom volgen we na een uitrol ook de verwerking in productie: worden betalingen afgerond en komt de uitkomst overeen met wat we verwachten? Zo vullen tests en monitoring elkaar aan, en gebruiken we nieuwe inzichten om de software verder te verbeteren.
Wat we meenemen
Wat we van Getsby leren
De afhankelijkheid van financiële dienstverleners vraagt om bewuste keuzes in de eigen software. Bij Getsby werden vooral deze drie afwegingen belangrijk.
Houd leveranciers vervangbaar
We konden betaalroutes vervangen doordat de koppelingen afzonderlijk waren ingericht. De logica voor het aanschaffen en beheren van kaarten kon blijven bestaan.
Bij volgende projecten
We bepalen welke kennis over een leverancier binnen de koppeling hoort. Zo wordt die leverancier niet onnodig bepalend voor de rest van het product.
Bewaar ook de bedoeling
Om een geldstroom te onderzoeken, moeten we zowel de bedoelde handeling als de verwerking kunnen terugvinden. Een uniek request-ID verbindt die gegevens.
Bij volgende projecten
We ontwerpen de registratie van belangrijke handelingen tegelijk met de handelingen zelf. Achteraf ontbrekende informatie alsnog verzamelen is vaak niet mogelijk.
Testen gaat door na livegang
Bij internationaal gebruik zagen we betaalcombinaties die met onze eigen testrekeningen niet te controleren waren. Productiegedrag gaf daardoor aanvullende informatie over de koppelingen.
Bij volgende projecten
We combineren controles vóór een release met het volgen van het proces daarna. Daarbij kijken we ook of een betaling daadwerkelijk wordt afgerond.
Ewout
Afhankelijk van externe koppelingen?
Moet jouw product blijven werken terwijl leveranciers, betaalroutes of gebruikerswensen veranderen? Vertel ons waar je tegenaan loopt. We denken mee over de technische keuzes en de doorontwikkeling.