Plăți cu cardul
Plăți cu cardul: de la terminal la acceptator și înapoi în contabilitate
Terminale EMV și gateway-uri de plăți conectate la acceptatori prin ISO 8583 sau API-uri, cu fișierele de decontare reconciliate în ERP.
Blueprint
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).
Prezentare generală
Acesta este traseul unei plăți cu cardul, de la terminal sau de la finalizarea comenzii online către acceptator, schema de carduri și emitent, și înapoi. Clientul așteaptă răspunsul la casă. Banii, minus comisioanele, ajung mai târziu, într-un fișier de decontare care trebuie potrivit cu vânzările din ERP-ul dumneavoastră.
Arhitectura de referință trimite autorizările printr-un gateway de plăți care tokenizează cardul și direcționează cererea către acceptator, prin ISO 8583 sau prin API-ul acceptatorului. Fișierele de decontare și de comisioane sunt colectate de stratul de integrare, potrivite cu vânzările originale și înregistrate în ERP ca vânzări, comisioane și plăți către comerciant.
Arhitectura acoperă și ce merge prost. O cerere care nu primește răspuns la timp este stornată, astfel încât clientul să nu fie taxat de două ori. O decontare care nu se potrivește sau o retragere de fonduri (chargeback) ajunge la echipa dumneavoastră de operațiuni de plăți, împreună cu vânzarea originală.
Cum funcționează fluxul
Pornirea la terminal sau la finalizarea comenzii
Terminalul EMV citește cardul cu cip sau contactless, ori pagina de finalizare a comenzii colectează datele cardului printr-o pagină găzduită, și trimite o cerere de autorizare către gateway.
Autorizare prin gateway
Gateway-ul înlocuiește numărul cardului cu un token și trimite autorizarea către acceptator, prin ISO 8583 sau prin API-ul acestuia.
Direcționare către emitent
Acceptatorul direcționează cererea prin schema de carduri către emitent, care o aprobă sau o respinge.
Returnarea răspunsului
Aprobarea sau respingerea se întoarce pe același traseu către terminal sau pagina de finalizare, împreună cu codul de răspuns.
Primirea decontării
Ulterior, acceptatorul trimite fișierele de decontare și de comisioane, pe care stratul de integrare le colectează și le validează.
Potrivire și înregistrare
Stratul potrivește tranzacțiile decontate cu vânzările originale și înregistrează în ERP vânzările, comisioanele și plățile către comerciant.
Când ceva eșuează
Niciun răspuns la timp
Dacă gateway-ul nu primește un răspuns în termenul acceptatorului, trimite o stornare, un mesaj ISO 8583 0400 sau echivalentul său prin API, astfel încât clientul să nu fie niciodată taxat pentru o vânzare care nu s-a finalizat.
O plată este respinsă
Codul de răspuns ajunge la casă sau la pagina de finalizare, cu un mesaj clar. Ratele de respingere sunt monitorizate, astfel încât o creștere bruscă ce indică o defecțiune tehnică să declanșeze o alertă.
Decontarea nu se potrivește
O sumă decontată care diferă de vânzare sau o vânzare fără decontare ajunge pe o listă de verificare pentru echipa dumneavoastră de operațiuni de plăți, cu ambele înregistrări alăturate.
Un deținător de card contestă o plată
Raportul de litigii al acceptatorului este importat și legat de vânzarea și decontarea originale, astfel încât echipa dumneavoastră să poată răspunde cu dovezile într-un singur loc.
Standarde și sisteme
- Standarde și canale bancare
- SFTP (H2H)
- Plăți
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- Integrare
- REST
- Webhooks
Întrebări și răspunsuri
Care este diferența dintre un gateway și un acceptator?
Acceptatorul este banca sau instituția autorizată care procesează plățile cu cardul pentru dumneavoastră și vă virează banii. Gateway-ul este serviciul tehnic din fața lui, care preia cererile de la terminale și paginile de finalizare, tokenizează cardurile și le direcționează. Unii furnizori oferă ambele. Arhitectura funcționează în ambele cazuri și păstrează cele două roluri clare.
Această soluție ține datele cardurilor în afara sistemelor noastre?
Acesta este scopul arhitecturii. Numerele de card sunt captate de terminalul certificat sau de o pagină de plată găzduită și înlocuite cu tokeni la gateway, astfel încât POS-ul, ERP-ul și bazele dumneavoastră de date să vadă doar tokeni. Astfel se reduce partea din infrastructura dumneavoastră căreia i se aplică PCI DSS. Evaluatorul dumneavoastră confirmă sfera finală.
ISO 8583 este același la fiecare acceptator?
Nu. ISO 8583 definește o structură, iar fiecare acceptator sau rețea publică propria specificație de câmpuri, tipuri de mesaje și coduri. De aceea construim pornind de la specificația acceptatorului și rulăm testele sale de certificare. Un API de gateway în fața acceptatorului ascunde aceste diferențe, ceea ce este adesea mai simplu pentru retaileri.
De ce decontarea ajunge mai târziu decât vânzarea?
Autorizarea doar rezervă fondurile. Acceptatorul decontează în loturi, după ce își deduce comisioanele și eventualele taxe ale schemei, și virează banii conform propriului calendar. De aceea arhitectura tratează autorizarea și decontarea ca evenimente separate și le potrivește, astfel încât finanțele să vadă ce s-a vândut, ce s-a decontat și ce urmează să sosească.
Sprijiniți EMV 3-D Secure pentru plățile online?
Da. Pentru plățile online cu cardul integrăm EMV 3-D Secure prin gateway, astfel încât emitentul să poată autentifica deținătorul cardului acolo unde reglementările sau riscul o cer. Gestionăm fluxurile cu provocare și pe cele fără fricțiune în pagina de finalizare și le testăm pe ambele cu cardurile de test ale furnizorului.
Putem folosi mai mulți furnizori de plăți?
Da. Stratul de integrare păstrează un singur model intern al unei plăți și îl transformă pentru fiecare furnizor, astfel încât puteți direcționa după canal, țară sau tip de card, ori muta volumul între furnizori. Fiecare furnizor are totuși nevoie de propria integrare și certificare, pe care le planificăm furnizor cu furnizor.
Începeți cu o conversație, nu cu un contract.
Spuneți-ne ce trebuie să construiți, să conectați sau să securizați. Un arhitect parcurge totul împreună cu dumneavoastră, apoi recomandă de unde să începeți.
Ce se întâmplă în continuare
Convenirea unei ore
Echipa noastră vă scrie prin e-mail pentru a conveni o oră pentru sesiune.
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.