De Transaction Gateway Unit (TGU)

Wat is de Transaction Gateway Unit (TGU)?

De Transaction Gateway Unit (TGU) is het onderdeel van het Pay.-platform waar betaalopdrachten worden aangemaakt en betalingen daadwerkelijk worden verwerkt. Door meerdere TGU's te gebruiken, kan Pay. betaalverkeer over verschillende processing-omgevingen verdelen en de beschikbaarheid van de betaalflow verhogen.

Wanneer een klant in een webshop, app of op een betaalterminal wil betalen, moet er achter de schermen veel gebeuren. De betaalopdracht moet worden aangemaakt, de juiste betaalmethode moet worden geselecteerd en de transactie moet via de juiste processor, acquirer of betaalmethode worden verwerkt.

Binnen het Pay.-platform begint dit proces bij de Transaction Gateway Unit, afgekort TGU.

Wat doet een TGU?

Een TGU is een transaction gateway unit binnen het Pay.-platform. De TGU bevindt zich aan het begin van de technische betaalflow en verwerkt de API-aanvragen waarmee nieuwe betaalopdrachten worden gestart.

Een vereenvoudigde flow ziet er als volgt uit:

Webshop / POS / App → Order Create → TGU → Payment Method / Processor / Acquirer → Scheme / Bank

De TGU zorgt er onder andere voor dat:

een nieuwe Order wordt aangemaakt;
de gegevens van de betaalopdracht worden gevalideerd;
de gewenste betaalmethode wordt gestart;
een klant naar de juiste betaalomgeving kan worden geleid;
een betaling naar de juiste achterliggende processingroute wordt gestuurd;
statussen van de betaling worden verwerkt;
de merchant via exchanges/webhooks op de hoogte kan worden gehouden van statuswijzigingen.

De TGU vormt daarmee de toegangspoort tot de transactionele processinglaag van Pay.

Een betaling begint met Order Create

Bij een moderne integratie wordt een betaling gestart met een Order:Create request richting de TGU.

Bijvoorbeeld:

POST https://connect.pay.nl/v1/orders

Een Order vertegenwoordigt de commerciële bestelling zoals die bij de merchant bestaat. Binnen deze Order kunnen vervolgens één of meerdere betalingen plaatsvinden.

Bij het aanmaken van de Order kunnen onder andere worden meegestuurd:

het bedrag en de valuta;
de Service Location (SL-code);
de referentie van de merchant;
de omschrijving;
de gewenste betaalmethode;
klantgegevens;
orderregels;
de return URL;
de exchange URL;
informatie voor optimalisatie en routing.

Na het aanmaken van de Order retourneert de TGU onder andere een unieke Order-identificatie, de status en de benodigde URL's om de betaling te vervolgen.

Order en Payment zijn niet hetzelfde

Een belangrijk onderdeel van de TGU-architectuur is het onderscheid tussen een Order en een Payment.

De Order vertegenwoordigt wat de klant moet betalen. Een Payment vertegenwoordigt een daadwerkelijke betaalpoging binnen die Order.

Dat betekent dat één Order meerdere Payments kan bevatten.

Bijvoorbeeld:

Order €100
→ Payment 1: voucher €25
→ Payment 2: iDEAL/Wero €75
→ Order volledig betaald

Maar ook:

Order €100
→ Payment 1: kaartbetaling mislukt
→ Payment 2: nieuwe kaartbetaling succesvol
→ Order betaald

Deze scheiding maakt de betaalarchitectuur flexibeler. Een merchant hoeft niet voor iedere betaalpoging een volledig nieuwe commerciële bestelling te creëren. De Order API ondersteunt expliciet meerdere betalingen binnen één Order.

Waarom gebruikt Pay. meerdere TGU's?

Betalingsverkeer is bedrijfskritisch. Tegelijkertijd bestaat een betaling uit een keten van verschillende technische systemen en externe partijen.

Daarom is het Pay.-platform opgezet als een Multicore Platform met meerdere Transaction Gateway Units.

Binnen de productieomgeving zijn meerdere TGU's beschikbaar. De documentatie noemt momenteel TGU1 t/m TGU6 voor de productie-core. Daarnaast bestaan aparte omgevingen voor onder meer beta, backup en private/on-premise toepassingen.

Het doel hiervan is om de afhankelijkheid van één transaction processing unit te verkleinen.

In plaats van:

Merchant → één gateway → payment processing

kan een integratie gebruikmaken van:

Merchant
↘ TGU 1
→ TGU 2
↗ TGU 3 / andere TGU

De betaling kan daarna via verschillende achterliggende kanalen, processors en acquirers verder worden verwerkt.

Pay. adviseert daarom dat integraties voor het kritieke payment-processinggedeelte met minimaal twee TGU's overweg kunnen.

High availability begint vóór de betaling

Een belangrijk voordeel van de TGU-architectuur is dat beschikbaarheid niet alleen afhankelijk is van één centraal systeem.

Wanneer een TGU door een storing of onderhoud tijdelijk niet beschikbaar is, kan een goed ingerichte integratie een andere beschikbare TGU gebruiken. De introductie van het TGU-platform is specifiek ontworpen om het wisselen tussen TGU's eenvoudiger te maken.

Dat betekent overigens niet dat iedere betaalstoring automatisch door een andere TGU kan worden opgelost.

Een betaling is afhankelijk van een volledige keten:

Merchant → TGU → Pay. routing → Processor/Acquirer → Scheme/Payment Method → Issuer/Bank

Wanneer bijvoorbeeld de issuer van de consument of een specifieke betaalmethode niet beschikbaar is, kan een andere TGU die externe storing niet oplossen.

De Multicore-architectuur vermindert vooral de afhankelijkheid van één Pay.-processingomgeving en maakt aanvullende routingmogelijkheden mogelijk.

TGU versus GMS

Binnen het Pay.-platform moet onderscheid worden gemaakt tussen de TGU en het Global Management System (GMS).

TGU – Transaction Gateway Unit

De TGU is gericht op de tijdkritische transactionele verwerking:

"Ik wil nu een betaling starten of verwerken."

GMS – Global Management System

Het GMS verzorgt de bredere management- en administratieve functies rondom betalingen, zoals merchantinformatie, configuratie, rapportages, inzichten, uitbetalingen en andere beheerfuncties.

Pay. scheidt deze functies bewust. Payment processing vindt plaats binnen de TGU-laag, terwijl overige platformactiviteiten via het GMS verlopen.

Vereenvoudigd:

PAY. Platform

TGU
→ Order Create
→ Payment processing
→ Transactionele status
→ Payment routing

GMS
→ Merchant management
→ Configuratie
→ Reporting
→ Payouts
→ Invoicing
→ Insights

Hierdoor hoeft de meest kritieke betaalflow niet volledig afhankelijk te zijn van dezelfde systemen die bijvoorbeeld rapportages of administratieve functies verzorgen.

Routing achter de TGU

Het ontvangen van een Order is slechts het begin van de betaalflow.

Afhankelijk van onder andere de betaalmethode, configuratie en beschikbare processingroutes kan Pay. een betaling verder verwerken via verschillende kanalen, processors en acquirers. Pay. beschrijft in de platformarchitectuur expliciet dat transacties via verschillende kanalen, processors en acquirers kunnen worden gerouteerd.

Bij een kaartbetaling kan de vereenvoudigde flow bijvoorbeeld zijn:

Merchant
↓
Order Create
↓
TGU
↓
Payment Processing
↓
Acquirer / Processor
↓
Visa / Mastercard
↓
Issuer
↓
Kaarthouder

Bij een account-to-account betaalmethode kan het vervolg van de route uiteraard anders zijn.

De TGU vormt daarbij het transactionele startpunt, terwijl de uiteindelijke route afhankelijk is van de gekozen betaalmethode.

Exchanges en statusupdates

Een merchant moet niet alleen een betaling kunnen starten, maar ook betrouwbaar kunnen vaststellen wat ermee is gebeurd.

Bij het aanmaken van een Order kan daarom een exchangeUrl worden opgegeven. Pay. kan statuswijzigingen vervolgens naar deze URL sturen.

Voor extra zekerheid ondersteunt het platform signed exchanges. Daarbij wordt een exchange cryptografisch ondertekend, zodat de ontvangende partij kan controleren of het bericht daadwerkelijk afkomstig is van het Pay.-platform en of de ontvangen data geldig is.

Een merchant moet voor de definitieve verwerking van een bestelling daarom niet uitsluitend vertrouwen op het feit dat een consument na de betaling terugkeert op de returnUrl.

De transactionele status is leidend.

RESTful API

De moderne TGU-integratie maakt gebruik van de RESTful API's van het Multicore Platform.

Voor transaction processing wordt onder andere gebruikgemaakt van:

connect.pay.nl

De Order API ondersteunt hierbij moderne betaalfunctionaliteit en vormt de basis voor nieuwe ontwikkelingen binnen het transaction processing-platform. Pay. adviseert merchants die nog gebruikmaken van de legacy processingomgeving om naar het Multicore Platform te migreren.

Waarom is de TGU belangrijk?

Voor een merchant lijkt een betaling vaak eenvoudig:

bedrag → betaalmethode → betaald

Technisch bestaat die betaling echter uit een keten van systemen, beslissingen en externe partijen.

De TGU abstraheert een groot deel van deze complexiteit.

De merchant communiceert met de transactionele API van Pay., terwijl Pay. daarachter de verbinding met verschillende betaalmethoden, processors, acquirers en andere onderdelen van de betaalinfrastructuur verzorgt.

Daarmee is de TGU niet simpelweg een API-endpoint, maar een belangrijk onderdeel van de transaction processing-architectuur van Pay.

Samengevat

De Transaction Gateway Unit (TGU) is de transactionele processinglaag van Pay.

Een moderne betaalflow begint met Order Create op een TGU. Binnen de Order kunnen vervolgens één of meerdere Payments worden uitgevoerd. De TGU verwerkt de transactionele flow en verbindt deze met de achterliggende betaalinfrastructuur.

Doordat het Pay.-platform uit meerdere TGU's bestaat, kan een integratie bovendien minder afhankelijk worden van één processingomgeving.

Kort gezegd:

Order → TGU → Payment → Routing → Processor/Acquirer → Scheme/Bank → Status

Daarmee vormt de TGU het technische hart van het starten en verwerken van betalingen binnen het Multicore Platform van Pay.