Kortbetalinger
Kortbetalinger: fra terminalen til innløseren og tilbake til hovedboken
EMV-terminaler og betalingsgatewayer koblet til innløsere over ISO 8583 eller API-er, med oppgjørsfiler avstemt i ERP-systemet.
Blueprint
Rull sidelengs for å se hele tegningen.
Kortbetalinger: autorisert i kassen, gjort opp senere, avstemt i ERP
Terminalen eller kassen spør betalingsgatewayen, betalingsgatewayen spør innløseren, og innløseren ruter til kortordningen og utstederen. Oppgjørsfiler kommer senere og avstemmes mot salg og gebyrer i ERP. En tidsavbrudd utløser en tilbakeføring, slik at kunden aldri belastes to ganger.
- Hovedforløp
- Asynkron
- Unntaksbane
Forløpet i 8 steg
Forløpet, steg for steg
- Fra EMV-terminal eller nettkasse til Betalingsgateway: Autorisasjonsforespørsel, over EMV · REST/JSON (hovedforløp).
- Fra Betalingsgateway til Innløser: Autorisasjon, over ISO 8583 (hovedforløp).
- Fra Innløser til Kortordning og utsteder: Rutes til utsteder, over ISO 8583 (hovedforløp).
- Fra Innløser til Betalingsgateway: Godkjent eller avvist, over ISO 8583 (asynkron).
- Fra Innløser til Integreringslag: Oppgjørs- og gebyrfiler, over SFTP (asynkron).
- Fra Integreringslag til ERP: Oppgjorte salg, gebyrer og utbetalinger, over REST/JSON (hovedforløp).
- Fra Betalingsgateway til EMV-terminal eller nettkasse: Ingen respons i tide: automatisk tilbakeføring, over ISO 8583 0400 (unntaksbane).
- Fra Integreringslag til Betalingsteamet: Avstemmingsavvik eller tilbakeføring (unntaksbane).
Oversikt
Dette er veien en kortbetaling tar, fra terminalen eller nettkassen til innløseren, kortordningen og utstederen, og tilbake. Kunden venter på svaret i kassen. Pengene, minus gebyrer, kommer senere i en oppgjørsfil som må avstemmes mot salget i ERP-systemet.
Referansedesignet sender autorisasjoner gjennom en betalingsgateway som tokeniserer kortet og ruter forespørselen til innløseren, over ISO 8583 eller innløserens API. Oppgjørs- og gebyrfiler hentes av integreringslaget, avstemmes mot det opprinnelige salget og posteres i ERP-systemet som salg, gebyrer og utbetalinger.
Designet dekker også det som går galt. En forespørsel som ikke får svar i tide, tilbakeføres, slik at kunden ikke belastes to ganger. Et oppgjør som ikke stemmer, eller en tilbakeføring (chargeback), går til betalingsteamet ditt med det opprinnelige salget vedlagt.
Slik fungerer flyten
Start ved terminalen eller nettkassen
EMV-terminalen leser chipen eller det kontaktløse kortet, eller nettkassen henter kortet gjennom en hostet betalingsside, og sender en autorisasjonsforespørsel til gatewayen.
Autoriser gjennom gatewayen
Gatewayen erstatter kortnummeret med et token og sender autorisasjonen til innløseren, over ISO 8583 eller innløserens API.
Rut til utstederen
Innløseren ruter forespørselen gjennom kortordningen til utstederen, som godkjenner eller avviser den.
Returner svaret
Godkjenningen eller avvisningen kommer tilbake samme vei til terminalen eller nettkassen, med svarkoden sin.
Motta oppgjør
Innløseren sender senere oppgjørs- og gebyrfiler, som integreringslaget henter og validerer.
Avstem og poster
Laget avstemmer oppgjørstransaksjonene mot det opprinnelige salget og posterer salg, gebyrer og utbetalinger i ERP-systemet.
Når noe feiler
Ingen svar i tide
Hvis gatewayen ikke får svar innen innløserens tidsgrense, sender den en tilbakeføring, en ISO 8583 0400-melding eller tilsvarende i API-et, slik at kunden aldri belastes for et salg som ikke ble fullført.
En betaling avvises
Svarkoden når kassen eller nettkassen med en tydelig melding. Avvisningsraten overvåkes, slik at et hopp som peker på en teknisk feil utløser et varsel.
Oppgjøret stemmer ikke
Et oppgjørsbeløp som avviker fra salget, eller et salg uten oppgjør, går til en gjennomgangsliste for betalingsdriftsteamet ditt, med begge postene side om side.
En kortholder bestrider en betaling
Innløserens tvistrapport importeres og kobles til det opprinnelige salget og oppgjøret, slik at teamet ditt kan svare med dokumentasjonen på ett sted.
Standarder og systemer
- Bankstandarder og bankkanaler
- SFTP (H2H)
- Betalinger
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integrasjon
- REST
- Webhooks
Spørsmål og svar
Hva er forskjellen på en gateway og en innløser?
Innløseren er banken eller den konsesjonsbelagte institusjonen som behandler kortbetalinger for deg og utbetaler pengene. Betalingsgatewayen er den tekniske tjenesten foran som tar imot forespørsler fra terminaler og kasser, tokeniserer kort og ruter dem. Noen leverandører er begge. Designet fungerer uansett og holder de to rollene tydelig atskilt.
Holder dette kortdata ute av systemene våre?
Det er målet med designet. Kortnumre fanges opp av den sertifiserte terminalen eller en hostet betalingsside og erstattes av token i betalingsgatewayen, slik at POS, ERP og datalagrene dine bare ser token. Dette reduserer den delen av løsningen din som PCI DSS gjelder for. Revisoren din bekrefter det endelige omfanget.
Er ISO 8583 likt hos alle innløsere?
Nei. ISO 8583 definerer en struktur, og hver innløser eller kortnettverk publiserer sin egen spesifikasjon av felt, meldingstyper og koder. Derfor bygger vi ut fra innløserens spesifikasjon og kjører sertifiseringstestene deres. En gateway-API foran innløseren skjuler disse forskjellene, noe som ofte er enklere for detaljhandelen.
Hvorfor kommer oppgjøret senere enn salget?
Autorisasjon reserverer bare midlene. Innløseren gjør opp satsvis, etter å ha trukket fra gebyrene sine og eventuelle kortordningsgebyrer, og utbetaler etter sin egen plan. Derfor behandler designet autorisasjon og oppgjør som separate hendelser og avstemmer dem, slik at finans kan se hva som er solgt, hva som er gjort opp og hva som fortsatt skal komme.
Støtter dere EMV 3-D Secure for nettbetalinger?
Ja. For kortbetalinger på nett integrerer vi EMV 3-D Secure gjennom betalingsgatewayen, slik at utstederen kan autentisere kortholderen der regelverket eller risikoen krever det. Vi håndterer utfordrings- og friksjonsfrie flyter i kassen og tester begge med leverandørens testkort.
Kan vi bruke mer enn én betalingsleverandør?
Ja. Integreringslaget holder én intern modell av en betaling og mapper den til hver leverandør, slik at du kan rute etter kanal, land eller korttype, eller flytte volum mellom leverandører. Hver leverandør trenger fortsatt sin egen integrasjon og sertifisering, som vi planlegger leverandør for leverandør.
Start med en samtale, ikke en kontrakt.
Fortell oss hva du trenger å bygge, koble sammen eller sikre. En arkitekt går gjennom det med deg og anbefaler deretter hvor du bør starte.
Hva skjer videre
Avtale tid
Teamet vårt sender deg en e-post for å avtale tid til samtalen.
Forhåndssamtale
En gratis forhåndssamtale på 30 minutter på nett: vi går gjennom målene, systemene og begrensningene dine.
Modenhetsvurdering
I en gratis modenhetsvurdering innen 48 timer kontrollerer en ledende arkitekt prosjektet ditt mot definisjonen av klar (6 punkter) og anbefaler sporet som passer.
Valg av spor
Prosjekter med definert omfang får et bindende forslag innen 3 til 5 virkedager. Prosjekter i konseptfasen starter i Blueprint Studio. Et system i drift som svikter, er udokumentert eller trenger integrasjon, starter med en diagnose på 1 til 2 uker. Blueprint Studio og diagnosen har hver en fastpris som angis i forslaget.