Kortbetalinger
Kortbetalinger: fra terminalen til indløseren og tilbage til hovedbogen
EMV-terminaler og betalingsgateways forbundet til indløsere via ISO 8583 eller API’er, med afregningsfiler afstemt i ERP-systemet.
Arkitekturskitse
Rul sidelæns for at se hele tegningen.
Kortbetalinger: autoriseret i kassen, afregnet senere, afstemt i ERP-systemet
Terminalen eller kassen spørger gatewayen, gatewayen spørger indløseren, og indløseren sender videre til kortordningen og udstederen. Afregningsfiler kommer senere og afstemmes med salg og gebyrer i ERP-systemet. En timeout udløser en tilbageførsel, så kunden aldrig bliver trukket to gange.
- Primært flow
- Asynkron
- Undtagelsessti
Forløbet i 8 trin
Forløbet, trin for trin
- Fra EMV-terminal eller onlinekasse til Betalingsgateway: Autoriseringsanmodning, over EMV · REST/JSON (primært flow).
- Fra Betalingsgateway til Indløser: Autorisering, over ISO 8583 (primært flow).
- Fra Indløser til Kortordning og udsteder: Sendt videre til udstederen, over ISO 8583 (primært flow).
- Fra Indløser til Betalingsgateway: Godkendt eller afvist, over ISO 8583 (asynkron).
- Fra Indløser til Integrationslag: Afregnings- og gebyrfiler, over SFTP (asynkron).
- Fra Integrationslag til ERP: Afregnet salg, gebyrer og udbetalinger, over REST/JSON (primært flow).
- Fra Betalingsgateway til EMV-terminal eller onlinekasse: Intet svar i tide: automatisk tilbageførsel, over ISO 8583 0400 (undtagelsessti).
- Fra Integrationslag til Betalingsdriftsteam: Afvigelse i afregning eller chargeback (undtagelsessti).
Oversigt
Dette er vejen for en kortbetaling, fra terminalen eller onlinekassen til indløseren, kortordningen og udstederen og tilbage igen. Kunden venter på svaret ved kassen. Pengene, fratrukket gebyrer, kommer senere i en afregningsfil, der skal afstemmes med salget i dit ERP-system.
Referencedesignet sender autorisationer gennem en betalingsgateway, der tokeniserer kortet og dirigerer anmodningen til indløseren via ISO 8583 eller indløserens API. Afregnings- og gebyrfiler indsamles af integrationslaget, afstemmes med det oprindelige salg og bogføres i ERP-systemet som salg, gebyrer og udbetalinger.
Designet dækker også det, der går galt. En anmodning, der ikke får svar i tide, tilbageføres, så kunden ikke bliver opkrævet to gange. En afregning, der ikke stemmer, eller en chargeback går til dit team for betalingsdrift med det oprindelige salg vedhæftet.
Sådan fungerer flowet
Start ved terminalen eller kassen
EMV-terminalen læser chippen eller det kontaktløse kort, eller onlinekassen indsamler kortoplysningerne via en hostet side og sender en autorisationsanmodning til gatewayen.
Autoriser via gatewayen
Gatewayen erstatter kortnummeret med et token og sender autorisationen til indløseren via ISO 8583 eller indløserens API.
Send videre til udstederen
Indløseren sender anmodningen gennem kortordningen til udstederen, som godkender eller afviser den.
Send svaret tilbage
Godkendelsen eller afvisningen går samme vej tilbage til terminalen eller kassen med sin svarkode.
Modtag afregningen
Indløseren sender senere afregnings- og gebyrfiler, som integrationslaget indsamler og validerer.
Afstem og bogfør
Laget afstemmer afregnede transaktioner med det oprindelige salg og bogfører salg, gebyrer og udbetalinger i ERP-systemet.
Når noget fejler
Intet svar i tide
Hvis gatewayen ikke får svar inden for indløserens tidsfrist, sender den en tilbageførsel, en ISO 8583 0400-meddelelse eller det tilsvarende API-kald, så kunden aldrig bliver debiteret for et salg, der ikke blev gennemført.
En betaling afvises
Svarkoden når frem til kassen eller onlinekassen med en tydelig besked. Afvisningsrater overvåges, så et spring, der tyder på en teknisk fejl, udløser en alarm.
Afregningen stemmer ikke
Et afregnet beløb, der afviger fra salget, eller et salg uden afregning kommer på en gennemgangsliste for dit team for betalingsdrift med begge poster side om side.
En kortindehaver bestrider en betaling
Indløserens tvistrapport importeres og knyttes til det oprindelige salg og den tilhørende afregning, så dit team kan svare med dokumentationen samlet ét sted.
Standarder og systemer
- Bankstandarder og bankkanaler
- SFTP (H2H)
- Betalinger
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integration
- REST
- Webhooks
Spørgsmål og svar
Hvad er forskellen på en gateway og en indløser?
Indløseren er den bank eller det licenserede institut, der behandler kortbetalinger for dig og udbetaler pengene. Gatewayen er den tekniske service foran den, som modtager anmodninger fra terminaler og kasser, tokeniserer kort og dirigerer dem videre. Nogle udbydere er begge dele. Designet fungerer i begge tilfælde og holder de to roller klart adskilt.
Holder det kortdata ude af vores systemer?
Det er formålet med designet. Kortnumre registreres af den certificerede terminal eller en hostet betalingsside og erstattes af tokens i gatewayen, så dit POS-system, dit ERP-system og dine datalagre kun nogensinde ser tokens. Det mindsker den del af dit IT-landskab, som PCI DSS gælder for. Din assessor bekræfter det endelige omfang.
Er ISO 8583 ens for alle indløsere?
Nej. ISO 8583 definerer en struktur, og hver indløser eller hvert netværk udgiver sin egen specifikation af felter, meddelelsestyper og koder. Derfor bygger vi ud fra indløserens specifikation og kører dens certificeringstests. Et gateway-API foran indløseren skjuler disse forskelle, hvilket ofte er enklere for detailhandlere.
Hvorfor kommer afregningen senere end salget?
Autorisationen reserverer kun midlerne. Indløseren afregner i batches efter at have fratrukket sine gebyrer og eventuelle gebyrer til kortordningen og udbetaler efter sin egen tidsplan. Derfor behandler designet autorisation og afregning som separate hændelser og afstemmer dem, så økonomiafdelingen kan se, hvad der blev solgt, hvad der blev afregnet, og hvad der stadig mangler at komme.
Understøtter I EMV 3-D Secure til onlinebetalinger?
Ja. Til online kortbetalinger integrerer vi EMV 3-D Secure via gatewayen, så udstederen kan autentificere kortindehaveren, hvor regulering eller risiko kræver det. Vi håndterer både challenge-flowet og det friktionsfrie flow i kassen og tester begge med udbyderens testkort.
Kan vi bruge mere end én betalingsudbyder?
Ja. Integrationslaget har én intern model af en betaling og oversætter den til hver udbyder, så du kan dirigere efter kanal, land eller korttype eller flytte volumen mellem udbydere. Hver udbyder kræver stadig sin egen integration og certificering, som vi planlægger udbyder for udbyder.
Start med en samtale, ikke en kontrakt.
Fortæl os, hvad du skal bygge, forbinde eller sikre. En arkitekt gennemgår det med dig og anbefaler derefter, hvor du skal starte.
Det sker der nu
Aftale om tidspunkt
Vores team sender dig en e-mail for at aftale et tidspunkt for sessionen.
Forhåndskonsultation
En gratis online forhåndskonsultation på 30 minutter: vi gennemgår dine mål, systemer og begrænsninger.
Parathedsanalyse
I en gratis parathedsanalyse på 48 timer tjekker en ledende arkitekt dit projekt op mod de 6 punkter i Definition of Ready og anbefaler det spor, der passer.
Valg af spor
Projekter med et klart omfang modtager et bindende forslag inden for 3 til 5 hverdage. Projekter i konceptfasen starter i Blueprint Studio. Et system i drift, der fejler, er udokumenteret eller skal integreres, starter med en diagnosticering på 1 til 2 uger. Blueprint Studio og diagnosticeringen har hver et fast honorar, som er angivet i forslaget.