Controale AVS/CVV și semnale de fraudă
1) De ce AVS/CVV în iGaming
AVS (Serviciul de verificare a adreselor) și CVV/CVC sunt controale de bază care:- reduce riscul de fraudă/chargebacks în conformitate cu „No Auth „/” Fraudă „,
- creșterea încrederii emitenților în CIT-urile primare
- ajuta buruieni/picături până la 3DS Challenge,
- oferă date pentru rutare și scoring bazate pe politici.
Important: AVS/CVV nu înlocuiesc 3DS2/SCA și tokenizarea, dar funcționează bine împreună.
2) Cum funcționează (în termeni generali)
AVS: compararea adresei de facturare a clientului (strada, index, uneori oraș/stat) cu adresa emitentului. Cod retur (meci/parțial/fără meci/neacceptat).
CVV: verificarea codului de pe hartă; meci/nu meci/nu este procesat/emitentul nu este certificat este returnat.
Ambele rezultate vin într-un răspuns de autorizare de la PSP/achizitor (sau în câmpuri separate de webhook) și trebuie să fie înregistrate fără PAN, asociate cu 'payment _ id'.
3) coduri AVS (rezumat logica deciziei)
Codurile diferă între circuite și PSP-uri, dar normalizarea practică arată astfel:- Coincidență completă: „Y” (street + index) → un semnal pozitiv puternic.
- Meci parţial: 'A' (street ok, index nr), 'Z' (index ok, street no), 'W/X' (9-/5 cifre ZIP), 'D/M' (meciuri internaţionale) → moderat pozitiv.
- Niciun meci: „N” → semnal negativ; eșec sau verificarea enhanced/3DS este posibilă.
- Indisponibil/nu se aplică: „U” (emitent indisponibil), „R” (încercare din nou), „S” (AVS nu este acceptat), „G” (internațional care nu este acceptat) → neutru/ușor negativ, soluția depinde de context.
- Piețe/carduri cu risc ridicat: necesită ≥ potrivire parțială sau 3DS-challenge implicită.
- Clienții cu risc scăzut cu istorie: atenuați la admitere „meci parțial” fără provocare.
- Pentru abonamente (MIT): AVS este util pe CIT-ul inițial; apoi, bazați-vă pe artefacte 3DS/jetoane și istorie.
4) Coduri CVV/CVC (normalizare)
Meci: „M” este un factor puternic pozitiv (în special pentru înregistrarea primară a cărții).
No Match: „N” este un negativ puternic; se recomandă eșecul sau 3DS-challenge obligatorie.
Nu este procesat/Nu este prezent: „P ”/„ S” - ușor negativ, a se vedea contextul (uneori emitentul nu sprijină sau câmpul este pierdut).
Emitentul nu este certificat/Indisponibil: „U” este neutru/ușor negativ.
- Pentru un CIT cu 'CVV = N', de obicei respinge (sau trimite la 3DS-challenge și revizuire).
- Nu se solicită CVV pentru MIT (se repetă); se bazează pe comunicarea cu CIT-ul inițial.
5) pachet AVS/CVV ↔ 3DS/SCA și jetoane de rețea
3DS2 cu un rezultat de succes (ICE/CAVV) oferă o schimbare de răspundere (în cadrul normelor), ceea ce reduce importanța AVS/CVV ca barieră „obligatorie”, dar:- AVS/CVV reduc riscul de provocare și cresc șansele de fricțiune.
- Dacă 'AVS = N' și/sau 'CVV = N', este rezonabil să se forțeze 3DS.
- jetoane de rețea (VTS/MDES/NSPK) și VAU/ABU impuls AR și LTV; împreună cu AVS/CVV oferă o imagine mai bună a riscului la CIT inițial.
6) Semnale de fraudă: ce să colecteze și cum să utilizeze
Semnale tehnice/contextuale:- Amprenta dispozitivului (panza/webgl/audio, шрифты, fus orar, lang).
- Viteza: încearcă să plătească pentru fereastra (prin card/cont/dispozitiv/IP/BIN).
- Geo-consistență: țară IP vs țară BIN vs facturare vs limbă/monedă.
- Modele comportamentale: viteza de intrare, focalizarea câmpului, copy paste, erori CVV.
- Istoricul contului: vârstă, sesiuni de joc AHT, status KYC, returnări.
- Atribute de plată: MCC 7995, tip card (preplătit/debit/credit), risc emitent.
- metadate 3DS: completarea metodei, dsTransID, frecvența provocărilor la emitent.
- Construiți o rată de risc compozit (0-100) cu greutăți: CVV, AVS, dispozitiv, geo, viteză, istorie 3DS.
- „score ≤ T1” → fără frecare (dacă este disponibil);
- „T1
- 'score> T2' → declin sau verificare manuală/alternativă.
7) Soluție matrice (exemplu pentru orchestrator)
8) modele Retrai și UX
Eroare CVV (N): afișați un mesaj clar "Verificați codul de pe card', ștergeți numai câmpul CVV, nu forțați să introduceți totul din nou.
Neconcordanță AVS: sugerați verificarea indexului/străzii, dați indicii de format (ZIP-5/ZIP-9).
Soft-declin/SCA: auto-retry cu 3DS, nici un card re-intrare.
Blocul de viteză: o scurtă „răcire” cu un cronometru și sfaturi pentru a utiliza o metodă diferită.
Alternative: A2A (transferuri bancare), portofele locale pe piață.
9) Scheme de stocare și date (câmpuri minime)
Păstrați numai metadate sigure, fără PAN/CVV:- 'payment _ id',' psp _ txn _ id', 'token _ id',' bin ',' last4 ',' schemă ',' emitent _ country '
- 'avs _ result _ normalized' ∈ {Y, PARŢIAL, N, NA}
- 'cvv _ result _ normalized' ∈ {M, N, NA}
- 'risk _ score', 'velocity _ bucket', 'device _ id',' ip _ country ',' bill _ country '
- 'threeDS': {'version', 'eci', 'cavv'?, 'method _ done': bool, 'challenge': bool}
- 'decision' ∈ {approve, challenge, decline}, 'reason'
- 'route' (PSP_A/B), 'was _ retry': bool, timestamps
10) Măsurători și observabilitate (KPI/SLO)
Calitate și conversie
Rata de aprobare pentru clusterele 'AVS/CVV' (de exemplu, 'CVV = M&AVS = Y' vs 'CVV = M&AVS = parțial').
Frictionless% și Challenge succes% în cadrul claselor AVS.
Abandonați rata pe ecranele de intrare CVV/adresă.
Risc
Rata de chargeback (fraudă/litigiu de consum) în ceea ce privește combinațiile AVS/CVV.
Ponderea fals pozitivă: eșecuri cu legitimitate ulterioară (pentru contestații/repetări).
Soft-declin → retry de succes (după 3DS).
Tehnica
Verificări AVS/CVV de latență (p95) și acțiuni „U/S/G” (nu sunt disponibile).
Adeziuni după 'CVV = N', 'AVS = N' (alerte) în secţiunea BIN/emitent/PSP.
11) Anti-modele
Tratați „AVS = U/S/G” ca pe un eșec greu la BIN-urile internaționale - pierderea conversiei.
Necesită AVS în țările/băncile în care nu este sprijinit sistemic.
Conectați adresele brute fără deghizare și fără goluri - risc de scurgeri/PII.
Hard respinge 'CVV = N' without analiza rata de eroare de intrare (onest mis-type este posibil).
Ignorați artefactele 3DS și istoricul clienților pentru meciuri AVS parțiale.
12) Lista de verificare a implementării
- Normalizat AVS/CVV Code Dictionary by Scheme/PSP.
- Politici decizionale (aprobare/provocare/declin) prin combinație.
- Integrarea cu 3DS2: auto-tranziție la provocare cu AVS negativ/CVV.
- Scoring de risc: dispozitiv, geo, viteză, istoricul clienților, politici BIN.
- Șabloane de eroare UX (localizare, salvarea câmpurilor introduse).
- Tablouri de bord și alerte KPI pentru exploziile „N ”/„ U/S/G”.
- PAN-safe: campuri gazduite/iframe, tokenization; în jurnale - numai metadate.
- A/B teste de praguri (T1/T2) și norme privind piețele/emitenții.
- Playbooks de retroys/soft-declin și metode alternative de plată.
- Address Retention/Politici PII (GDPR/DSR), mascare, minimizare.
13) Exemplu de politici de piață (schiță)
SUA/Canada (AVS strong): „AVS = Y” sau „risc parțial + 3DS/low”; 'AVS = N' → provocare/declin.
UE (PSD2): accentul pus pe 3DS2 (fără fricțiuni acolo unde este posibil); AVS - semnal de notare.
Piețe internaționale cu suport AVS limitat: dependență de dispozitivul 3DS +/geo/viteză; 'AVS = U/S/G' - neutru.
14) Rezumat
AVS/CVV sunt „primele filtre” în plățile CNP. Acestea ar trebui să lucreze în combinație cu 3DS2, tokenization și scoring de risc, iar deciziile ar trebui să fie luate în context, și nu printr-un singur cod. Normalizați răspunsurile, construiți scoring, automatizați tranziția la 3DS, gestionați cu atenție adresele/PII și măsurați rezultatul cu metrici. Deci, ai reduce frauda și chargebacks fără a ucide conversia.