זיהוי עסקה, אישור שרשרת, קישור להזמנה ואספקת שירות הם שלבים נפרדים. אמתו את השרשרת, הנכס, הנמען והסכום הנכונים; הפעילו מדיניות קבלה מתועדת; והפכו את ההתאמה לאידמפוטנטית. אסמכתת עסקה, צילום מסך או כפתור בדפדפן לבדם אינם יכולים לקבוע שהזמנה מסוימת שולמה.
הפרידו בין אירוע השרשרת לאירוע ההזמנה
דיווח של ארנק שהעברה נשלחה הוא ראיה על הפעולה שלו עצמו, לא החלטת תשלום מלאה. ה-backend המקבל חייב לצפות ברשת המיועדת, לאמת את ההעברה בפועל ולקשר אותה להזמנה. רק אז ההזמנה יכולה להחיל את מדיניות הקבלה שלה. אספקת תשתית היא שלב תפעולי נוסף לאחר קבלת התשלום.
השאירו את המעברים האלה מפורשים גם בקוד וגם בשפה ללקוח. מסך יכול להציג ממתין, זוהה או מאשר בלי לקרוא להזמנה בתשלום. אל תתנו לדפדפן לספק את הסכום שהתקבל או לדרוס סטטוס סמכותי. שמרו את ההצעה שנוצרה בשרת ואת ההוראות שלה כדי שאפשר יהיה להעריך התאמה מאוחרת מול ההזמנה המקורית ולא מול עגלה משתנה.
השתמשו בכללי אמון ספציפיים לשרשרת
רשתות שונות מתארות אמון בעסקה באופן שונה. מדריך המפתחים של Bitcoin מסביר כיצד צמתים בוחרים את השרשרת עם מירב הוכחת העבודה המצטברת וכיצד בלוקים מתחרים יכולים להיווצר. עסקה שנראתה לאחרונה זקוקה אפוא למדיניות לעומק אישור ולשינויים אפשריים בשרשרת. אין מספר אישורים אחד שמתאים לכל נכס ולכל סיכון מסחרי.
התיעוד של Ethereum להוכחת החזקה מסביר סופיות של נקודת ביקורת, בעוד Solana מתעדת מצבי התחייבות של processed, confirmed ו-finalized. אל תתרגמו את המונחים האלה בקלות ראש למספר בלוקים אוניברסלי אחד. תעדו את הכלל הספציפי לרשת, מקור המידע וההתנהגות בזמן אי-ודאות. המפעיל צריך לקבוע ספי קבלה מול סיכון התשלום והאספקה, לא להעתיק מספר מתהליך תשלום לא קשור.
אמתו את מטען ההעברה בפועל
זהו את הנמען, הנכס והסכום בשרשרת הנכונה. תשלומי טוקן צריכים את זהות הטוקן המיועדת, לא רק עסקה מוצלחת לכתובת. אמתו הצלחת ביצוע וראיות העברה רלוונטיות לפי המודל של השרשרת. פרסרו סכומים שלמים בדיוק המתאים לנכס במקום לסמוך על עשרוני מעוצב שסופק על ידי הדפדפן.
הוראת תשלום חייבת להישאר קשורה למסלול המקורי שלה. העברה ברשת אחרת, טוקן שונה עם אותו סמל או אסמכתת עסקה לא קשורה לא אמורים לספק אותה. רשומת האימות צריכה להסביר מה נבדק ולשמר את הראיות הדרושות לבדיקת ההחלטה. מדריך זה מתאר עקרונות כלליים להתאמת תשלומים ולא מימוש של שירות מסוים.
הפכו את הקישור להזמנה לחד-משמעי
כתובות קבלה קבועות יכולות לקבל כמה הזמנות בסכומים דומים. קיומה של העברה תואמת אינו מוכיח איזה לקוח או איזו הזמנה צריכים לקבל זיכוי. הגדירו את שיטת הקישור לפני קבלת תשלומים חיים וכללו טיפול בהתנגשויות. אסמכתת עסקה שסופקה על ידי משתמש עדיין דורשת אימות שאותה העברה לא הוקצתה כבר במקום אחר.
תארו לעצמכם שתי חשבוניות באותו סכום באותו מסלול בחלון חופף. צופה רואה העברה אחת. סימון שתיהן כשולמו אוטומטית הוא שגוי; בחירה באחת בלי מספיק ראיות גם אינה בטוחה. השאירו את ההעברה לא מוקצית או בבדיקה עד שמדיניות המפעיל יכולה לקבוע קישור תקף. התאמה עמומה היא מצב שיש לטפל בו, לא סיבה להמציא ודאות.
הגדירו מצבים שסובלים ראיות מאוחרות ומשתנות
תהליך תשלום נהנה מקבוצה קטנה של מצבים ברורים, עם ראיות שרשרת נפרדות מההחלטה לקבל הזמנה. טבלה להמחשה זו מסבירה שלבים אפשריים ולא מתארת שמות סטטוס של שירות מסוים. לכל מעבר צריך להיות סיבה מאומתת, וקבלת תשלום צריכה להישאר נפרדת מאספקת תשתית.
כללו העברות מאוחרות, חלקיות ועודפות, תפוגת הצעה ונתוני שרשרת לא זמינים זמנית. תפוגה לא גורמת להעברה אמיתית להיעלם. תשלום מאוחר עשוי לדרוש בדיקה ולא קבלה או דחייה אוטומטיות. אם אירוע שרשרת שנצפה קודם משתנה, העריכו מחדש את המצב לפי המדיניות המתועדת במקום להתייחס לכל התראת צופה כאמת בלתי הפיכה.
| מצב להמחשה | משמעות | ההחלטה הבאה |
|---|---|---|
| ממתין | לא זוהתה העברה מתאימה מאומתת | המשיכו לצפות בחשבונית תקפה |
| זוהה | נצפתה העברה רלוונטית | בדקו אמון שרשרת וקישור |
| מאשר | כלל הקבלה טרם התקיים | צפו עד שהמדיניות תאפשר החלטה |
| בדיקה | ראיות מאוחרות, חלקיות או עמומות | פתרו לפי מדיניות המפעיל |
| התקבל | תשלום מאומת ומותאם | המשיכו לתהליך אספקה נפרד |
הפכו ניסיונות חוזרים לבטוחים ולניתנים לצפייה
צופים ומשימות התאמה ינסו שוב לאחר חיבורים שהופסקו או הפעלות מחדש של תהליכים. השתמשו בזהות העברה יציבה, כגון השרשרת ומזהה העסקה או ההעברה המתאים, כדי למנוע זיכויים כפולים. שמרו התקדמות והחלטות כך שאותו אירוע יוכל להיות מעובד שוב בלי להקצות שירות שני או לשנות הצעה שהתקבלה.
הבדילו בין תוצאה לא ידועה לפעולה שנכשלה. אם בקשה במורד הזרם מסתיימת בתפוגה, בדקו את התוצאה הסמכותית שלה לפני שליחה חוזרת. שמרו רשומות עמידות של פעולות שהתקבלו ושל פעולות לא ודאיות. הגבילו גישה לאסימוני הזמנה ולראיות פנימיות תוך שמירת מספיק מידע לחקירת תשלום שנוי במחלוקת. אמינות כאן עוסקת בהחלטות ניתנות לחזרה, לא באנימציה חלקה בתהליך התשלום.
דעו מה הזמנה ממתינה עדיין צריכה
הזמנה עשויה להישאר ממתינה מפני שההעברה לא נצפתה, רמת אמון השרשרת הנדרשת לא הושגה או שהקישור שלה לחשבונית דורש בדיקה. שמרו את החשבונית ואת אסמכתת העסקה הציבורית, בדקו את כללי הקבלה המוצהרים והשתמשו בתהליך העזרה המיועד של ההזמנה. עדכון סטטוס מתעכב אינו, כשלעצמו, סיבה לשלוח תשלום נוסף.
פעלו לפי ההוראות והסטטוס המאומת של ההזמנה בפועל. אישור תשלום צריך לזהות קבלה של ההעברה המותאמת, בעוד שלאספקת השירות יש סטטוס נפרד. הרחיקו אסימוני גישה פרטיים וסודות ארנק מבקשות עזרה.
רשימת הבדיקה המעשית שלך.
- שמרו הצעה בלתי ניתנת לשינוי שנוצרה בשרת.
- אמתו שרשרת, נמען, נכס וסכום שלם.
- תעדו כללי קבלה ספציפיים לשרשרת.
- טפלו בהתנגשויות בכתובת קבועה בלי לנחש.
- מנעו זיכויים כפולים ושליחות חוזרות לא בטוחות.
- בדקו מקרים של איחור, תשלום חלקי, מסלול שגוי וראיות שהשתנו.
הפרטים שחשובים.
האם hash של עסקה מספיק כדי לאשר תשלום?+
לא. אמתו את ההעברה בשרשרת המיועדת, את המטען שלה ואת רמת האמון, ואז קבעו שהיא שייכת להזמנה וטרם זוכתה.
האם כל רשת יכולה להשתמש באותו סף אישורים?+
לא. רשתות חושפות מודלים שונים של אמון וסופיות. המפעיל חייב להגדיר ולבדוק מדיניות קבלה מתאימה לכל מסלול.
האם תשלום מאושר אומר שהשרת הוקצה?+
לא. קבלת תשלום ואספקה הם אירועי תהליך נפרדים. תקשרו את מצב ההקצאה מהתהליך הסמכותי שלו עצמו.
לך למקור.
הפניות אלה תומכות במושגים הטכניים במדריך זה. עקוב אחר התיעוד העדכני לפני שינוי מערכת ייצור.
- מדריך מפתחים של Bitcoin: התנהגות בלוקצ'יין developer.bitcoin.org
- Ethereum: הוכחת החזקה וסופיות ethereum.org
- Solana: התחייבות מצב RPC solana.com
הדרכה עריכתית מאת SwissOctet. הדוגמאות להמחשה. יש לאמת בנפרד מפרטי שירות, אפשרויות זמינות ותנאים חוזיים.