Eén betaling, vijf statussen, en bij twee daarvan een mens
Versie 1 is bewust klein en bewust handmatig. Alles hieronder beschrijft wat er werkelijk gebeurt, inclusief de delen die een machine nog niet doet.
Waar het geld zich op elk moment bevindt
Waarom het betalingskenmerk verplicht is
Een bijschrijving komt binnen met een bedrag, een afzender en een vrije omschrijving. Die omschrijving is het enige wat de betaling aan een boeking verbindt, en daarom wordt zij afgedwongen in plaats van aangemoedigd, en is zij zo opgemaakt dat zij zichtbaar afwijkt van elk ander betalingskenmerk dat onze boekhouders onder ogen krijgen.
Een bijschrijving die zonder kenmerk binnenkomt, wordt niet geweigerd — die gaat naar een wachtrij en een mens redeneert terug vanuit het bedrag en de afzender.
Twee handmatige wachtrijen
Bijschrijvingen aan boekingen koppelen, en vrijgaves fiatteren. In versie 1 is er geen bank-API, dus deze twee wachtrijen vormen de werkelijke capaciteitsgrens van het product. Vrijgaves boven een drempelbedrag vereisen een tweede fiatteur, en elke fiattering wordt vastgelegd in een auditlog, met de naam van degene die erop heeft geklikt.
De gevallen die bepalen of iemand dit vertrouwt
Een vertrouwensproduct wordt volledig beoordeeld op de scenario's waarin het misgaat. Die zijn vooraf beantwoord, zodat niemand hoeft te improviseren met het geld van een ander.
Het reisbureau geeft nooit een ticket uit
De bezwaartermijn verstrijkt en de reiziger krijgt het volledige bedrag terug. Het reisbureau hoeft daar niet mee in te stemmen, en niets aan de terugbetaling vereist zijn medewerking — die onafhankelijkheid is precies waar deze constructie om draait.
Het ticket bestaat, maar klopt niet
Verkeerde passagier, verkeerde route, verkeerde datum. Dit geldt als geen geldig ticket: het bewijs van uitgifte wordt getoetst aan de boeking zoals die is verkocht, en niet enkel aan het bestaan van een ticketnummer.
De reiziger maakt het verkeerde bedrag over
Een onderbetaling wordt gemarkeerd in plaats van automatisch geweigerd. Kleine tekorten zijn meestal kosten van tussenbanken, en een systeem dat ze terugstuurt creëert twee problemen in plaats van er één op te lossen. Een mens beslist.
De reiziger bedenkt zich
Vóór de vrijgave is het geld in elk praktisch opzicht nog van hem, en de annuleringsvoorwaarden van het bureau gelden voor de boeking en niet voor het geld. Escrow schept geen recht op annulering, maar het betekent wel dat niemand achter een bureau aan hoeft voor een terugbetaling die het al heeft uitgegeven.
Het geld komt binnen nadat de reserveringstermijn is verstreken
De stoel kan weg zijn terwijl er met de betaling niets mis is. De bijschrijving wordt gekoppeld, de boeking wordt als verlopen gemarkeerd en het geld wordt teruggestort in plaats van vastgehouden voor een boeking die niet meer bestaat.
Iemand betwist het later
Elke statuswijziging wordt vastgelegd met een tijdstempel en een handelende persoon, en de statuspagina van de reiziger blijft 24 maanden beschikbaar. Beide partijen zien dezelfde vastlegging.
Wat een reisbureau werkelijk bouwt
Eén doorverwijzing heen, twee webhooks terug. Onze eigen reismerken zijn merchant nummer één en gebruiken dezelfde publieke API, dus er is geen privéroute die beter werkt dan de uwe.
1 · Maak de betaling aan
Server-side aanroep met de boeking, het bedrag, de valuta en het e-mailadres van uw klant. U krijgt een betalingskenmerk en een portaal-URL terug.
2 · Stuur de reiziger door
Verwijs door naar de portaal-URL in plaats van uw eigen bankgegevens te tonen. Alles wat de reiziger nodig heeft — begunstigde, IBAN, kenmerk, uiterste datum — staat daar.
3 · Luister naar twee gebeurtenissen
payment.held geeft aan dat het geld binnen is en dat u het ticket veilig kunt uitgeven. payment.released geeft aan dat het is uitbetaald. De gebeurtenis payment.returned sluit het scenario af waarin het misgaat.
Het contract van de merchant-API wordt geschreven naast de eerste pilotintegraties in plaats van vooraf gepubliceerd, zodat de bureaus in de pilot het mede vormgeven. Vraag ons om het huidige concept.
Bekijk het van de kant van de reiziger
De vier schermen die een klant doorloopt, en de pagina waarop hij belandt wanneer hij onze naam opzoekt nadat hem is gevraagd geld naar ons over te maken.