אסימון קלפים וזרמים מוגנים

1) מדוע אסימון ומה פאן-בטוח

• למזער בדיקת PCI DSS (ועלות שליטה),
• להפחית את הסיכון של דליפות,
• לשפר את האישור (החלפה אוטומטית, COF, לחיצה אחת),
• לפשט ניתוב מרובה PSP ומחיקות.

זרימה פאן-בטוחה היא כזה תרחיש משתמש ושרת שבו PAN מופיעה רק בתוך היקף אמין מבודד (walt/TSP/PSP iframe) ואף פעם לא עוברת דרך גיבוי/יומנים/אוטובוסים של אירועים בטקסט ברור.

2) סוגי אסימונים ומחזור חיים

2. אסימונים בכספת 1 (פרטי)

נוצר על ידי הארנק שלך או ספק בטוח של צד שלישי.
מחובר ל-PAN, אבל התכתובת ההפיכה מאוחסנת רק בוואלס (HSM).
משמש לנתיב לכל PSP/Akavayer (גמישות).
פלוס: עצמאות ממזימות; מינוס: דורש וולט צייתן משלו.

2. 2 Network tokens (מעגל; ויזה/מאסטרקארד/AMEX TSP)

שוחרר על ידי רשתות באמצעות TSP; לעתים קרובות מלווה בקשירת סוחר וקריפטוגרמה.
לשפר את האישור: שיעור אישור גבוה יותר, פחות הונאה-נופל חיובי.
תמוך בעדכון אוטומטי כאשר הכרטיס יונפק מחדש.
מינוס: עניבה עבור תמיכת PSP/מעבד וכיסוי שוק.

2. 3 שימוש יחיד וניתן לשימוש חוזר (COF)

שימוש חד פעמי: לגריטה/חניכה חד פעמית של SCA.
עבור מנויים, מגשים מחדש, תשלומים חוזרים.

2. 4 מחזור חיים

1. ייזום: החזית מקבלת שדות תשלום לא מהתחום שלך (שדות מארחים/iframe TSP/PSP).
2. tokenization: PAN # token (כספת או רשת), cryptogram free (אם נדרש).
3. אחסון: token and metadata (נתוני BIN, סכימה, מונח, קשירת דומיין).
4. שימוש: אישור/kapchur/retrae על ידי אסימון.
5. סיבוב/עדכון: עדכונים אוטומטיים (רשת), עדכון כרטיס (כספת/PSP).
6. זכור/מחיקה: לפי בקשת המשתמש (GDPR/DSR) או לפי מדיניות השמירה.

3) תבניות ארכיטקטוניות פאן-בטוחות

3. שכבת לקוח 1 (web/mobile)

שדות מארחים/iFrame SDK מ ־ PSP/TSP: PAN מוזן מחוץ ל ־ DOM שלך.
החזית שלך מקבלת רק את התכונות הלא קריטיות (4 הספרות האחרונות, BIN-meta).
SCA/3DS מתחיל דרך הספק; השרתים שלך מקבלים את התוצאה/פסק הדין.

3. שירות תזמורות תשלומים 2

לא רואה את PAN; פועל עם אסימונים.
מימושים: ניתוב (primary/secondary PSP), מפתחות אידמפוטנטיות, ריטריז/גיבוב, ניתוב חכם (BIN/region/contrausion).
מחזיק בהגדרה של כללי PSP ודגימות בריאות (SLI/SLO).
יודע איך לסלק פרוקסי (רק כ ”מעבורת שירות” בתוך היקף אמין למסלול).

3. 3 טוקן-וולט (אם יש לו)

HSM backend, הצפנה תואמת FIPS.
בידוד רשת/קטגמנטציה, AAA (MFA/lest privilience), יומני ביקורת, סיבוב מפתח.
API: tokenize (), detokenize (), rotate (), clege () עם ACL/Scopes דקים.
תצורה לשימור הצפנה (FPE) תמיכה - אופציונלית אם אתה זקוק לאחסון ”רעול פנים” ויזואלי.

3. 4 אוטובוס אירועים ומע "מ

באירועים, רק אסימונים ומאבטחים מטא-נתונים.
קישור האישור ↔ kapchur/refand באמצעות payment_id (לא PAN).
PAN ו CVV אינם מורשים במאגר BI.

4) זרמים (תרשימי טקסט)

4. 1 COF ראשוני (כרטיס שמירה)

1. User # Harved Fields (PSP/TSP iframe) מציג את PAN.
2. PSP/TSP # מחזירה אסימון (+ התקן קשירה/קריפטוגרמה).
3. Front # Backend (תזמורת): ”[token, order_id, הקשר]”.
4. תזמורת = PSP: 'auth' by token (אתגר 3DS אפשרי).
5. PSP # תזמורת: ”auth _ group”.
6. תזמורת # שירות ארנק: שמור 'אסימון' ומטה.

PAN לא מופיע בשום מקום בשירותים שלך.

4. 2 חיוב מחדש/מנוי

1. תזמורת לוחות זמנים/עסקים: ”מטען (סימון, כמות)”.
2. תזמורת = PSP: ”לכידה/auth”.
3. PSP # תזמורת: תוצאה + ארן/רן.
4. תזמורת = לדג 'ר/פיוס.

4. 3 כשלים בניתוב חכם

חוק: "אם PSP_A. פח או פח, ואז PSP_B אחר PSP_A'.
עבור אסימונים ברשת, ודא כי שני PSP תומכים בקבלתם; אחרת, להחזיק את הכבילה הבינארית (רשת + כספת).

5) 3DS ו SCA בלולאה פאן-בטוחה

3DS2 משוגרת מה-SDK המארחת; השרתים שלך לקבל כינויים סטטוס (חיכוך, אתגר, כישלון).
קישור פסק דין 3DS payment_id; חפצים עסקיים מאוחסנים (ARes, CRes Reps) ללא PAN.
עבור reclamation (MIT/recuring/undited COF) - סימן נכון את דגלי העסקה (סוג MIT, התייחסות CIT מקורית).

6) ביטחון, ציות ומדיניות נתונים

כוונת PCI DSS: חזית ללא PAN, backend ללא הערכת PAN association מפושטת (SAQ-A/וריאציות). אם קיים walt/diokenation - סקופ מעל (SAQ-D).
סיבוב HSM/key: סיבוב מחזורי של מפתחות מאסטר, בקרה כפולה, פיצול ידע.
GDPR/DSR: Delete token and associated metadata לבקשת המשתמש (השארת PAN לא ידוע).
רישומים/שבילים: תחפושות מחמירות, גלאי דליפות (DLP), חיטוי בעת ביצוע שגיאות.
סגמנט: וולט בקטע המודגש; גישה - רק על MTLS ואסימונים קצרי ימים (STS).

7) אינטגרציה עם PSP/acaviers

7. 1 יכולת PSP מינימלית עבור PAN-בטוח

שדות מארחים/SDK עם אסימונים.
קבל אסימונים ברשת (במידת האפשר) ו/או ייצוא אסימונים בכספת.
מעדכן כרטיסים, סימוני COF, דגלי MIT.
שרת 3DS + תזמור SCA.
משודרים באינטרנט עם משלוח וחתימה אידמפוטנטים.

7. 2 ארכיטקטורת multi-PSP

אבסטרקציה ”מקשר” בתזמור (שדות אחידים).
שולחן ”משקולות/סדר עדיפויות” + סיכות בריאות.
שולחן מדיניות (סכימה, אזור, מוצר, ניקוד סיכונים).
Fallback PSP עבור מסלולים קריטיים (Fallback SLA).

8) שדרוג קלפים ואריכות ימים סמלית

אסימונים ברשת: עדכונים אוטומטיים על שחרור מחדש (הטוב ביותר עבור LTV).
אסימונים בכספת: השתמש במעדכן קלפים (באמצעות PSP/3-part).
מעקב אחר תאריכי תפוגה, הודעות למשתמש, נסיגות רכות (exponential backoff + jitter).
מחייב COF לזיהוי חשבון, לא למשתמש PII, להוצאה מחודשת פשוטה.

9) נסיגה, חרקים ואידמפוטנטיות

idempotency-key = edempotency ( , , .
קטגוריזציה של שגיאה: hard (קוד ירידה קבוע) נגד רך (פסק זמן, רשת, סיכון תלוי ועומד).
גיבוי: 1 מטר = 10 מטר = 1. h = 24 עם קשירה עליונה וירידה קשה.
דו-שכפול של חנויות event_id ושינויים במכונות.

10) פיוס וכספים

שמור על פנקס תשלומים ללא PAN: ”תשלום _ id',” psp _ txn _ id', ”arn/rn',” token _ id', statuses.
בליעה יומית של קובץ PSP/Akavayer; השוואה של סכומים, עמלות, מטענים.
צינורות נפרדים עבור החזרים/חללים/צ 'רג' בקס; תיאום עם חיוב/חשבונאות.

PSP/Country/BIN KPIs

11) מטריצות ומטרות (KPIs)

ביטחון/ציות

% מהשירותים שאף פעם לא רואים פאן (מטרה: 100%).
רמת היקף PCI (מתחת - טוב יותר).

עסקים

קצב אישור (AR) על ידי רשת נגד כספת.
שיעור השמירה של COF, נתח של שיטות מעודכנות אוטומטית.
D + 0/D + 1 אי התאמות פיוס (מטרה: = 0).

טכניקה

אסימון זמן p95.
חלק מהעסקאות דרך הגיבוי.
מספר ניתוקים (מטרה: למזער, רק בתוך הרולר).

12) אנטי דפוסים תכופים

רישום PAN/CVV בחריגים.
טופס לקוח ללא שדות מארחים.
שליחת פאן דרך האוטובוס שלך היא ”זמנית”.
ערבוב אסימונים מתחומים שונים ללא מדיניות מפורשת (סיכון).
אין כרטיס ניתוב (כל התשלומים ”ב-PSP אחד”).
אחסון של חפצי 3DS עם מח "ש מיותר.

13) תוכנית יישום (על ידי צעדים)

1. פרונטנד: אינטגרל שדות מארחים/SDK, הסר את טפסי התשלום שלך.

2. בחירת PSP/TSP: אנו מאשרים תמיכה באסימוני רשת, 3DS2,

3. תזמור: שכבת אבסטרקציה מעל PSP, כללי ניתוב, אידמפוטנטיות, חזרות.
4. וולט (אופציונלי): בחר בכספת מנוהלת או בנה לעצמך (HSM, ACL, סיבובים).
5. נתונים/אירועים: איסור על PAN באוטובוס ו-DWH; יישום שער DLP ב CI/CD.
6. ציות: עדכון היקף PCI, הליכים, יומני ביקורת, בדיקות מיסוך.
7. יכולת תצפית: AR/LSR/latency metrics על ידי PSP, התראות השפלה, לוחות מחוונים.
8. כלכלה: A/B test network vservans by AR/honey/value, travel optimization.

14) רשימת בדיקות פאן-בטוחה

[ ] הזן PAN באייפריים/שדות מארחים בלבד.

[ ] בקנד אף פעם לא מקבל פאן/CVV.

[ ] Tokens מוצפן באחסון, מפתחות HSM, סיבוב מופעל.

[ ] 3DS2 וסק "א מתויגים נכון (CIT/MIT/COF).

[ ] ניתוב מולטי-PSP ומבחן כשל.

[ מעדכן כרטיס ] (רשת/PSP) מופעל.

[ ] בולי עץ/שבילים/זורקים - ללא PAN (מסכות/מחטאים).

[ ] פיוס וצינורות גבס בלי פאן.

[ ] מדיניות הסרת הסמלים של GDPR.

[ ] מטריצות והתראות מכסות איכות זרימת סמלים.

15) תקציר גלוסרי

מספר כרטיס.
טוקן (כספת/רשת) - תחליף בטוח ל ־ PAN.
ספק שירות טוקן.

• מודול אבטחת חומרה.
• SCA/3DS2: אימות חזק/פרוטוקול אימות כרטיס.

16) תקציר

Tokenization היא טכניקה בסיסית להפחתת סיכוני PCI, הגדלת שיעור האישור וניתוב תשלומים גמישים ב-iGaming. לשלב אסימונים ברשת (באמצעות המרה ועדכונים אוטומטיים) עם אסימונים בכספת (באמצעות שליטה ועצמאות), לבנות זרימה פאן-בטוחה עם שדות מארחים, תזמור, ניהול מפתחות ויכולת תצפית שקופה מאישור לפיוס. זה ייתן ביטחון, קנה מידה וכסף צפוי.