Dacă vă construiți propriul instrument care interacționează cu plățile, cine își asumă riscul de conformitate?

Dumneavoastră. Nu inteligența artificială care a generat codul, nu furnizorul de găzduire și nu procesatorul de plăți. În momentul în care un instrument pe care l-ați construit interacționează cu plățile, riscul de conformitate revine companiei dumneavoastră și rămâne acolo, indiferent de câți furnizori conformi integrați. Ceea ce puteți schimba este amploarea acestui risc, iar diferența dintre un instrument personalizat bine conceput și unul realizat neglijent este uriașă.

De ce revine riscul asupra dumneavoastră și nu asupra furnizorilor?

Acceptarea cardurilor se bazează pe un lanț de contracte. Rețelele de carduri stabilesc regulile, banca acceptatoare (banca care decontează vânzările prin card pentru dumneavoastră) le aplică, iar acordul de comerciant vi le transmite dumneavoastră. Setul de reguli este PCI DSS, standardul de securitate a datelor din industria cardurilor de plată, și se aplică oricărei companii care stochează, procesează sau transmite date ale deținătorilor de carduri (numerele de card și detaliile asociate acestora). Versiunea curentă este 4.0.1. (Numerele versiunilor și detaliile programului sunt exacte la data publicării; tratați aceste detalii specifice ca pe o situație la un moment dat.)

Furnizorii dumneavoastră au obligații pentru propriile sisteme, iar un procesator de plăți conform vă reduce dramatic volumul de muncă. Însă nimic din ceea ce face un furnizor nu transferă responsabilitatea. Consiliul pentru Standarde de Securitate PCI (PCI Security Standards Council) precizează în mod explicit că obligativitatea de a valida conformitatea este decisă de mărcile de carduri și de banca acceptatoare, iar răspunsul lor, înscris în acordul de comerciant, este da. În fiecare an, cineva din cadrul companiei dumneavoastră semnează o declarație prin care atestă că mediul dumneavoastră respectă standardul. Acea semnătură este a dumneavoastră, nu a furnizorului.

Ce se schimbă în momentul în care propriul cod interacționează cu datele cardului?

Aria de aplicare (Scope). Efortul de conformitate este evaluat în funcție de aria de aplicare: fiecare sistem care interacționează cu datele deținătorilor de carduri, plus tot ceea ce este conectat la acesta, intră sub incidența standardului.

Un comerciant ale cărui plăți sunt gestionate în totalitate de un furnizor conform și de dispozitivele sale certificate validează conformitatea printr-un chestionar scurt de autoevaluare (o listă de verificare anuală), cu câteva zeci de întrebări. Un comerciant al cărui software propriu gestionează numerele de card intră în categoria cea mai complexă, care reflectă cea mai mare parte a standardului complet: peste două sute de cerințe care acoperă scanări trimestriale de vulnerabilități, teste de penetrare, controale de acces, jurnalizare (logging) și politici oficiale de securitate¹.

Acel formular de checkout pe care o inteligență artificială l-a scris pentru dumneavoastră într-o după-amiază? Dacă acceptă numere de card, serverul web, baza de date, laptopul de administrare și rețeaua Wi-Fi a magazinului sunt toate candidate pentru a intra în aria de aplicare. Și nu puteți trimite în liniște chestionarul scurt în orice caz. Alegerea unei categorii pentru care nu sunteți eligibil nu vă reduce riscul; înseamnă că documentul pe care l-ați semnat este incorect, lucru care tinde să iasă la iveală în cel mai nefavorabil moment, imediat după o breșă de securitate.

Cât costă, de fapt, dacă greșiți?

Aplicarea sancțiunilor este contractuală, așa că de obicei apare pe extrasul de procesare. Mulți procesatori facturează o taxă recurentă de neconformitate în fiecare lună până când validați conformitatea. După o breșă de securitate, costurile se acumulează: o investigație criminalistică obligatorie pe care o plătiți dumneavoastră, costurile de reemitere a cardurilor și penalități progresive transmise prin banca acceptatoare, menționate de obicei în intervalul de la 5.000 USD la 100.000 USD pe lună (pe baza grilelor de penalități publicate de evaluatorii de conformitate PCI). În cazuri grave, o companie poate pierde complet capacitatea de a accepta carduri.

Pentru un comerciant mic, cel mai mare cost este mai puțin vizibil decât orice amendă: gestionarea unui program real de securitate necesită timp pe care plănuiați să îl dedicați administrării afacerii.

Cum puteți construi instrumente personalizate fără a intra în aria de aplicare pentru datele de card?

Păstrați codul în afara fluxului de date al cardului. Instrumentul dumneavoastră personalizat ar trebui doar să organizeze vânzarea: să creeze coșul de cumpărături, să aplice reduceri, să calculeze totalul comenzii și să trimită suma care urmează să fie încasată. Cardul propriu-zis ar trebui să interacționeze doar cu un terminal certificat (echipament de plată validat pentru a gestiona carduri) sau cu pagina de plată găzduită a furnizorului dumneavoastră, oricare dintre acestea transmițându-l direct către un procesator de plăți (compania care transferă banii). Instrumentul dumneavoastră primește înapoi un rezultat, aprobat sau respins, plus un token (un număr de referință inutil pentru oricine l-ar fura).

Această separare este întreaga argumentație în favoarea arhitecturii POS headless: ecrane personalizate la suprafață, infrastructură de plată certificată dedesubt. Este, de asemenea, motivul pentru care paginile de checkout generate de IA arată excelent în demo-uri, dar se blochează în producție, și de ce un formular web este un răspuns greșit pentru plățile fizice cu debit, cum ar fi Interac: plățile în persoană aparțin echipamentelor certificate, atât din punct de vedere tehnic, cât și contractual.

Final este construit exact în jurul acestei delimitări. Fluxurile pe care le construiți, fie că le generați singur prin prompturi, fie că vă conectați propria IA prin MCP, controlează ecranele, coșurile de cumpărături și cataloagele. Datele cardului merg de la terminalul hardware certificat către un procesator de plăți prin Final Pay și nu intră niciodată în fluxul pe care l-ați construit. Personalizat acolo unde personalizarea este sigură, standardizat acolo unde se află răspunderea.

Așadar, cine își asumă riscul de conformitate?

Dumneavoastră, și așa va fi întotdeauna. Decizia reală este cât de mult din aria de aplicare vă asumați, iar aceasta este o alegere de arhitectură, nu o alegere de documente. Înainte de a lansa un instrument care interacționează cu plățile, puneți-vă o singură întrebare: poate codul meu să vadă vreodată un număr de card? Dacă da, programul de conformitate este responsabilitatea dumneavoastră. Dacă nu, păstrați flexibilitatea unei soluții personalizate cu doar o fracțiune din efort. Dacă analizați un astfel de proiect acum, începeți cu semnele că ați depășit capacitățile POS-ului dumneavoastră standard.