Kaartbetalingen
Kaartbetalingen: van de terminal naar de acquirer en terug naar het grootboek
EMV-terminals en betaalgateways verbonden met acquirers via ISO 8583 of API’s, met afwikkelingsbestanden die in het ERP worden afgestemd.
Blauwdruk
Scroll zijwaarts om de hele tekening te zien.
Kaartbetalingen: geautoriseerd aan de kassa, later afgewikkeld, in het ERP afgestemd
De terminal of checkout vraagt het aan de gateway, de gateway aan de acquirer, en de acquirer routeert naar het kaartsysteem en de uitgever. Afwikkelingsbestanden komen later binnen en worden in het ERP aan verkopen en kosten gekoppeld. Een timeout start een terugdraaiing, zodat de klant nooit dubbel wordt belast.
- Hoofdstroom
- Asynchroon
- Uitzonderingspad
De stroom in 8 stappen
De stroom, stap voor stap
- Van EMV-terminal of online checkout naar Betalingsgateway: Autorisatieverzoek, via EMV · REST/JSON (hoofdstroom).
- Van Betalingsgateway naar Acquirer: Autorisatie, via ISO 8583 (hoofdstroom).
- Van Acquirer naar Kaartsysteem en uitgever: Naar de uitgever gerouteerd, via ISO 8583 (hoofdstroom).
- Van Acquirer naar Betalingsgateway: Goedgekeurd of afgewezen, via ISO 8583 (asynchroon).
- Van Acquirer naar Integratielaag: Afwikkelings- en kostenbestanden, via SFTP (asynchroon).
- Van Integratielaag naar ERP: Afgewikkelde verkopen, kosten en uitbetalingen, via REST/JSON (hoofdstroom).
- Van Betalingsgateway naar EMV-terminal of online checkout: Geen antwoord op tijd: automatische terugdraaiing, via ISO 8583 0400 (uitzonderingspad).
- Van Integratielaag naar Betalingsoperationeel team: Afwikkelingsafwijking of terugboeking (uitzonderingspad).
Overzicht
Dit is het pad van een kaartbetaling, van de terminal of onlinecheckout naar de acquirer, het kaartsysteem en de uitgever, en terug. De klant wacht aan de kassa op het antwoord. Het geld, minus kosten, komt later binnen in een afwikkelingsbestand dat moet worden afgestemd op de omzet in uw ERP.
Het referentieontwerp stuurt autorisaties via een betaalgateway die de kaart tokeniseert en het verzoek naar de acquirer routeert, via ISO 8583 of de API van de acquirer. Afwikkelings- en kostenbestanden worden door de integratielaag opgehaald, aan de oorspronkelijke omzet gematcht en als omzet, kosten en uitbetalingen in het ERP geboekt.
Het ontwerp dekt ook wat misgaat. Een verzoek waarop op tijd geen antwoord komt, wordt omgekeerd, zodat de klant niet dubbel wordt belast. Een afwikkeling die niet matcht, of een terugboeking, gaat met de oorspronkelijke verkoop naar uw team voor betalingsoperaties.
Hoe de flow werkt
Begin bij de terminal of checkout
De EMV-terminal leest de chip- of contactloze kaart, of de onlinecheckout verzamelt de kaart via een gehoste pagina, en stuurt een autorisatieverzoek naar de gateway.
Autoriseer via de gateway
De gateway vervangt het kaartnummer door een token en stuurt de autorisatie naar de acquirer, via ISO 8583 of de API van de acquirer.
Routeer naar de uitgever
De acquirer routeert het verzoek via het kaartsysteem naar de uitgever, die het goedkeurt of afwijst.
Geef het antwoord terug
De goedkeuring of afwijzing keert langs dezelfde weg terug naar de terminal of checkout, met de responscode.
Ontvang de afwikkeling
De acquirer stuurt later afwikkelings- en kostenbestanden, die de integratielaag ophaalt en valideert.
Koppelen en boeken
De laag matcht afgewikkelde transacties aan de oorspronkelijke omzet en boekt omzet, kosten en uitbetalingen in het ERP.
Wat als er iets misgaat
Geen antwoord op tijd
Als de gateway binnen de tijdslimiet van de acquirer geen reactie krijgt, stuurt die een omkering, een ISO 8583 0400-bericht of het API-equivalent, zodat de klant nooit wordt belast voor een verkoop die niet is afgerond.
Een betaling wordt afgewezen
De responscode bereikt de kassa of checkout met een duidelijke melding. Afwijzingspercentages worden gemonitord, zodat een sprong die op een technische fout wijst een melding oplevert.
Afwikkeling matcht niet
Een afgewikkeld bedrag dat van de verkoop afwijkt, of een verkoop zonder afwikkeling, gaat naar een beoordelingslijst voor uw team voor betalingsoperaties, met beide registraties naast elkaar.
Een kaarthouder betwist een betaling
Het geschillenrapport van de acquirer wordt geïmporteerd en aan de oorspronkelijke verkoop en afwikkeling gekoppeld, zodat uw team op één plek met het bewijs kan reageren.
Standaarden en systemen
- Bankstandaarden en -kanalen
- SFTP (H2H)
- Betalingen
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integratie
- REST
- Webhooks
Vragen en antwoorden
Wat is het verschil tussen een gateway en een acquirer?
De acquirer is de bank of gelicentieerde instelling die uw kaartbetalingen verwerkt en het geld uitbetaalt. De gateway is de technische dienst ervoor die verzoeken van terminals en checkouts accepteert, kaarten tokeniseert en routeert. Sommige providers zijn beide. Het ontwerp werkt in beide gevallen en houdt de twee rollen gescheiden.
Houdt dit kaartdata buiten onze systemen?
Dat is het doel van het ontwerp. Kaartnummers worden vastgelegd door de gecertificeerde terminal of een gehoste betaalpagina en bij de gateway door tokens vervangen, zodat uw POS, ERP en datastores alleen tokens zien. Dit verkleint het deel van uw landschap waarop PCI DSS van toepassing is. Uw assessor bevestigt de definitieve scope.
Is ISO 8583 voor elke acquirer hetzelfde?
Nee. ISO 8583 definieert een structuur, en elke acquirer of elk netwerk publiceert een eigen specificatie van velden, berichttypen en codes. Daarom bouwen we vanuit de specificatie van de acquirer en draaien we zijn certificeringstests. Een gateway-API vóór de acquirer verbergt deze verschillen, wat voor retailers vaak eenvoudiger is.
Waarom komt de afwikkeling later dan de verkoop?
Autorisatie reserveert alleen de middelen. De acquirer wikkelt in batches af, na aftrek van zijn kosten en eventuele kaartkosten, en betaalt volgens zijn eigen schema uit. Daarom behandelt het ontwerp autorisatie en afwikkeling als aparte gebeurtenissen en matcht het ze, zodat finance ziet wat is verkocht, wat is afgewikkeld en wat nog moet binnenkomen.
Ondersteunt u EMV 3-D Secure voor onlinebetalingen?
Ja. Voor online kaartbetalingen integreren we EMV 3-D Secure via de gateway, zodat de uitgever de kaarthouder kan authenticeren waar regelgeving of risico dat vereist. We verwerken de challenge- en frictionless-stromen in de checkout en testen beide met de testkaarten van de provider.
Kunnen we meer dan één betaalprovider gebruiken?
Ja. De integratielaag houdt één intern model van een betaling en mapt dat naar elke provider, zodat u kunt routeren op kanaal, land of kaarttype, of volume tussen providers kunt verschuiven. Elke provider vraagt nog steeds een eigen integratie en certificering, die we provider voor provider plannen.
Begin met een gesprek, niet met een contract.
Vertel ons wat u wilt bouwen, verbinden of beveiligen. Een architect neemt het met u door en adviseert daarna waar te beginnen.
Wat er nu gebeurt
Een tijd afspreken
Ons team mailt u om een tijd voor de sessie af te spreken.
Voorgesprek
Een gratis online voorafgaand adviesgesprek van 30 minuten: we bespreken uw doelen, systemen en beperkingen.
Gereedheidsanalyse
In een gratis gereedheidsanalyse van 48 uur toetst een Principal Architect uw project aan de 6-punts Definition of Ready en adviseert het traject dat past.
Het traject kiezen
Projecten met een heldere scope ontvangen binnen 3–5 werkdagen een bindend voorstel. Projecten in de conceptfase starten in de Blueprint Studio. Een live systeem dat uitvalt, ongedocumenteerd is of integratie nodig heeft, begint met een diagnose van 1–2 weken. De Blueprint Studio en de diagnose hebben elk een vaste prijs, vermeld in het voorstel.