Kortbetalningar
Kortbetalningar: från terminalen till acquirern och tillbaka till huvudboken
EMV-terminaler och betalningsgatewayer kopplade till acquirer över ISO 8583 eller API:er, med avräkningsfiler avstämda i ERP-systemet.
Ritning
Rulla i sidled för att se hela ritningen.
Kortbetalningar: auktoriserade i kassan, avräknade senare, avstämda i ERP
Terminalen eller kassan frågar gatewayen, gatewayen frågar acquirern, och acquirern dirigerar till kortnätverket och kortutgivaren. Avräkningsfiler anländer senare och matchas mot försäljning och avgifter i ERP. En timeout utlöser en återföring så att kunden aldrig debiteras två gånger.
- Primärt flöde
- Asynkront
- Undantagsväg
Flödet i 8 steg
Flödet, steg för steg
- Från EMV-terminal eller onlinekassa till Betalningsgateway: Auktoriseringsbegäran, över EMV · REST/JSON (primärt flöde).
- Från Betalningsgateway till Acquirer: Auktorisering, över ISO 8583 (primärt flöde).
- Från Acquirer till Kortnätverk och utgivare: Dirigerad till utgivaren, över ISO 8583 (primärt flöde).
- Från Acquirer till Betalningsgateway: Godkänd eller avslagen, över ISO 8583 (asynkront).
- Från Acquirer till Integrationslager: Avräknings- och avgiftsfiler, över SFTP (asynkront).
- Från Integrationslager till ERP: Avräknad försäljning, avgifter och utbetalningar, över REST/JSON (primärt flöde).
- Från Betalningsgateway till EMV-terminal eller onlinekassa: Inget svar i tid: automatisk återföring, över ISO 8583 0400 (undantagsväg).
- Från Integrationslager till Team för betalningsdrift: Avräkningsavvikelse eller återkrav (undantagsväg).
Översikt
Det här är vägen för en kortbetalning, från terminalen eller näthandelskassan till acquirern, kortnätverket och kortutgivaren, och tillbaka. Kunden väntar på svaret i kassan. Pengarna, minus avgifter, kommer senare i en avräkningsfil som måste matchas mot försäljningen i ditt ERP-system.
Referensdesignen skickar auktoriseringar genom en betalningsgateway som tokeniserar kortet och dirigerar begäran till acquirern, över ISO 8583 eller acquirerns API. Avräknings- och avgiftsfiler samlas in av integrationslagret, matchas mot den ursprungliga försäljningen och bokförs i ERP-systemet som försäljning, avgifter och utbetalningar.
Designen täcker också det som går fel. En begäran som inte får svar i tid återförs, så att kunden inte debiteras två gånger. En avräkning som inte matchar, eller ett återkrav, går till ditt betalningsoperations team med den ursprungliga försäljningen bifogad.
Så fungerar flödet
Börja i terminalen eller kassan
EMV-terminalen läser chip- eller kontaktlösa kortet, eller näthandelskassan tar emot kortet via en hostad sida, och skickar en auktoriseringsbegäran till gatewayen.
Auktorisera genom gatewayen
Gatewayen ersätter kortnumret med en token och skickar auktoriseringen till acquirern, över ISO 8583 eller acquirerns API.
Dirigera till kortutgivaren
Acquirern dirigerar begäran via kortnätverket till kortutgivaren, som godkänner eller avslår den.
Returnera svaret
Godkännandet eller avslaget kommer tillbaka samma väg till terminalen eller kassan, med sin svarskod.
Ta emot avräkning
Acquirern skickar senare avräknings- och avgiftsfiler, som integrationslagret samlar in och validerar.
Matcha och bokför
Lagret matchar avräknade transaktioner mot den ursprungliga försäljningen och bokför försäljning, avgifter och utbetalningar i ERP-systemet.
När något går fel
Inget svar i tid
Om gatewayen inte får något svar inom acquirerns tidsgräns skickar den en återföring, ett ISO 8583 0400-meddelande eller motsvarande API-anrop, så att kunden aldrig debiteras för en försäljning som inte fullföljdes.
En betalning avslås
Svarskoden når kassan eller näthandelskassan med ett tydligt meddelande. Avslagsfrekvensen övervakas, så att ett hopp som tyder på ett tekniskt fel larmar.
Avräkningen matchar inte
Ett avräknat belopp som avviker från försäljningen, eller en försäljning utan avräkning, hamnar på en granskningslista för ditt betalningsoperations team, med båda posterna sida vid sida.
En kortinnehavare bestrider en betalning
Acquirerns tvisterapport importeras och kopplas till den ursprungliga försäljningen och avräkningen, så att ditt team kan svara med underlaget på ett ställe.
Standarder och system
- Bankstandarder och kanaler
- SFTP (H2H)
- Betalningar
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integration
- REST
- Webhooks
Frågor och svar
Vad är skillnaden mellan en gateway och en acquirer?
Acquirern är banken eller den licensierade institution som hanterar kortbetalningar åt dig och betalar ut pengarna. Gatewayen är den tekniska tjänsten framför som tar emot begäranden från terminaler och kassor, tokeniserar kort och dirigerar dem. Vissa leverantörer är båda. Designen fungerar oavsett och håller de två rollerna åtskilda.
Håller det här kortdata borta från dina system?
Det är syftet med designen. Kortnummer tas emot av den certifierade terminalen eller en hostad betalsida och ersätts av tokens i gatewayen, så att ditt POS-system, ERP-system och dina datalager bara ser tokens. Det minskar den del av din miljö som PCI DSS omfattar. Din granskare bekräftar den slutliga omfattningen.
Är ISO 8583 likadan hos alla acquirer?
Nej. ISO 8583 definierar en struktur, och varje acquirer eller nätverk publicerar sin egen specifikation av fält, meddelandetyper och koder. Därför bygger vi utifrån acquirerns specifikation och kör dennes certifieringstester. Ett gateway-API framför acquirern döljer dessa skillnader, vilket ofta är enklare för detaljhandeln.
Varför kommer avräkningen senare än försäljningen?
Auktoriseringen reserverar bara pengarna. Acquirern avräknar i satser, efter avdrag för sina avgifter och eventuella nätverksavgifter, och betalar ut enligt sitt eget schema. Därför behandlar designen auktorisering och avräkning som separata händelser och matchar dem, så att finansavdelningen ser vad som sålts, vad som avräknats och vad som återstår.
Stöds EMV 3-D Secure för betalningar online?
Ja. För kortbetalningar online integrerar vi EMV 3-D Secure genom gatewayen, så att kortutgivaren kan autentisera kortinnehavaren där regler eller risk kräver det. Vi hanterar både utmaningsflödet och det friktionsfria flödet i kassan och testar båda med leverantörens testkort.
Går det att använda fler än en betalningsleverantör?
Ja. Integrationslagret håller en intern modell av en betalning och mappar den till varje leverantör, så att volymer kan dirigeras per kanal, land eller korttyp eller flyttas mellan leverantörer. Varje leverantör behöver fortfarande sin egen integration och certifiering, som vi planerar leverantör för leverantör.
Börja med ett samtal, inte ett avtal.
Berätta vad du behöver bygga, koppla samman eller skydda. En arkitekt går igenom det med dig och rekommenderar sedan var du ska börja.
Vad som händer härnäst
Vi enas om en tid
Vårt team mejlar dig för att enas om en tid för samtalet.
Förberedande samtal
En kostnadsfri förkonsultation online i 30 minuter: vi går igenom dina mål, system och begränsningar.
Mognadsgenomgång
I en kostnadsfri mognadsgenomgång på 48 timmar prövar en ledande arkitekt ditt projekt mot de sex kriterierna för Definition of Ready och rekommenderar det spår som passar.
Val av spår
Projekt med tydlig omfattning får ett bindande förslag inom 3 till 5 arbetsdagar. Projekt i konceptfasen börjar i Blueprint Studio. Ett system i drift som fallerar, är odokumenterat eller behöver integreras börjar med en diagnostik på 1 till 2 veckor. Blueprint Studio och diagnostiken har var sitt fasta pris som anges i förslaget.