Gå til indhold
XSIS
KundeområdeAnmod om et forslag
Et kort bruges på en betalingsterminal

Virksomheder og integrationer

Betalinger, agentisk handel (AP2) og POS

Kortbetalinger, agentisk checkout og butikker forbundet fra terminal til hovedbog

Anmod om et forslagBook en gratis session

Når butikker, checkout og hovedbogen ikke stemmer overens

En kortbetaling berører flere systemer på få sekunder: terminalen eller checkout, en gateway, indløseren, kortordningen og udstederen. Pengene og gebyrerne kommer senere i afregningsfiler, som nogen skal afstemme med salget i dit ERP-system.

Når butikker, onlinebutikker og ERP-systemet synkroniseres i batches om natten, bliver varer oversolgt under kampagner, og afregningsdifferencer hober sig op på tværs af indløsere. Checkout bliver langsommere på de travleste tidspunkter. Nu begynder AI-agenter også at købe ind på kundernes vegne.

Det ændrer sig for dig

  1. Ét overblik over lager og salg

    Salg, returneringer, priser og lager i takt på tværs af alle butikker, webbutikker og ERP-systemet, i realtid i stedet for natten over.

  2. Afregninger, der stemmer

    Afregnings- og gebyrfiler fra hver indløser afstemmes automatisk med salget, og differencerne listes op for dit team.

  3. Klar til agentisk handel

    En checkout, der kan modtage betalinger fra AI-agenter, med en verificerbar registrering af, hvad kunden har godkendt.

Det leverer vi

  • Forbindelse til gateway, indløser og kortnetværk

    Flows for autorisering, hævning, tilbagebetaling og tilbageførsel over ISO 8583, ISO 20022 eller udbyderens API, med orkestrering på tværs af flere indløsere og håndtering af hver svarkode.

  • AP2 og checkout med kryptografiske mandater

    AP2 er en åben protokol, der lader en AI-agent betale på en kundes vegne. Kryptografisk signerede mandater registrerer, hvad kunden har godkendt, og vi integrerer dem i din checkout.

  • EMV- og SoftPOS-terminaler

    EMV-chip- og kontaktløse terminaler samt SoftPOS, som modtager kontaktløse kort på en almindelig telefon eller tablet, forbundet med din POS- eller kiosksoftware.

  • Automatiseret behandling af afregningsfiler

    Indløsernes afregnings- og gebyrfiler indsamles, valideres, revideres og omdannes til posteringer, som dit ERP-system kan afstemme.

  • POS-til-ERP-synkronisering i realtid

    Salg, returneringer, priser, kampagner og lagerbeholdninger synkroniseres mellem alle butikker og ERP-systemet via et lag til hændelsesstreaming.

  • Tokenisering og PCI DSS-omfang

    Kortnumre erstattes med tokens og holdes ude af dit POS- og ERP-system, med en skriftlig oversigt over, hvilke systemer der fortsat er omfattet af PCI DSS.

  • Certificering og udrulning

    Testscripts og dokumentation til hver udbyders certificering, en pilot i nogle få butikker og derefter udrulning butik for butik, hvor de daglige totaler sammenlignes.

Sådan arbejder vi

  1. Følg et salg

    Vi følger et salg fra kassen eller checkout til hovedbogen sammen med dine økonomi-, butiks- og IT-teams og aftaler omfanget.

  2. Design integrationen

    Vi vælger protokollerne, tilgangen til tokenisering og beskedflowene og skriver interfacespecifikationen.

  3. Byg og test

    Vi bygger betalings-, afregnings- og POS-flowene med automatiserede tests, herunder afvisninger, timeouts og tilbagebetalinger.

  4. Certificer hos udbyderen

    Vi kører udbyderens testcases i udbyderens testmiljø og retter det, certificeringen finder.

  5. Pilot og derefter udrulning

    Vi idriftsætter først i nogle få butikker eller kanaler, sammenligner totaler dagligt og udruller derefter butik for butik.

  6. Overvågning og support

    Vi holder øje med godkendelsesrater, afregningsfiler og butikkernes posteringer og håndterer ændringer hos udbydere, efterhånden som de annonceres.

Kortbetalinger: autoriseret i kassen, afregnet senere, afstemt i ERP-systemetTerminalen 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.POSEMV-terminal elleronlinekasseChip, kontaktløs oge-handelGatewayBetalingsgatewayTokenisering ogvideresendelseBankIndløserAutorisering ogafregningTredjepartKortordning ogudstederGodkender ellerafviserERPERPSalg, gebyrer ogudbetalingerXSISIntegrationslagFortolkning ogafstemning afafregningerMenneskerBetalingsdriftsteamAfvigelser, tvister ogchargebacks1EMV · REST/JSON2ISO 85833ISO 85834ISO 85835SFTP6REST/JSON7ISO 8583 04008

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

  1. Fra EMV-terminal eller onlinekasse til Betalingsgateway: Autoriseringsanmodning, over EMV · REST/JSON (primært flow).
  2. Fra Betalingsgateway til Indløser: Autorisering, over ISO 8583 (primært flow).
  3. Fra Indløser til Kortordning og udsteder: Sendt videre til udstederen, over ISO 8583 (primært flow).
  4. Fra Indløser til Betalingsgateway: Godkendt eller afvist, over ISO 8583 (asynkron).
  5. Fra Indløser til Integrationslag: Afregnings- og gebyrfiler, over SFTP (asynkron).
  6. Fra Integrationslag til ERP: Afregnet salg, gebyrer og udbetalinger, over REST/JSON (primært flow).
  7. Fra Betalingsgateway til EMV-terminal eller onlinekasse: Intet svar i tide: automatisk tilbageførsel, over ISO 8583 0400 (undtagelsessti).
  8. Fra Integrationslag til Betalingsdriftsteam: Afvigelse i afregning eller chargeback (undtagelsessti).
POS til ERP: hvert salg bogført én gangSalget går fra kasserne til ERP-systemet som hændelser, og priser og lager går tilbage. En butik, der går offline, bliver ved med at sælge og indhenter bagefter. En bogføring, der fejler, forsøges igen og gives derefter til en person.POSPOS-terminalerHver kasse i hverbutikDatalagerButiks- ellerPOS-cloudserverSælger videre, mensden er offlineXSISIntegrationslagHændelseskø,mapping, beskyttelsemod dubletterERPERPSalg, lager ogøkonomiServiceKø til gentagneforsøgGentagne forsøg medstigende ventetid,derefter endead-letter-køMenneskerButiksdriftsteam12REST/JSON3OData · REST/JSON4REST/JSON5REST/JSON678

POS til ERP: hvert salg bogført én gang

Salget går fra kasserne til ERP-systemet som hændelser, og priser og lager går tilbage. En butik, der går offline, bliver ved med at sælge og indhenter bagefter. En bogføring, der fejler, forsøges igen og gives derefter til en person.

  • Primært flow
  • Asynkron
  • Undtagelsessti
Forløbet i 8 trin

Forløbet, trin for trin

  1. Fra POS-terminaler til Butiks- eller POS-cloudserver: Salg, returneringer og annulleringer (primært flow).
  2. Fra Butiks- eller POS-cloudserver til Integrationslag: Salgshændelser og dagens totaler, gennem en hændelseskø, over REST/JSON (asynkron).
  3. Fra Integrationslag til ERP: Salg og lagerbevægelser bogført, over OData · REST/JSON (primært flow).
  4. Fra ERP til Integrationslag: Priser, kampagner og varedata, via API eller fileksport, over REST/JSON (primært flow).
  5. Fra Integrationslag til Butiks- eller POS-cloudserver: Pris- og lageropdateringer, over REST/JSON (primært flow).
  6. Fra Integrationslag til Kø til gentagne forsøg: Bogføring mislykkedes (undtagelsessti).
  7. Fra Kø til gentagne forsøg til Integrationslag: Forsøgt igen (undtagelsessti).
  8. Fra Kø til gentagne forsøg til Butiksdriftsteam: Fejler stadig: alarm med detaljerne (undtagelsessti).

Standarder og protokoller

At nævne et produkt eller en udbyder betyder ikke, at vi er partner med det.

Sprog
  • Go
Frameworks
  • Node.js
Data og analyser
  • Apache Kafka
Databaser
  • Redis
DevOps og observerbarhed
  • Kubernetes
Bankstandarder og bankkanaler
  • ISO 20022
Betalinger
  • ISO 8583
  • EMV
  • EMV 3-D Secure
  • PCI DSS

Dokumenteret i produktionen

For en GCC-koncern inden for detailhandel og indkøbscentre med flere brands erstattede vi natlige batchscripts med POS-til-ERP-synkronisering i realtid. Vi samlede også betalinger fra flere indløsere med automatiseret afregning og byggede en service til lagerreservation til spidsbelastninger under flashsalg.

Sådan begynder du

Klare krav til udbydere og butikker går direkte til et forslag. En ny betalingsplatform eller en agentisk checkout starter som regel i Blueprint Studio.

Det sker der nu

  1. Forhåndskonsultation

    En gratis online forhåndskonsultation på 30 minutter: vi gennemgår dine mål, systemer og begrænsninger.

  2. 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.

  3. 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.

  4. Levering i fem faser

    Mobilisering, sprints med demonstrationer, integration og hærdning, accept og idriftsættelse samt derefter administrerede tjenester. Efter idriftsættelsen følger en garantiperiode, derefter valgfri support og vedligeholdelse.

Spørgsmål og svar

Arbejder I direkte med ISO 8583?

Ja, hvor indløseren eller processoren tilbyder det. ISO 8583 er en ramme snarere end ét format: hver indløser udgiver sin egen specifikation af felter og meddelelsestyper. Vi bygger ud fra den specifikation, håndterer autorisationer, tilbageførsler og advice-meddelelser og tester hver svarkode.

Link til dette spørgsmål

Hvad er AP2, og har vi brug for det nu?

Agent Payments Protocol (AP2) er en åben protokol for betalinger foretaget af AI-agenter. Hvert køb har signerede mandater, der viser, hvad kunden har godkendt, så forretninger, udstedere og indløsere kan stole på købet og revidere det. Hvis AI-agenter sandsynligvis vil handle hos dig, kan vi gøre din checkout AP2-klar ved siden af dine nuværende flows.

Link til dette spørgsmål

Hvordan reducerer I vores PCI DSS-omfang?

Vi kan ikke fjerne PCI DSS, men vi kan reducere, hvor stor en del af dit IT-landskab det gælder for. Hostede betalingssider, punkt-til-punkt-kryptering ved terminalen og gateway-tokens holder kortnumre ude af dit POS-system, ERP-system og datavarehus. Vi dokumenterer dataflowene for din assessor.

Link til dette spørgsmål

Kan vi acceptere kort på telefoner i stedet for terminaler?

Ja, med SoftPOS. Kontaktløse kort og digitale tegnebøger modtages på en understøttet telefon eller tablet via en certificeret betalingsapp fra din indløser eller udbyder. Vi integrerer appen med dine POS-, salgs- og afregningsflows som enhver anden terminal.

Link til dette spørgsmål

Hvad sker der, når en butik mister forbindelsen?

Butikken bliver ved med at sælge. Salg gemmes lokalt og sendes til ERP-systemet, når forbindelsen er tilbage, hvert med en unik identifikator, så intet bogføres to gange. Om kortbetalinger kan fortsætte offline, afhænger af din indløsers regler og din risikovillighed, og det designer vi sammen med dig.

Link til dette spørgsmål

Håndterer I tilbagebetalinger og chargebacks?

Ja. Tilbagebetalinger og tilbageførsler er en del af de betalingsflows, vi bygger. Ved chargebacks importerer vi indløserens tvistrapporter og knytter hver enkelt til det oprindelige salg og den oprindelige afregning. Dit team får en liste at arbejde sig igennem, med dokumentationen vedhæftet.

Link til dette spørgsmål

Klar til at bygge? Bed om et forslag.

Send dine krav eller din RFP. Vores arkitekter validerer dem og sender et bindende forslag med fast omfang retur.

Anmod om et forslagBook en gratis session

Det sker der nu

  1. 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.

  2. Bindende forslag

    Efter arkitekturvalidering uden omkostninger modtager du et bindende forslag med fast omfang inden for 3 til 5 hverdage: milepæle, arkitektur, teamstruktur og SLA’er. Vi underskriver efter anmodning en fortrolighedsaftale (NDA) med dig, før du deler dine krav.

  3. Mobilisering

    Når du har underskrevet, begynder vores ingeniørteams på sprint 0 inden for 5 til 10 hverdage efter kontraktunderskrivelse.

  4. Levering i fem faser

    Mobilisering, sprints med demonstrationer, integration og hærdning, accept og idriftsættelse samt derefter administrerede tjenester. Efter idriftsættelsen følger en garantiperiode, derefter valgfri support og vedligeholdelse.