PAYD אוסטרליה: NPP זורם

1) הקשר: NPP ו ־ PAYD

תשתית התשלומים המיידיים הלאומית של אוסטרליה (24/7/365) עם יישובים בזמן אמת והודעה עשירה של ISO 20022. PAYD היא שכבת פנייה על גבי NPP, המאפשרת לך לשלם לא באמצעות BSB/Account, אלא באמצעות כינוי "אנושי": מספר טלפון, דוא "ל, ABN/ACN או זיהוי ארגון.

• כל משתתפי NPP ↔ כל בנקים שמנפיקים.
• שם בדוי: המשלם רואה את שם ה-PAYD לפני אישור (אנטי-הטעיה).
• מיידי וסופי: אשראי על חשבון הסוחר מוצג באופן מיידי; חזרה - פעולה נפרדת.
• נתוני תשלום: ISO 20022 עם הפוגה נוחה (מטרת התשלום, ID וכו ').

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

ניתוב ושרטוט NPP/Schema

אימות לקוח, אנטי הונאה, שליחת הודעה.
בנק/רוכש (PAYEE FI): קבלת הלוואות, הודעות, דיווח.
PSP/fintech: יישומים בקו החזית, SDKs, דיווחים ופיוס לסוחרים.
סוחר: מחזיק PAYD (או פרטי בנק), יוצר בקשה/קישור למשלם.

3) תעודות זהות

סוגים של PAYD: נייד, דוא "ל, ABN/ACN, זיהוי ארגון.

• כל PAYD משויך לשם PAYD שהמשלם רואה לפני שהוא מאשר.
• חשבון יחיד יכול להיות מספר רב של PAYD; ניידות חוצה בנק נתמכת על ידי הליכי הגירה.
• ABN/ACN-PayID נוחים לעסקים: קל יותר להתאים את פרופיל החברה.

4) זרימות תשלום בסיסיות (NPP/PAYID)

P2P (דחיפה): המשלם נכנס/סורק את PAYID של PAYE * רואה את שם PAYD * מאשש את האשראי של payID * באופן מיידי.

P2M (דחיפה): הסוחר מפרסם PAYD או מוציא עמוקות/QR

בקשה לתשלום (גוביינא): סוחר יוזם בקשה לתשלום; המשתמש מאשר ביישום הבנקאי.

• עבור מסחר אלקטרוני, השתמש ברינק/QR עם כמות קבועה ו- ID.
• עבור לא מקוון, PAYD סטטי מקובל, אבל QR דינמי לפי סדר הוא טוב יותר.

5) תשלום: אי-מנדטים וחברות אוטומטיות

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

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

6) מגבלות ובקרת סיכונים

• פר-עסקה/פר-יום: סף בנק עבור NPP/PAYID עשוי להשתנות.
• מקבלים חדשים: צמצום מגבלות התחלה ו/או מהירות תריס הם לעתים קרובות בתוקף.
• מדיניות קטגורית: MCC/verticals בודדים עשויים להדק.
• כרטיסי PayTO: גבולות נקבעים בכרטיס עצמו (כמות, תקופה, מחיקה מקסימלית).

• אל תהיו קשוחים - שמרו על ההגבלה ועדכנו באופן קבוע.
• בממשק, להזהיר על עודף אפשרי ולהציע פיצול בדיקות, אם אפשר.

7) UX ואבטחה

אישור של אימות דמוי Payee: הצגת שם PAYD מפחיתה את הסיכון של שגיאת הנמען.
2FA והתקן המחייב בבנק של התשלום בעת אישור.
אנטי-פראוד/מהירות: לבנקים יש חוקים משלהם; שקול כישלונות ”רכים” אפשריים.
שקיפות: בדוק עם אנשי קשר תומכי UTR/time/כמות/מטרה +.
אם קישור עמוק לא נפתח, להציע PAYD העתק, QR סטטי והוראות.

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

אין צ 'רג' רס במובן הכרטיס. ההחזר הוא עסקת אשראי חדשה מהסוחר למשלם, עם התייחסות ל-UTR/LookID המקורי.
תמכו בהחזרים חלקיים וביכולת איתור מלאה בדוחות.
מחלוקות נפתרות באמצעות בנקים/פ.ס.פ. ותקנות תמיכה; LAY SLA ואוסף ראיות (יומן הזמנות, משלוח, התכתבות).

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

1. תשלום סטטי מזהה

תתחיל מהר, פיתוח מינימלי.
סיכונים: גורם אנושי (הזנת כמות/הערה), אנליטיקה חלשה יותר.

2. QR/לינק דינמי

דור לסדר: סכום קבוע, ID, הפוגה.
סיור טוב יותר לפי סדר, פחות שגיאות, המרה גבוהה יותר.

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

”החשבונית” מהסוחר * אישור מהמשלם.
שימושי עבור חשבוניות, B2B, ושירותי כמות משתנה.

4. PayTO (אי-מנדטים)

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

• Web wooks of status (הצלחה/כישלון/תלוי ועומד), סקרים חוזרים ונשנים על ידי גיבוי.
• טבלת אידמפוטנטיות ( ID + שאילתה).
• פיוס על ידי UTR/LookID/זמן/כמות.
• החזר פיצויים ונהלי ODR.
• ניטור בנק/PSP SLA (ניטור, הצלחה, קודי שגיאה).

10) פיוס ודיווח (ISO 20022, UTR)

UTR (זיהוי העברה ייחודי) - מפתח פיוס ראשי; שמור גם את התשלום המקורי וגם את ההחזר.
השתמש ב ־ ISO 20022 tassage/remitance fields עבור ID, cart, Ref.
הגדרת סיור אוטומטי יומי וסיור מלא תקופתי.
דוחות PSP: עסקאות, סטטוסים, כרטיסי PayTO, החזרות, סטיות.

11) תעריפים ועלויות

עבור NPP/PAYID אין MDR קלאסי כמו בתרשימי קלפים, עם זאת, ישנם דמי הספק לרכישה, מודולי PayTO, דיווח, חבילות SLA.
קחו בחשבון את העלויות של תמיכה/סכסוכים, אנטי-הונאה, דור QR ומארח עמודים עמוקים.

12) אפשרויות מנותקות ו ־ QR

Merchant-הציג QR (דינמיקה): אופטימלי עבור POS/checkout; כמות ומטא-נתונים מוגנים לקוד.
QR סטטי: מקודד PayID ללא סכום; הזן את הסכום ידנית.
הדפסה-על-לבדוק/על הצלחת: מותר לעסקים קטנים, אבל גרוע יותר לפיוס.

13) ציות, AML/CTF וסודיות

ציית ל ־ AML/CTF (AustrAC), אחסון רישומי כרטיסים, רמות KYC ב ־ PSP.
הפעלת סנקציה/הונאה ברמת PSP, כללי מהירות, ניטור אנומליה.
Process PayID Data על פי עקרונות המזעור; הצג רק מה שנדרש עבור UX וביקורת.

14) תכונות בסיכון גבוה (כולל iGaming)

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

15) ארכיטקטורת שירות שער NPP/PAYID

API: 'כוונת ', ' QR', ' ToPay', 'PaytoMandate', 'החזר', 'להתפייס', 'webhook'.
אמינות: מגש אקספוננציאלי, אידמפוטנטיות, שכפול אירועים.
תצפיות: Metrics (הצלחה/כשלים/latency), עקבות, התראות על בנקי SLA.
אבטחה: חתימת HMAC של ווים ברשת, IP של רשימת-כל, סיבוב של סודות, יומן ביקורת.
נתונים: ספריות בודדות של הגבלות על ידי בנקים/ערוצים, מדדי מנדט PayTO, כרטיס UTR.

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

1. קבל סוחר PAYD (או בריכת PAYD) מבנק/PSP.
2. בחר זרם: QR/link דינמי, Request-to-Pay ו/או PayTO.
3. יישום ווים באינטרנט, אידמפוטנטיות ושולחן כרטיסים.
4. אפשר סיור מונחה UTR (יומי + מלא), התראות על ידי יישור שגוי.
5. הפעל זרימת החזר (מלא/חלקי), רישומי ODR.
6. הוספת מסכי הגבלת UX, תצוגה מקדימה בשם PAYD, שגיאות מובנות.
7. להגדיר מעקב SLA ולוחות מחוונים ספק.
8. ביצוע בדיקות מקצה לקצה עם בנקים שונים הנפקה ותרחישים PayTO.

המשך תקציר

לתשלומים חד-פעמיים, הימור על QR/קישור עמוק דינמי עם metadata עשיר.
עבור מנויים ותשלומים חוזרים, השתמש בכרטיסי PayTO עם ניהול UX שקוף.
אל תגביל קוד קשיח: שמור על הגדרות בנק/PSP ועדכון.
לבנות תהליך סביב פיוס UTR, רישום מפורט והתראה על ידי SLA.