שוודיה סוויש: תשלומים ניידים

1) מהו סוויש

Swish היא מערכת התשלומים הלאומית של A2A עם 24/7 העברות מיידיות. המשתמש מאשר עסקאות באמצעות BANKID (SCA). תרחישי P2P (לכל טלפון), P2M עסקי (מקוון ולא מקוון), תרומות ותשלומים נתמכים.

• פונה באמצעות מספר טלפון (או מספר סוחר/QR), ללא IBAN ב- UX.
• אשראי מיידי לחשבון הבנק של הנמען; סופית של העברה בנקאית.
• חיכוך נמוך: App2App/QR, אישור ב-BANCID.
• כיסוי בנק רחב ופופולריות גבוהה בקמעונאות/באינטרנט.

2) תפקידים ומוצרים

חוקים, קטלוגים ומותג.
השתתפות בנקים - הנפקה/חיבור סוויש, ליישם גבולות ואנטי הונאה.
PSP/רוכשים - סוחרים מחוברים (Swish Handel/Swish Företag), מספקים API/SDK, דיווחים, הסדר.

• העברות בין אנשים.
• Swish Företag - לקבל תשלומים לא מקוונים (תצוגה/POS).
• Swish Handel (Swish for e-commerce) - קופה מקוונת (QR/App2App/Link).
• תרומות סוויש - מספרים קצרים/כינויים לתרומות.
• Swish Payouts/Disbursements - תשלום המוני (באמצעות בנק/PSP).

3) זרימות תשלום

3. 1 P2P (דחיפה)

1. השולח בוחר את הקשר הטלפוני * נכנס לכמות/הודעה.
2. מאשר ב-BANKID (פנים/מגע/קוד).
3. המקבל מיד רואה את האשראי בחשבון ואת ההודעה באפליקציה.

3. 2 P2M: מסחר אלקטרוני (סוויש הנדל)

• App2App/Deeplink: בבדיקה, פתח את הבקשה Swish/BANKID = אישור = חזרה לסוחר.
• QR לפי סדר: נוצר QR דינמי (סכום, ID, התייחסות לסוחר); הלקוח סורק עם מצלמה Swish = מאשר עם BANKID.

3. 3 POS/offline (Företag)

QR דינמי בקופה או מספר סוויש סטטי (כמות ידנית).
אישור ב-BANKID; תבדוק אצל הסוחר ובבקשה של הלקוח.

3. 4 בקשות לראו/חשבוניות

הסוחר שולח קישור תשלום/בקשה (בדוא "ל/SMS/שליח); הלקוח מאשר ב-BANKID.

3. 5 תשלומים

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

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

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

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

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

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

העלות עבור הסוחר היא בדרך כלל נמוכה יותר מאשר הכרטיס הקלאסי MDR, אבל התנאים תלויים בבנק/PSP (תיקון/ריבית נמוכה, עמלה עבור QR/SDK/דיווחים).
תשלום עבור תמיכה 'ממתינה/פג תוקף', סכסוכים, איסוף מידע וניטור SLA.

7 מחזירה ומחלוקות (ODR)

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

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

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

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

אפשרויות

1. מארחת/משובצת על ידי PSP - התחלה מהירה, App2App/QR מחוץ לקופסה, סטטוסים וחרקים.
2. שרת אל שרת + App2App/QR - יליד UX, QR דינמי לפי סדר, שגיאה עמוקה/עיבוד חזרה.
3. Pay-by-Link/Invoice - שליחת קישור/בקשה; נוח עבור שירותים ו B2B.

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

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

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

11) תבניות UX

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

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

סוויש בסיסי - חד פעמי עם SCA. עבור המנויים נעשה שימוש בצרור: התשלום הראשון Swish # e-mandate/Autogiro/Open-Banking PIS עבור חיובים נוספים (הגבלה/תדירות/הודעות, מסך ניהול כרטיסים).

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

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

14) אדריכלות ”שער סוויש”

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

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

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

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

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

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

המשך תקציר

עבור QR מקוון - App2App + דינמי, עבור QR/POS לא מקוון (Företag), עבור העברות - P2P לטלפון.
אימות מקוון נפרד ואשראי סופי בלוגיקה עסקית; לבנות סביב האינטרנט + סיור והחזר חלקי.
אין לתקן סכומים: לשמור על הגדרות גבול על ידי בנקים/ערוצים עם עדכון רגיל.
למנויים, החבילה הראשונה Swish = כרטיס עם ניהול שקוף והודעות.