Plăți, comerț agentic (AP2) și POS
Plăți cu cardul, finalizare a comenzii pentru agenți IA și magazine conectate de la terminal la registru
Când magazinele, casele de marcat și registrul nu sunt de acord
O plată cu cardul atinge mai multe sisteme în câteva secunde: terminalul sau casa de marcat, un gateway, acceptatorul, schema de carduri și emitentul. Banii și comisioanele sosesc mai târziu, în fișiere de decontare pe care cineva trebuie să le potrivească cu vânzările din ERP.
Când magazinele, comenzile online și ERP-ul se sincronizează în loturi nocturne, stocul se vinde în plus în campaniile promoționale, iar diferențele de decontare se acumulează între acceptatori. Finalizarea comenzii încetinește în cele mai aglomerate momente. Acum și agenții IA încep să cumpere în numele clienților.
Ce se schimbă pentru dumneavoastră
O singură imagine a stocului și a vânzărilor
Vânzări, retururi, prețuri și stoc sincronizate în fiecare magazin, magazin online și în ERP, în timp real, nu peste noapte.
Decontări care se potrivesc
Fișierele de decontare și de comisioane de la fiecare acceptator potrivite automat cu vânzările, iar diferențele listate pentru echipa dumneavoastră.
Pregătiți pentru comerțul cu agenți IA
O finalizare a comenzii care acceptă plăți de la agenți IA, cu o evidență verificabilă a ceea ce a autorizat clientul.
Ce livrăm
Conectivitate la gateway, acceptatori și rețele de carduri
Fluxuri de autorizare, capturare, rambursare și stornare prin ISO 8583, ISO 20022 sau API-ul furnizorului, cu orchestrare între mai mulți acceptatori și fiecare cod de răspuns tratat.
AP2 și finalizarea comenzii cu mandat criptografic
AP2 este un protocol deschis care permite unui agent IA să plătească în numele unui client. Mandatele semnate criptografic consemnează ce a aprobat clientul, iar noi le integrăm în finalizarea comenzii.
Terminale EMV și SoftPOS
Terminale cu cip EMV și fără contact și SoftPOS, care acceptă carduri fără contact pe un telefon sau o tabletă obișnuită, conectate la software-ul dumneavoastră de POS sau chioșc.
Prelucrarea automată a fișierelor de decontare
Fișierele de decontare și de comisioane ale acceptatorilor colectate, validate, auditate și transformate în înregistrări contabile pe care ERP-ul le poate potrivi.
Sincronizare POS-ERP în timp real
Vânzări, retururi, prețuri, promoții și niveluri de stoc sincronizate între fiecare magazin și ERP printr-un nivel de streaming de evenimente.
Tokenizare și sfera PCI DSS
Numerele de card înlocuite cu tokeni și ținute în afara POS-ului și ERP-ului, cu o imagine documentată a sistemelor care rămân în sfera PCI DSS.
Certificare și extindere
Scripturi de test și dovezi pentru certificarea fiecărui furnizor, un proiect pilot în câteva magazine, apoi extinderea magazin cu magazin, cu totalurile zilnice comparate.
Cum lucrăm
Urmărirea unei vânzări
Urmărim o vânzare de la casă sau finalizarea comenzii până la registru, împreună cu echipele dumneavoastră financiare, de magazine și IT, și stabilim scopul.
Proiectarea integrării
Alegem protocoalele, abordarea de tokenizare și fluxurile de mesaje și scriem specificația interfeței.
Construire și testare
Construim fluxurile de plată, de decontare și de POS cu teste automate, inclusiv refuzuri, expirări de timp și rambursări.
Certificare la furnizor
Rulăm cazurile de test ale furnizorului în mediul său de test și corectăm ce găsește certificarea.
Pilot, apoi extindere
Intrăm în producție mai întâi în câteva magazine sau canale, comparăm totalurile zilnic și apoi extindem magazin cu magazin.
Monitorizare și suport
Urmărim ratele de aprobare, fișierele de decontare și înregistrările din magazine și gestionăm schimbările furnizorilor pe măsură ce sunt anunțate.
Derulați lateral pentru a vedea întregul desen.
Plăți cu cardul: autorizate la casă, decontate mai târziu, reconciliate în ERP
Terminalul sau checkout-ul întreabă gateway-ul, gateway-ul întreabă acceptatorul, iar acceptatorul direcționează către rețeaua de carduri și emitent. Fișierele de decontare sosesc mai târziu și sunt corelate cu vânzările și comisioanele din ERP. Un timeout declanșează o inversare, astfel încât clientul să nu fie taxat de două ori.
- Flux principal
- Asincron
- Cale de excepție
Fluxul în 8 pași
Fluxul, pas cu pas
- De la Terminal EMV sau checkout online la Gateway de plăți: Cerere de autorizare, prin EMV · REST/JSON (flux principal).
- De la Gateway de plăți la Acceptator: Autorizare, prin ISO 8583 (flux principal).
- De la Acceptator la Rețea de carduri și emitent: Direcționat către emitent, prin ISO 8583 (flux principal).
- De la Acceptator la Gateway de plăți: Aprobat sau refuzat, prin ISO 8583 (asincron).
- De la Acceptator la Strat de integrare: Fișiere de decontare și comisioane, prin SFTP (asincron).
- De la Strat de integrare la ERP: Vânzări, comisioane și plăți decontate, prin REST/JSON (flux principal).
- De la Gateway de plăți la Terminal EMV sau checkout online: Niciun răspuns în timp: inversare automată, prin ISO 8583 0400 (cale de excepție).
- De la Strat de integrare la Echipa de operațiuni de plăți: Neconcordanță de decontare sau chargeback (cale de excepție).
Derulați lateral pentru a vedea întregul desen.
POS către ERP: fiecare vânzare postată o singură dată
Vânzările curg de la casele de marcat la ERP ca evenimente, iar prețurile și stocurile curg înapoi. Un magazin care rămâne offline continuă să vândă și se sincronizează la revenire. O înregistrare care eșuează este reîncercată, apoi predată unei persoane.
- Flux principal
- Asincron
- Cale de excepție
Fluxul în 8 pași
Fluxul, pas cu pas
- De la Terminale POS la Server de magazin sau cloud POS: Vânzări, retururi și anulări (flux principal).
- De la Server de magazin sau cloud POS la Strat de integrare: Evenimente de vânzare și totaluri de sfârșit de zi, printr-o coadă de evenimente, prin REST/JSON (asincron).
- De la Strat de integrare la ERP: Vânzări și mișcări de stoc postate, prin OData · REST/JSON (flux principal).
- De la ERP la Strat de integrare: Prețuri, promoții și date despre articole, prin API sau export de fișier, prin REST/JSON (flux principal).
- De la Strat de integrare la Server de magazin sau cloud POS: Actualizări de prețuri și stocuri, prin REST/JSON (flux principal).
- De la Strat de integrare la Coadă de reîncercări: Postare eșuată (cale de excepție).
- De la Coadă de reîncercări la Strat de integrare: Reîncercat (cale de excepție).
- De la Coadă de reîncercări la Echipa de operațiuni a magazinelor: Încă eșuează: alertă cu detalii (cale de excepție).
Standarde și protocoale
Numirea unui produs sau a unui furnizor nu înseamnă un parteneriat cu acesta.
- Limbaje
- Go
- Framework-uri
- Node.js
- Date și analize
- Apache Kafka
- Baze de date
- Redis
- DevOps și observabilitate
- Kubernetes
- Standarde și canale bancare
- ISO 20022
- Plăți
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
Dovada în producție
Pentru un grup de retail și centre comerciale din GCC cu mai multe branduri, am înlocuit scripturile de lot nocturne cu sincronizare POS-ERP în timp real. Am unificat și plățile prin mai mulți acceptatori cu decontare automată și am construit un serviciu de rezervare a stocului pentru vârfurile de vânzări fulger.
Cum să începeți
Cerințele clare privind furnizorii și magazinele merg direct la o propunere. O platformă nouă de plăți, sau o finalizare a comenzii pentru agenți IA, începe de obicei în Blueprint Studio.
Ce se întâmplă în continuare
Sesiune de preconsultanță
O sesiune online gratuită de preconsultanță de 30 de minute: trecem în revistă obiectivele, sistemele și constrângerile dumneavoastră.
Evaluarea de pregătire
Într-o evaluare de pregătire gratuită în 48 de ore, un arhitect principal verifică proiectul dumneavoastră față de definiția „pregătit” în 6 puncte și recomandă traseul potrivit.
Alegerea traseului
Proiectele cu scop definit primesc o propunere fermă în 3–5 zile lucrătoare. Proiectele aflate în faza de concept încep în Blueprint Studio. Un sistem live care eșuează, nu este documentat sau are nevoie de integrare începe cu un diagnostic de 1–2 săptămâni. Blueprint Studio și diagnosticul au fiecare un tarif fix, cotat în propunere.
Livrare în cinci etape
Mobilizare, sprinturi cu demonstrații live, integrare și consolidare, acceptanță și intrare în producție, apoi servicii administrate. După lansare urmează o perioadă de garanție, apoi suport și mentenanță opționale.
Echipe de produs native IA
Poduri multifuncționale administrate, formate din ingineri seniori, dotate cu cadre agentice de programare și de QA.
Proiecte cu rezultat fix și servicii administrate non-stop
Livrare cu scop fix, organizată pe etape, cu responsabili de livrare numiți, și servicii administrate pentru aplicații non-stop, sub guvernanță SLA.
Întrebări și răspunsuri
Lucrați direct cu ISO 8583?
Da, acolo unde acceptatorul sau procesatorul îl oferă. ISO 8583 este un cadru, nu un singur format: fiecare acceptator își publică propria specificație de câmpuri și tipuri de mesaje. Construim pe baza acelei specificații, tratăm autorizări, stornări și mesaje de notificare și testăm fiecare cod de răspuns.
Ce este AP2 și avem nevoie de el acum?
Agent Payments Protocol (AP2) este un protocol deschis pentru plățile făcute de agenți IA. Fiecare achiziție poartă mandate semnate care arată ce a autorizat clientul, astfel încât comercianții, emitenții și acceptatorii să o poată verifica și audita. Dacă este probabil ca agenții IA să cumpere de la dumneavoastră, putem pregăti finalizarea comenzii pentru AP2 alături de fluxurile actuale.
Cum reduceți sfera noastră PCI DSS?
Nu putem elimina PCI DSS, dar putem reduce cât din mediul dumneavoastră acoperă. Paginile de plată găzduite, criptarea punct-la-punct la terminal și tokenii gateway-ului țin numerele de card în afara POS-ului, ERP-ului și depozitului de date. Documentăm fluxurile de date pentru evaluatorul dumneavoastră.
Putem accepta carduri pe telefoane în locul terminalelor?
Da, cu SoftPOS. Cardurile și portofelele fără contact sunt acceptate pe un telefon sau o tabletă compatibilă printr-o aplicație de plată certificată de la acceptatorul sau furnizorul dumneavoastră. Integrăm acea aplicație cu fluxurile de POS, vânzări și decontare ca pe orice alt terminal.
Ce se întâmplă când un magazin își pierde conexiunea?
Magazinul continuă să vândă. Vânzările sunt stocate local și trimise în ERP când revine conexiunea, fiecare cu un identificator unic, astfel încât nimic să nu fie înregistrat de două ori. Dacă plățile cu cardul pot continua offline depinde de regulile acceptatorului și de apetitul dumneavoastră la risc, iar acest lucru îl proiectăm împreună.
Gestionați rambursările și retragerile de fonduri?
Da. Rambursările și stornările fac parte din fluxurile de plată pe care le construim. Pentru retragerile de fonduri (chargeback), importăm rapoartele de dispute ale acceptatorului și legăm fiecare de vânzarea și decontarea inițială. Echipa dumneavoastră primește o listă de parcurs, cu dovezile atașate.
Gata de construcție? Cereți o propunere.
Trimiteți cerințele sau cererea de propunere (RFP). Arhitecții noștri le validează și vă returnează o propunere fermă, cu scop fix.
Ce se întâmplă în continuare
Evaluarea de pregătire
Într-o evaluare de pregătire gratuită în 48 de ore, un arhitect principal verifică proiectul dumneavoastră față de definiția „pregătit” în 6 puncte și recomandă traseul potrivit.
Propunere fermă
După validare de arhitectură fără costuri, primiți o propunere fermă cu scop fix în 3–5 zile lucrătoare: etape, arhitectură, structura echipei și SLA-uri. La cerere, semnăm cu dumneavoastră un acord de confidențialitate (NDA) înainte să ne împărtășiți cerințele.
Mobilizare
Odată ce semnați, echipele noastre de inginerie încep Sprintul 0 în 5–10 zile lucrătoare de la semnarea contractului.
Livrare în cinci etape
Mobilizare, sprinturi cu demonstrații live, integrare și consolidare, acceptanță și intrare în producție, apoi servicii administrate. După lansare urmează o perioadă de garanție, apoi suport și mentenanță opționale.