שוויץ: QR ו-In-app

1) הקשר ומיקום TWINT

TWINT היא תוכנית תשלום ניידת של A2A וארנק משולב עם בנקים במדינה. המשתמש משלם מיישום TWINT/Bank: Online - באמצעות in-app/App2App או Deep Link, offline - באמצעות QR (TWINT QR סטנדרטי). האישור מבוצע ביישום (SCA: PIN/biometrics), הקרנות נדחות על ידי החשבון/כרטיס הנלווה לזכותו של הסוחר באמצעות אשראי בנקאי.

• מותג/QR מאוחד לאינטרנט ו ־ POS, בהישג יד גבוה למשתמש.
• אישור מקוון מיידי עבור UX והסדר מהיר (בתוך חלונות בנק).
• P2P על ידי מספר טלפון/קשר בתוך המערכת האקולוגית.
• הונאה נמוכה עקב SCA וקשירת מכשיר.

2) חברים ותפקידים

חוקים, ספריות משתתפות, ניתוב.
בנק TWINT/issuer: KYC, גבולות ואנטי הונאה.
PSP/רוכשים: לחבר סוחר (Online/POS), לספק API/SDK, ווי אינטרנט ודיווחים.
סוחר: החל בתשלום/בקשה, תהליכים סטטוסים/החזרות, שומר על פיוס.
Payer: מאשר עסקאות ביישום TWINT/Bank.

3) ערוצים ותרחישים למשתמש

3. 1 E-commerce: in-app/Deep Link/ App2App

על הצ 'ק, הסוחר יוצר כוונת תשלום _ נותן קישור עמוק/כפתור Pay TWINT.
יישום TWINT נפתח (App2App), המשתמש מאשר את החזרה לקופאית עם הסטטוס.
QR דינמי לכל סדר מוצג עבור שולחן העבודה; הלקוח סורק את הבקשה ומאשר.

3. 2 POS/offline: TWINT QR

QR דינמי על מסך הקופה/מסוף: סכום, ID, metadata.
המשתמש סורק * מאשר ביישום * הסוחר מקבל סטטוס מקוון.
QR סטטי (הסכום נכנס באופן ידני) מתאים לתרומות/קמעונאות קטנה, אך גרוע יותר לפיוס.

3. 3 P2P ”לכל טלפון”

העברות בין אנשים על ידי מספר טלפון/מגע עם אישור דחוף ואשראי מיידי לנמען.

3. 4 בקשה לתשלום/תשלום על ידי קישור

הסוחר יוזם בקשה לתשלום (סכום/תור/תאריך יעד) * הלקוח מאשר ביישום כי התשלום עובר בזרימת A2A הרגילה.

4) סטטוסים ותזמונים

סטטוסים טיפוסיים הם ”יזום” * ”תלוי ועומד” * ”הצלחה ”/” נכשל ”/” בוטל ”/” פג תוקף”.
עבור QR/שולחן עבודה, שקול את פסק הזמן לאישור (הצג את מד הזמן).
הסדר: אשראי בנק T + 0/T + 1 תלוי בחלון ההסדר/PSP; איסוף מידע יומי עדיין נדרש לדיווח.

5) מגבלות ומדיניות סיכון

• כל עסקה, ביום/24h, לפעמים שבועית/חודשית.
• מקלט/סוחר חדש - סף מופחת ו/או מהירות תריס.
• גבולות הערוץ: e-commerce (קישור עמוק/QR), POS, P2P, בקשה-לתשלום.
• מהירות/התקן/geo-rules מיושמים על ידי הבנקים והתוכנית.

6) כלכלה ועמלות

עבור הסוחר, TWINT הוא בדרך כלל זול יותר מאשר כרטיס MDR טיפוסי; התנאים שונים בין PSPs (תיקון/נמוך%).
חיוב עבור אינטגרציה/SDK, עיבוד/פג תוקף, תמיכה/ODR ופיוס.

7 מחזירה ומחלוקת

צ 'רגק (כמו בקלפים) חסר. החזר - העברת אשראי חדשה מסוחר למשלם; החזרים חלקיים נתמכים.
תאריכי החזרה הם בנק (בדרך כלל T + 0/T + 1).
מחלוקות/תלונות - על פי נוהלי PSP/בנק; לשמור יומני סדר, אישור של שירות/משלוח, חבילת refund↔order.

8) בטיחות וציות

SCA ביישום TWINT/Bank (סיכה/ביומטריה), קשירת התקן.
אנטי-פראוד בבנק/PSP: מהירות, מקבלים חדשים, סיכונים ניקוד.
מזערי PII והצפנה, HMAC/nonce על ווים באינטרנט, הגנה שידור חוזר, יומן ביקורת.
ענו על דרישות שירות התשלומים המקומי ותקנות הגנת מידע השוואת GDPR.

9) שילוב סוחרים

אפשרויות

1. מארח/משובץ ב- PSP - התחלה מהירה, בתוך-אפליקציה/QR מחוץ לקופסה, סטטוסים ושגיאות.
2. שרת אל שרת + קישור עמוק/QR - מולדת UX, QR דינמי לכל סדר, טיפול שגיאות בסדר.
3. תשלום לפי קישור/בקשה לתשלום - חיוב עם קישור (דוא "ל/SMS/שליח).

• Api: ”תשלום”, ”החזר”, ” ToPay”, ”webhook”, ”ליישב”.
• אידמפוטנציה (" Id' + key), מגשים אקספוננציאליים, dedup אירועים.
• סיור: סיור אוטומטי יומי + סיור מלא מחזורי; אחסון UTR/התייחסות לבנק.
• לוחות מחוונים SLA: המרה, 'תלוי ועומד' הצלחה/פג תוקף, זמן להרשמה/חזרה.

10) פיוס ודיווח

יומן: ' ID/transactionId' של הספק,' Id', ערוץ (App2App/QR/Link), בנק payer, סטטוס, כמות/מטבע, חותמת זמן, UTR.
מתוך PSP/Bank: רשמים של נקודות זכות/החזרות/תיקונים, עדכוני מצב מאוחרים.
הגדרת התראות מחוץ לסנכרון ו ”תלייה” ”תלוי ועומד”.

11) שיטות UX

מובייל-ראשון: בנייד - in-app/App2App; על שולחן העבודה - QR דינמי גדול עם טיימר.
התאוששות: עם ”פסק זמן/פג תוקף” - חזרה בטוחה ואלטרנטיבית (כרטיס/SEPA/A2A אחר).
קבלה: סכום, זמן, 'transactionId', ערוץ, UTR, אנשי קשר תומכים.
הדגשת סיכונים/מגבלות: הראה למשתמש מי קבע את הסף - בנק או ערוץ.

12) הישנות ומנדטים

הטווינט הבסיסי הוא חד פעמי עם SCA. עבור מנויים, נעשה שימוש בצרור: התשלום הראשון TWINT = e מנדט/SEPA DD/Open-Banking לכתיבה עתידית (הגבלה/תדירות/הודעות).
תן למשתמש הפסקה/ביטול/עדכון ומסך הודעה מראש לפני כתיבה.

13) אלומות בסיכון גבוה (כולל iGaming)

זמינות ערוץ ומגבלות תלויות במדיניות בנק/PSP וחוק מקומי.
תצפה להנמכת סף, קיי-סי-סי משופר, אפשרות לחיזוקים.
תוכנית מסילות אלטרנטיביות (כרטיסים, SEPA, PIS אחר) וניתוב חכם על ידי סיכון/ערוץ/בנק.

14) ארכיטקטורת שער TWINT

שכבת API (Rest/GraphQL) לקופה ומחפרון.
תורים לאירוע: אירועי מצב * חיוב/CRM/אנליטיקה.
אבטחה: כספת לסודות, IP-Allowlist PSP, אימות מחודש קפדני, אסימונים נגד הילוך חוזר.
יכולת תצפית: המרת ערוץ (App2App/QR/Link), חלק מ ”תלוי ועומד”, זמן להסדר/חזרה.

15) רשימת תפוקה

1. חיבור TWINT ב- PSP/Bank; ערוצים נבחרים (App2App/QR/Link).
2. יישום ”CreatSame ”/” ToPay”, QR דינמי, שגיאה/הגבלת מסכים.
3. להתחבר לספרי אינטרנט, אידמפוטנטיות, רטריי ודדופ אירועים.
4. הגדרת איסוף מידע (יומי + מלא), אחסון הפניות UTR/fin.
5. תמכו בהחזרים חלקיים/מלאים ובהליכי ODR.
6. הפעל לוחות מחוונים SLA והתראות להמרה/latency/hound statuses.
7. ביצוע בדיקות e2e עם בנקים/התקנים ראשיים ו-POS (אם זה רלוונטי).

הגבל כרטיס התייחסות

הסף האמיתי מגדיר את הבנק/PSP ומשתנה לפי התרחיש.

Per-txn/24h/7d: לאחסן בקונפיג ולבדוק לפני תחילת.
מקבלים/סוחרים חדשים: הורדת סף/מהירות תריס.
ערוצים: גבולות נפרדים למסחר אלקטרוני (App2App/QR), POS, P2P, Request-to-Pay.
מהירות/סיכון: בנק אנטי-פראוד יכול להסיט בעדינות/להאט פעולות.

תקציר

עבור QR מקוון - in-app/App2App + דינמי לקמעונאי - TWINT QR, להעברות - P2P לטלפון.
אישור מקוון נפרד ואשראי סופי; לבנות סביב האינטרנט + סיור והחזר חלקי.
אל תתקן את הסכומים: שמור את ההגבלות על ידי בנק/ערוץ ועדכן באופן קבוע.
למנויים, צרור TWINT הראשון = כרטיס עם ניהול שקוף והודעות.