Betalinger, agentisk handel (AP2) og POS
Kortbetalinger, agentisk kasse og butikker koblet sammen fra terminal til hovedbok
Når butikker, kasser og hovedboken ikke stemmer overens
En kortbetaling berører flere systemer i løpet av noen sekunder: terminalen eller kassen, en betalingsgateway, innløseren, kortordningen og utstederen. Pengene og gebyrene kommer senere i oppgjørsfiler som noen må avstemme mot salget i ERP-systemet.
Når butikker, nettkasser og ERP-systemet synkroniseres i satsvise kjøringer om natten, selges det for mye lager under kampanjer, og oppgjørsavvik hoper seg opp på tvers av innløsere. Kassen går tregere i de travleste periodene. Nå begynner også KI-agenter å handle på vegne av kundene.
Det som endres for deg
Én oversikt over lager og salg
Salg, returer, priser og lager i takt på tvers av alle butikker, nettbutikker og ERP-systemet, i sanntid i stedet for over natten.
Oppgjør som stemmer overens
Oppgjørs- og gebyrfiler fra alle innløsere avstemmes automatisk mot salget, og avvik listes opp for teamet ditt.
Klar for agentisk handel
En kasse som kan ta imot betalinger fra KI-agenter, med en verifiserbar oversikt over hva kunden godkjente.
Det vi leverer
Tilkobling til betalingsgateway, innløser og kortnettverk
Flyter for autorisasjon, trekk, tilbakebetaling og tilbakeføring over ISO 8583, ISO 20022 eller leverandørens API, med orkestrering på tvers av flere innløsere og håndtering av alle svarkoder.
AP2 og kasse med kryptografiske fullmakter
AP2 er en åpen protokoll som lar en KI-agent betale på vegne av en kunde. Kryptografisk signerte fullmakter registrerer hva kunden godkjente, og vi integrerer dem i kassen din.
EMV- og SoftPOS-terminaler
EMV-brikke- og berøringsfrie terminaler, og SoftPOS, som tar imot berøringsfrie kort på en vanlig telefon eller nettbrett, koblet til POS- eller kioskprogramvaren din.
Automatisk behandling av oppgjørsfiler
Oppgjørs- og gebyrfiler fra innløsere samles inn, valideres, revideres og gjøres om til posteringer som ERP-systemet kan avstemme.
Sanntidssynkronisering fra POS til ERP
Salg, returer, priser, kampanjer og lagernivåer synkroniseres mellom alle butikker og ERP-systemet gjennom et hendelsesdrevet strømmelag.
Tokenisering og PCI DSS-omfang
Kortnumre erstattes med tokens og holdes utenfor POS-systemet og ERP-systemet, med en skriftlig oversikt over hvilke systemer som fortsatt er innenfor PCI DSS-omfanget.
Sertifisering og utrulling
Testskript og revisjonsbevis for hver leverandørs sertifisering, en pilot i noen få butikker, deretter utrulling butikk for butikk med sammenligning av daglige totaler.
Slik arbeider vi
Følg ett salg
Vi følger ett salg fra kassen eller nettkassen til hovedboken sammen med økonomi-, butikk- og IT-teamene dine, og blir enige om omfanget.
Design integrasjonen
Vi velger protokoller, tilnærming til tokenisering og meldingsflyter, og skriver grensesnittspesifikasjonen.
Bygging og testing
Vi bygger betalings-, oppgjørs- og POS-flytene med automatiserte tester, inkludert avvisninger, tidsavbrudd og tilbakebetalinger.
Sertifiser hos leverandøren
Vi kjører leverandørens testtilfeller i testmiljøet og retter det sertifiseringen avdekker.
Pilot, deretter utrulling
Vi går først i drift i noen få butikker eller kanaler, sammenligner totalene daglig og ruller deretter ut butikk for butikk.
Overvåk og støtt
Vi overvåker godkjenningsrater, oppgjørsfiler og posteringer i butikk, og håndterer leverandørendringer når de kunngjøres.
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).
Rull sidelengs for å se hele tegningen.
POS til ERP: hvert salg posteres én gang
Salgsflyten fra kassene til ERP som hendelser, og priser og lager flyter tilbake. En butikk som går offline, fortsetter å selge og tar igjen det tapte. En postering som feiler, forsøkes på nytt og overleveres deretter til en person.
- Hovedforløp
- Asynkron
- Unntaksbane
Forløpet i 8 steg
Forløpet, steg for steg
- Fra POS-terminaler til Butikk- eller POS-skyserver: Salg, returer og annulleringer (hovedforløp).
- Fra Butikk- eller POS-skyserver til Integreringslag: Salgshendelser og dagssluttotaler, gjennom en hendelseskø, over REST/JSON (asynkron).
- Fra Integreringslag til ERP: Salgs- og lagerbevegelser postert, over OData · REST/JSON (hovedforløp).
- Fra ERP til Integreringslag: Priser, kampanjer og varedata, via API eller fileksport, over REST/JSON (hovedforløp).
- Fra Integreringslag til Butikk- eller POS-skyserver: Pris- og lageroppdateringer, over REST/JSON (hovedforløp).
- Fra Integreringslag til Kø for nye forsøk: Postering feilet (unntaksbane).
- Fra Kø for nye forsøk til Integreringslag: Forsøkt på nytt (unntaksbane).
- Fra Kø for nye forsøk til Butikkdriftsteam: Feiler fortsatt: varsel med detaljene (unntaksbane).
Standarder og protokoller
Å navngi et produkt eller en leverandør betyr ikke partnerskap med det.
- Språk
- Go
- Rammeverk
- Node.js
- Data og analyse
- Apache Kafka
- Databaser
- Redis
- DevOps og observerbarhet
- Kubernetes
- Bankstandarder og bankkanaler
- ISO 20022
- Betalinger
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
Bevist i produksjon
For en flermerkegruppe innen GCC-detaljhandel og kjøpesentre erstattet vi nattlige satsvise skript med sanntidssynkronisering fra POS til ERP. Vi samlet også betalinger fra flere innløsere med automatisert oppgjør, og bygde en tjeneste for lagerreservasjon til topper under flash-salg.
Slik starter du
Tydelige krav til leverandør og butikk går rett til et forslag. En ny betalingsplattform, eller en agentisk kasse, starter vanligvis i Blueprint Studio.
Hva skjer videre
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.
Leveranse i fem trinn
Mobilisering, sprinter med livedemoer, integrasjon og herding, godkjenning og idriftsettelse, deretter forvaltede tjenester. Etter idriftsettelsen kommer en garantiperiode, deretter valgfri støtte og vedlikehold.
KI-innfødte produkteam
Forvaltede, tverrfaglige team av erfarne ingeniører, utstyrt med agentiske rammeverk for koding og kvalitetssikring.
Prosjekter med fast resultat og forvaltede tjenester døgnet rundt
Leveranse med fast omfang og milepæler, med navngitte leveranseledere, og forvaltede applikasjonstjenester døgnet rundt under SLA-styring.
Spørsmål og svar
Arbeider dere direkte med ISO 8583?
Ja, der innløseren eller prosessoren tilbyr det. ISO 8583 er et rammeverk snarere enn ett format: hver innløser publiserer sin egen spesifikasjon av felt og meldingstyper. Vi bygger fra den spesifikasjonen, håndterer autorisasjoner, tilbakeføringer og advis-meldinger, og tester hver svarkode.
Hva er AP2, og trenger vi det nå?
Agent Payments Protocol (AP2) er en åpen protokoll for betalinger utført av KI-agenter. Hvert kjøp har signerte mandater som viser hva kunden autoriserte, slik at forhandlere, utstedere og innløsere kan stole på og revidere det. Hvis KI-agenter sannsynligvis vil handle hos deg, kan vi gjøre kassen din AP2-klar sammen med dagens flyter.
Hvordan reduserer dere omfanget av vår PCI DSS?
Vi kan ikke fjerne PCI DSS, men vi kan redusere hvor mye av virksomheten den gjelder for. Hostede betalingssider, punkt-til-punkt-kryptering i terminalen og gateway-tokener holder kortnumre ute av POS, ERP og datavarehus. Vi dokumenterer dataflytene for den som vurderer etterlevelsen.
Kan vi ta imot kort på telefoner i stedet for terminaler?
Ja, med SoftPOS. Kontaktløse kort og lommebøker tas imot på en støttet telefon eller nettbrett gjennom en sertifisert betalingsapp fra innløseren eller leverandøren din. Vi integrerer den appen med POS-, salgs- og oppgjørsflytene dine som enhver annen terminal.
Hva skjer når en butikk mister forbindelsen?
Butikken fortsetter å selge. Salg lagres lokalt og sendes til ERP når forbindelsen er tilbake, hvert med en unik identifikator slik at ingenting posteres to ganger. Om kortbetalinger kan fortsette offline avhenger av innløserens regler og risikoviljen din, og det designer vi sammen med deg.
Håndterer dere tilbakebetalinger og tilbakeføringer (chargeback)?
Ja. Tilbakebetalinger og tilbakeføringer er en del av betalingsflytene vi bygger. For tilbakeføringer (chargeback) importerer vi innløserens tvistrapporter og kobler hver enkelt til det opprinnelige salget og oppgjøret. Teamet ditt får en liste å arbeide gjennom, med dokumentasjonen vedlagt.
Klar til å bygge? Be om forslag.
Send kravene dine eller en anmodning om forslag (RFP). Arkitektene våre validerer dem og returnerer et bindende forslag med fast omfang.
Hva skjer videre
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.
Bindende forslag
Etter arkitekturvalidering uten kostnad mottar du et bindende forslag med fast omfang innen 3 til 5 virkedager: milepæler, arkitektur, teamstruktur og SLA-er. Vi signerer en konfidensialitetsavtale (NDA) med deg på forespørsel, før du deler kravene dine.
Mobilisering
Når du har signert, starter utviklingsteamene våre sprint 0 innen 5 til 10 virkedager etter kontraktsignering.
Leveranse i fem trinn
Mobilisering, sprinter med livedemoer, integrasjon og herding, godkjenning og idriftsettelse, deretter forvaltede tjenester. Etter idriftsettelsen kommer en garantiperiode, deretter valgfri støtte og vedlikehold.