Sofort/Klarna: תשלום על ידי בנק

1) מהו Sofort/Klarna Pay-by-Bank

Sofort (כיום Klarna Pay Now/Pay-by-Bank) הוא כלי A2A המאפשר לקונה לשלם עבור הזמנה ישירות מחשבון הבנק שלו באמצעות יישום מקוון של בנק/סלולרי. הזרם בנוי בדרך כלל על issuer-redirect/App2App אישור SCA (PSD2), והסוחר מקבל אישור מקוון (הצלחה) ולאחר מכן הלוואה בנקאית בהתבסס על הדו "חות/חישובים של הספק.

• עלות נמוכה יחסית ל-MDRs כרטיס.
• מצב מקוון (הצלחה/כישלון) כמעט מיד, בעוד זיכוי קרנות אינו תמיד מיידי (בדרך כלל T + 1/T + 2).
• גאוגרפיה רחבה באיחוד האירופי/EEA (גרמניה/אוסטריה חזקה במיוחד), תמיכה בעשרות בנקים.
• פרטי תשלום מינימלי מהקונה - בחירת בנק ואישור.

2) תפקידים ומשתתפים

Klarna/Sofort (תוכנית/ספקית): ניתוב לבנקים, סטטוסים, דיווחים, התנחלויות, חזרה.
בנק Issuer (payer's bank): SCA, אישור כתיבה, מגבלות/הונאה.
סוחר PSP/Acquirer: חיבור סוחר, API/SDK, קובצי אינטרנט וסיור.

סוחר - הפעל תשלום, תהליך סטטוס/החזר, התפייסות

3) תשלום זורם: הפניה חוזרת ו ־ App2App

3. 1 כיוון מחדש קלאסי

1. Checkout servant # בחר ”שלם לפי הבנק (Sofort/Klarna)”.
2. רשימת הבנקים * הפניה מחדש לבנק המקוון (או לדף המארח של הספק) * SCA.
3. הבנק מאשר את החזרת התשלום לסוחר עם המעמד (הצלחה/כישלון/ביטול/המתנה).
4. הזמנת רשומות הסוחר כ "בתשלום/תלוי ועומד", מחכה לדו "ח webhook/הרשמה.

3. 2 App2App/נייד

במכשירים ניידים, הסוחר פותח את היישום הבנקאי על ידי קישור עמוק/כוונות _ החזרה לפי התוכנית לעיל.
ההמרה גבוהה יותר, החיכוך נמוך יותר; שמור את הנפילה באינטרנט להפנות.

3. 3 אפשרויות בקשה לתשלום/שיבוץ

למספר בנקים יש בקשה לתשלום/PIS דרך ממשקי הספק (הקונה מקבל בקשה מבנק היישומים).
וידג 'טים משובצים מ-PSP מפשטים את רשימת הבנקים, השגיאות והסטטוסים.

4) גבולות והתנהגות של בנקים

• כל עסקה, ביום/שבוע בבנק של התשלום.
• מקבלים/סוחרים חדשים - סף מופחת, מהירות תריס אפשרית.
• ערוץ (נייד/אינטרנט), כללי מהירות, אותות גיאו/התקן.
• במדינות/בנקים בודדים, חריגות הסף של SCA (RA, TRA) אפשריות - תלוי בבנק.

5) אישור נגד הסדר

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

6 מחזירה, החזרות חלקיות ומחלוקות

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

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

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

8) פיוס ודיווח

שמור 'paymentid/transactionId' של הספק,' Id', הנפקת בנק, עיתוני זמן, סטטוסים.
אפשר פתקי אינטרנט על שינויי מצב וסיור אוטומטי יומי.
שילוב אירועים מקוונים (הצלחה/המתנה) עם דוחות כספיים (קרדיטים/החזרות/תיקונים).
אחסן את התייחסות UTR/בנק מהדו "ח עבור כל עסקה.

9) שיטות UX

ספרייה של בנקים: למלא מראש את הבחירה האחרונה, למיין על ידי פופולריות/התקן בנק.
נייד-ראשון: להציע App2App, גיבוי - הפניה באינטרנט.
שגיאות וחזרה: תן סיבות ברורות (גבול, כשל SCA, פסק זמן), כפתור חזרה וחלופות.
אידמפוטנטיות: " Id' + מפתח אידמפוטנטיות עבור חזרות בטוחות.
קבלה: סכום, תאריך/זמן, 'transactionId', בנק, ערוץ (App2App/Redirect).

10) מחיקה חוזרת ונשנית ומנדטים

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

11) ציות, ביטחון, נתונים

PSD2/SCA: אישור בבנק, התקן מחייב, בנק נגד הונאה.
מזעור PII: לאחסן רק את התכונות הדרושות; להצפין את PII; חתימות של קרסים ברשת.
GDPR/Logs: קונסולים, זכות למחוק, שינויים בביקורת.

12) Verticals סיכון גבוה (כולל iGaming)

הזמינות של Pay-by-Bank בקטגוריות מסוימות מוגבלת על ידי הספק/בנקים לפי מדיניות פנימית וחוק מקומי.
צפה להגבלות מופחתות, מעקב פיננסי נוסף, החזקות אפשריות.
שמרו על מעקות חלופיים (כרטיסים, SEPA, בנקאות פתוחה A2A, שוברים) וקטעי תנועה.

13) שילוב סוחרים: אפשרויות

1. מארח/משובץ PSP/Klarna

התחלה מהירה: וידג 'ט לבחירת בנק, סטטוסים, חרקים, חוברות אינטרנט מחוץ לקופסה.

2. שרת אל שרת + redirect/App2App

יותר שליטה: הדף הפרטי של הבנקים, עיבוד שגיאות בסדר, QR/Deep Link.

3. בקשה לתשלום

שליחת בקשת תשלום (דוא "ל/SMS/Link), נוחה B2B/services.

• ”תשלום”, ”מעמד”, ”החזר”, ”webhook”, ”ליישב”.
• אידמפוטנטיות ושולחן דדופי על ידי ' Id'.
• באופן אקספוננציאלי למדינאים, אות מתה לתגובות לא יציבות.
• קטלוגים: בנקים/מדינות, גבולות/קודי שגיאה, מדדי SLA על ידי שליחים.

14) ארכיטקטורת שער סופור/קלרנה

שכבת API (Rest/GraphQL) עבור הקופה.
תורים לאירוע: אירועי מצב * חיוב/CRM/אנליטיקה.
תצפית: המרת בנק/ערוץ, 'תלוי ועומד' הצלחה/פג תוקף, latency, כשל SCA.
אבטחה: כספת לסודות, ספק IP-Allowlist, אסימונים נגד שידור חוזר, אימות מחודש קפדני של אור-אר-איי.

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

1. בחר את ערוץ PSP/Klarna/Sofort עם גאוגרפיית הבנק הרצויה.
2. יישום ”CarePayment” + בחירת בנק + redirect/App2App עם גיבוי.
3. להתחבר לספרי אינטרנט, אידמפוטנטיות, פסקי זמן וחזרה על הסטטוס.
4. הגדרת איסוף מידע (יומי + מלא), אחסון הפניות UTR/fin.
5. אפשר החזר חלקי/מלא ו ־ ODR בתמיכה.
6. הכן תרחישי כשל/הגבלה של UX ושיטות חלופיות.
7. Test mobile banks (iOS/Android) והנפקות גדולות במדינות היעד.
8. שמור על מדריך מוגבל ודף מצב אירוע.

כרטיס ציון דרך

”הצלחה”, ”תלוי ועומד”, ”נכשל”, ”בוטל”, ”פג תוקף”.
יישוב: לרוב T + 1/T + 2; לתכנן ”ביצוע מותנה” לפני הקרדיט.
גבולות: per-txn/day/week at issuer 'a; למקבלים חדשים - למטה.
חזרה: באמצעות מנדט אלקטרוני/SEPA DD/Open Banking.

תקציר

להמרה - App2App/Embedded, ליציבות - פנקסי אינטרנט ברורים + סיור.
הפרד בין אישור מקוון לבין אשראי ממשי (T + 1/T + 2) בלוגיקה עסקית.
אל תתקן כמויות קשות: הגבלת הגדרות על ידי בנק/מדינה + עדכון רגיל.
עבור מנויים, השתמש במנדט התשלום הראשון של A2A, עם ניהול וגבולות ברורים של UX.