
Fizetések, ágens alapú kereskedelem (AP2) és POS
Kártyás fizetések, ágens alapú fizetés és üzletek összekötve a termináltól a főkönyvig
Amikor az üzletek, a pénztárak és a főkönyv mást mutat
Egy kártyás fizetés néhány másodperc alatt több rendszert érint: a terminált vagy a pénztárat, egy átjárót, a kártyaelfogadó bankot, a kártyarendszert és a kibocsátót. A pénz és a díjak később, elszámolási fájlokban érkeznek meg, amelyeket valakinek az ERP-ben rögzített eladásokhoz kell párosítania.
Ha az üzletek, az online pénztárak és az ERP éjszakai kötegekben szinkronizálnak, akciók idején túlértékesítik a készletet, és a kártyaelfogadó bankok elszámolási eltérései felhalmozódnak. A legforgalmasabb pillanatokban lelassul a fizetés. Ráadásul az MI-ágensek is elkezdtek vásárolni az ügyfelek nevében.
Mi változik Önnél
Egységes kép a készletről és az eladásokról
Az eladások, a visszáruk, az árak és a készlet összhangban minden üzletben, webáruházban és az ERP-ben, valós időben, nem éjszakánként.
Egyező elszámolások
Minden kártyaelfogadó bank elszámolási és díjfájljait automatikusan párosítjuk az eladásokhoz, az eltéréseket pedig listában kapja meg a csapata.
Készen az ágens alapú kereskedelemre
Olyan pénztár, amely MI-ágensektől is fogad fizetést, ellenőrizhető nyilvántartással arról, mit engedélyezett az ügyfél.
Mit nyújtunk
Kapcsolat átjárókkal, kártyaelfogadó bankokkal és kártyahálózatokkal
Engedélyezési, rögzítési, visszatérítési és sztornófolyamatok ISO 8583-on, ISO 20022-n vagy a szolgáltató API-ján, több kártyaelfogadó bank vezénylésével és minden válaszkód kezelésével.
AP2 és kriptográfiai felhatalmazáson alapuló fizetés
Az AP2 nyílt protokoll, amellyel egy MI-ágens az ügyfél nevében fizethet. A kriptográfiailag aláírt felhatalmazások rögzítik, mit hagyott jóvá az ügyfél, és ezeket beépítjük az Ön pénztárába.
EMV- és SoftPOS-terminálok
Chipes és érintéses EMV-terminálok, valamint SoftPOS, amely egy átlagos telefonon vagy táblagépen fogad érintéses kártyákat, a POS- vagy kioszkszoftveréhez kapcsolva.
Az elszámolási fájlok automatikus feldolgozása
A kártyaelfogadó bankok elszámolási és díjfájljait begyűjtjük, érvényesítjük, auditáljuk, és az ERP által párosítható könyvelési tételekké alakítjuk.
Valós idejű POS- és ERP-szinkron
Az eladások, a visszáruk, az árak, az akciók és a készletszintek szinkronizálása minden üzlet és az ERP között, eseménytovábbító rétegen keresztül.
Tokenizálás és PCI DSS-hatókör
A kártyaszámokat tokenekre cseréljük, és kívül tartjuk a POS- és ERP-rendszeren, írásos áttekintéssel arról, mely rendszerek maradnak a PCI DSS hatálya alatt.
Tanúsítás és bevezetés
Tesztforgatókönyvek és bizonyítékok minden szolgáltató tanúsításához, próbaüzem néhány üzletben, majd üzletenkénti bevezetés a napi összesítők összevetésével.
Hogyan dolgozunk
Egy eladás végigkövetése
Pénzügyi, bolti és IT-csapataival együtt végigkövetünk egy eladást a kasszától vagy a pénztártól a főkönyvig, és megállapodunk a hatókörben.
Az integráció tervezése
Kiválasztjuk a protokollokat, a tokenizálás módját és az üzenetfolyamokat, és megírjuk az interfészspecifikációt.
Építés és tesztelés
Megépítjük a fizetési, elszámolási és POS-folyamatokat automatizált tesztekkel, az elutasításokat, az időtúllépéseket és a visszatérítéseket is beleértve.
Tanúsítás a szolgáltatóval
Lefuttatjuk a szolgáltató teszteseteit a tesztkörnyezetében, és kijavítjuk, amit a tanúsítás feltár.
Próbaüzem, majd bevezetés
Először néhány üzletben vagy csatornán élesítünk, naponta összevetjük az összesítőket, majd üzletről üzletre bevezetjük.
Monitorozás és támogatás
Figyeljük a jóváhagyási arányokat, az elszámolási fájlokat és a bolti könyveléseket, és a bejelentésükkor kezeljük a szolgáltatók változásait.
Görgessen oldalra az egész rajz megtekintéséhez.
Kártyás fizetések: engedélyezés a kasszánál, elszámolás később, egyeztetés az ERP-ben
A terminál vagy a webes pénztár az átjárótól kér engedélyt, az átjáró a kártyaelfogadótól, a kártyaelfogadó pedig a kártyarendszerhez és a kibocsátóhoz továbbítja a kérést. Az elszámolási fájlok később érkeznek, és az ERP-ben az értékesítésekhez és a díjakhoz párosítjuk őket. Időtúllépéskor sztornó indul, így az ügyfelet soha nem terhelik meg kétszer.
- Elsődleges folyamat
- Aszinkron
- Kivételi útvonal
A folyamat 8 lépésben
A folyamat lépésről lépésre
- Forrás: EMV-terminál vagy webes pénztár, cél: Fizetési átjáró. Engedélyezési kérelem, EMV · REST/JSON protokollon keresztül (elsődleges folyamat).
- Forrás: Fizetési átjáró, cél: Kártyaelfogadó. Engedélyezés, ISO 8583 protokollon keresztül (elsődleges folyamat).
- Forrás: Kártyaelfogadó, cél: Kártyarendszer és kibocsátó. Irányítva a kibocsátóhoz, ISO 8583 protokollon keresztül (elsődleges folyamat).
- Forrás: Kártyaelfogadó, cél: Fizetési átjáró. Jóváhagyva vagy elutasítva, ISO 8583 protokollon keresztül (aszinkron).
- Forrás: Kártyaelfogadó, cél: Integrációs réteg. Elszámolási és díjfájlok, SFTP protokollon keresztül (aszinkron).
- Forrás: Integrációs réteg, cél: ERP. Elszámolt értékesítés, díjak és kifizetések, REST/JSON protokollon keresztül (elsődleges folyamat).
- Forrás: Fizetési átjáró, cél: EMV-terminál vagy webes pénztár. Nincs válasz időben: automatikus sztornó, ISO 8583 0400 protokollon keresztül (kivételi útvonal).
- Forrás: Integrációs réteg, cél: Fizetési üzemeltetési csapat. Elszámolási eltérés vagy visszaterhelés (kivételi útvonal).
Görgessen oldalra az egész rajz megtekintéséhez.
POS és ERP: minden értékesítés egyszer könyvelve
Az értékesítési adatok eseményként jutnak el a kasszáktól az ERP-be, az árak és a készlet pedig visszafelé. Az offline üzlet tovább árusít, és később pótolja a lemaradást. A sikertelen könyvelést a rendszer újrapróbálja, majd egy munkatárs kezébe adja.
- Elsődleges folyamat
- Aszinkron
- Kivételi útvonal
A folyamat 8 lépésben
A folyamat lépésről lépésre
- Forrás: POS-terminálok, cél: Bolti szerver vagy POS-felhőszerver. Értékesítés, visszaküldések és sztornók (elsődleges folyamat).
- Forrás: Bolti szerver vagy POS-felhőszerver, cél: Integrációs réteg. Értékesítési események és napi záróösszegek eseménysoron keresztül, REST/JSON protokollon keresztül (aszinkron).
- Forrás: Integrációs réteg, cél: ERP. Értékesítés és készletmozgások könyvelve, OData · REST/JSON protokollon keresztül (elsődleges folyamat).
- Forrás: ERP, cél: Integrációs réteg. Árak, akciók és cikktörzsadatok API-n vagy fájlexporttal, REST/JSON protokollon keresztül (elsődleges folyamat).
- Forrás: Integrációs réteg, cél: Bolti szerver vagy POS-felhőszerver. Ár- és készletfrissítések, REST/JSON protokollon keresztül (elsődleges folyamat).
- Forrás: Integrációs réteg, cél: Újrapróbálkozási sor. A könyvelés sikertelen (kivételi útvonal).
- Forrás: Újrapróbálkozási sor, cél: Integrációs réteg. Újrapróbálva (kivételi útvonal).
- Forrás: Újrapróbálkozási sor, cél: Bolti üzemeltetési csapat. Még mindig sikertelen: riasztás a részletekkel (kivételi útvonal).
Szabványok és protokollok
Egy termék vagy szolgáltató megnevezése nem jelent partnerséget vele.
- Nyelvek
- Go
- Keretrendszerek
- Node.js
- Adat és analitika
- Apache Kafka
- Adatbázisok
- Redis
- DevOps és megfigyelhetőség
- Kubernetes
- Banki szabványok és csatornák
- ISO 20022
- Fizetések
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
Bizonyíték éles üzemből
Egy többmárkás GCC-beli kiskereskedelmi és bevásárlóközpont-csoportnál az éjszakai kötegelt szkripteket valós idejű POS- és ERP-szinkronra cseréltük. Emellett automatizált elszámolással egységesítettük a több kártyaelfogadó bankon futó fizetéseket, és készletfoglalási szolgáltatást építettünk a villámakciók csúcsterhelésére.
Hogyan kezdje
A világos szolgáltatói és bolti követelmények egyenesen ajánlathoz vezetnek. Egy új fizetési platform vagy egy ágens alapú pénztár általában a Blueprint Studióban indul.
Mi történik ezután
Előzetes konzultáció
Egy ingyenes 30 perces online előzetes konzultáció: áttekintjük a céljait, rendszereit és korlátait.
Felkészültségi értékelés
Egy ingyenes 48 órás felkészültségi értékelés során egyik vezető architektünk a hatpontos készenléti definíció (Definition of Ready) alapján megvizsgálja a projektjét, és javasolja a hozzá illő utat.
Az út kiválasztása
A kész hatókörű projektek 3 és 5 munkanapon belül kötelező érvényű ajánlatot kapnak. A koncepciószakaszban lévő projektek a Blueprint Studióban indulnak. A hibás, dokumentálatlan vagy integrációra szoruló éles rendszer diagnosztikával indul (időtartam: 1 és 2 hét között). A Blueprint Studiónak és a diagnosztikának egyaránt fix díja van, amelyet az ajánlat tartalmaz.
Megvalósítás öt szakaszban
Mobilizálás, sprintek élő bemutatókkal, integráció és megerősítés, átvétel és élesítés, majd menedzselt szolgáltatások. Az élesítés után következik: garanciaidőszak, majd opcionális támogatás és karbantartás.
MI-natív termékcsapatok
Menedzselt, több funkciót lefedő szenior mérnöki podok, ágens alapú kódolási és QA-keretrendszerekkel felszerelve.
Fix kimenetelű projektek és éjjel-nappal működő menedzselt szolgáltatások
Rögzített hatókörű, mérföldkövekre épülő megvalósítás megnevezett megvalósítási vezetőkkel, valamint éjjel-nappal működő alkalmazás-üzemeltetési szolgáltatások SLA-alapú irányítással.
Kérdések és válaszok
Közvetlenül is dolgoznak ISO 8583-mal?
Igen, ahol a kártyaelfogadó bank vagy a feldolgozó ezt kínálja. Az ISO 8583 inkább keretrendszer, mint egyetlen formátum: minden kártyaelfogadó bank saját specifikációt ad ki a mezőkről és az üzenettípusokról. Ez alapján építünk, kezeljük az engedélyezési, sztornó- és értesítő (advice) üzeneteket, és minden válaszkódot tesztelünk.
Mi az AP2, és szükségünk van rá már most?
Az Agent Payments Protocol (AP2) nyílt protokoll az MI-ágensek által indított fizetésekhez. Minden vásárlás aláírt felhatalmazásokat hordoz arról, mit engedélyezett az ügyfél, így a kereskedők, a kibocsátók és a kártyaelfogadó bankok megbízhatnak benne és auditálhatják. Ha várhatóan MI-ágensek is vásárolnak Önnél, a jelenlegi folyamatai mellett AP2-képessé tehetjük a pénztárát.
Hogyan csökkentik a PCI DSS-hatókörünket?
A PCI DSS-t nem tudjuk megszüntetni, de szűkíthetjük, hogy rendszerei mekkora részére vonatkozik. A hosztolt fizetési oldalak, a terminálon alkalmazott ponttól pontig titkosítás és az átjáró tokenjei kívül tartják a kártyaszámokat a POS-, az ERP- és az adattárház-rendszeren. Az adatfolyamokat az Ön auditora számára dokumentáljuk.
Fogadhatunk kártyát telefonon, terminál helyett?
Igen, SoftPOS-szal. Az érintéses kártyákat és digitális tárcákat támogatott telefonon vagy táblagépen fogadhatja, a kártyaelfogadó bankja vagy szolgáltatója tanúsított fizetési alkalmazásával. Ezt az alkalmazást ugyanúgy integráljuk a POS-, értékesítési és elszámolási folyamataival, mint bármely más terminált.
Mi történik, ha egy üzlet elveszíti a kapcsolatát?
Az üzlet tovább árusít. Az eladásokat helyben tároljuk, és a kapcsolat helyreálltakor elküldjük az ERP-be, mindegyiket egyedi azonosítóval, így semmit sem könyvelünk kétszer. Hogy a kártyás fizetés offline is folytatódhat-e, az a kártyaelfogadó bank szabályaitól és az Ön kockázatvállalási hajlandóságától függ, és ezt Önnel együtt tervezzük meg.
Kezelik a visszatérítéseket és a visszaterheléseket?
Igen. A visszatérítések és a sztornók az általunk épített fizetési folyamatok részei. A visszaterheléseknél importáljuk a kártyaelfogadó bank vitajelentéseit, és mindegyiket az eredeti eladáshoz és elszámoláshoz kapcsoljuk. Csapata feldolgozandó listát kap, a bizonyítékokkal együtt.
Készen áll az építésre? Kérjen ajánlatot.
Küldje el követelményeit vagy ajánlatkérését (RFP). Architektjeink ellenőrzik őket, és kötelező érvényű, rögzített hatókörű ajánlatot küldenek.
Mi történik ezután
Felkészültségi értékelés
Egy ingyenes 48 órás felkészültségi értékelés során egyik vezető architektünk a hatpontos készenléti definíció (Definition of Ready) alapján megvizsgálja a projektjét, és javasolja a hozzá illő utat.
Kötelező érvényű ajánlat
Az ingyenes architektúra-validálás után 3 és 5 munkanapon belül kötelező érvényű, rögzített hatókörű ajánlatot kap: mérföldkövekkel, architektúrával, csapatszerkezettel és SLA-kkal. Kérésre titoktartási megállapodást (NDA) írunk alá Önnel, mielőtt megosztaná a követelményeit.
Mobilizálás
Mérnöki podjaink a szerződés aláírását követő 5 és 10 munkanapon belül megkezdik a Sprint 0-t.
Megvalósítás öt szakaszban
Mobilizálás, sprintek élő bemutatókkal, integráció és megerősítés, átvétel és élesítés, majd menedzselt szolgáltatások. Az élesítés után következik: garanciaidőszak, majd opcionális támogatás és karbantartás.
