פיתוח אוטומציה של טרנזקציות דרך Safe{Wallet}

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

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1376
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1350
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    798
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1089
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1034
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1130

אוטומציה של עסקאות Safe: היכן נשבר התהליך הידני

כל עוד דרך Safe{Wallet} עוברות כמה פעולות בשבוע, אישור ידני של פעולות נראה בטוח: מהנדס אחד מרכיב חבילה, האחרים פותחים אותה בממשק, מאמתים כתובות וסכומים, ומחתימים.

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

הסוג הראשון של כשלים — אי-סנכרון. בין ההכנה לאישור הרכב החבילה משתנה, ואי אפשר לבטל חתימה שכבר ניתנה: החותם מאשר גרסה שכבר אינה עדכנית, והפעולה יוצאת לרשת בצורה שבה הורכבה לפני התיקונים.

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

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

מחיר התהליך ניתן למדידה: עיכוב בתשלומים נמדד בימים, שיעור החבילות שהורכבו מחדש גדל יחד עם מספרן, ואימות ידני אינו מתרחב בלי חותמים חדשים — כל משתתף נוסף מרחיב את שטח הפגיעות לשגיאה. להלן נבחן כיצד זה נסגר באמצעות אוטומציה של עסקאות Safe.

מה נותן ביצוע פעולות לפי כללים מוגדרים

הכלל מוגדר פעם אחת: מי יוזם את הפעולה, למי מותר לשלם, באילו גבולות סכום ובאיזה חלון זמן. לאחר מכן כל עסקה ב-Safe{Wallet} נבדקת מול המדיניות הזו לפני שליחה לחתימה — ואם היא נכנסת לגדר, אין עוד צורך בבעלים. אישור ידני נשאר רק למקרים חריגים: צד נגדי חדש, סכום מעל הגבול, שינוי המדיניות עצמה.

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

זה מסיר סוג שלם של שגיאות: תשלום כפול בגלל אישור מיותר, סכום שגוי בהזנה ידנית, שליחה לרשת הלא נכונה.

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

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

אפשרויות ביצוע פעולות והמגבלות שלהן

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

להלן ארבע אפשרויות שאנו מכניסים לאוטומציה של עסקאות Safe{Wallet}, עם המגבלות הכנות של כל אחת.

אפשרות מתי מתאימה מגבלות המצב
ביצוע באצווה תשלומים והעברות קבועים ברשימה אחת, כשחשוב החיסכון בעמלות והאטומיות: או שכל הסט עובר, או שכלום לא מגבלה על מספר הפעולות בסט אחד; כשל בתוך הרשימה מחזיר את כל הסט לאחור
ביצוע דחוי תשלומים לפי לוח זמנים עם חלון לביטול: הנהלת החשבונות מספיקה לבטל שורה שגויה נדרשים אחסון תור ומתזמן; כאשר צומת היוזם אינה זמינה, המועד נדחה
ביצוע לפי אירוע תגובה לאות חיצוני: הגיע אישור מהצד הנגדי, הסתיימה תקופה, הופעל סף יתרה תלות במקור האירוע; נדרשת הגנה מפני הפעלה חוזרת ומגבלות על התדירות
מצב חצי-ידני פעולות לא שגרתיות וגדולות, שבהן האוטומציה מכינה את הסט והאדם חותם המסלול האיטי ביותר; צוואר הבקבוק — זמינות החותמים וסף האישורים

מה לבדוק לפני הבחירה

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

הטמעת אוטומציה: שלבי העבודה ההנדסית

סדר העבודות בנוי כך שכל שינוי נבדק לפני הכנסתו למעגל הראשי. כל שלב נסגר בארטיפקט — תרשים תפקידים, תצורה או פרוטוקול בדיקה — ורק לאחר מכן מתחיל השלב הבא. עבור אוטומציה של עסקאות ב-Safe זה קריטי: כללי החתימות נוגעים ישירות בגישה לכספים.

  1. ביקורת תפקידים והרשאות. אוספים רשימה של בעלים, חותמים ומפעילים, את ההרשאות בפועל שלהם, את ספי ההפעלה ואת ההרשאות שנותרו מתצורות קודמות.
  2. תכנון תרשים החתימות. קובעים אילו פעולות עוברות לביצוע אוטומטי, אילו דורשות אישור של אדם וכמה חתימות מספיקות לכל סוג של פעולה.
  3. הגדרת כללים וספים. מקשרים מגבלות לסוגי פעולות ולכתובות מקבלים, קובעים תנאי הפעלה וסדר אסקלציה בעת חריגה.
  4. בדיקה במעגל ניסוי. מריצים תרחישים על עותק של הרשת: תשלום שגרתי, חריגה מהמגבלה, ביטול חתימה, אי-זמינות של אחד החותמים.
  5. מסירה להפעלה. מעבירים את התצורה הנבדקת, מקבעים אחראים, סדר שחזור גישה ונקודות בקרה.
  6. תקנון שינויים. מתארים כיצד מוסיפים חותמים ומשנים ספים: מי יוזם, מי מאשר, כיצד השינוי נבדק וכיצד הוא מוחזר לאחור.

שישה שלבים אורכים פרק זמן צפוי, ומכאן התמיכה מתנהלת לפי תקנון מקובע — בלי תיקונים «לפי טלפון» תוך עקיפת מעגל הניסוי.

מה נשאר אצלכם: תרשימים, מדיניות ותקנונים

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

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

את המסמכים מוסרים בפורמט ניתן לעריכה ועוברים עליהם עם הצוות שלכם — כדי שהתקנון לא יישאר קובץ שלא נקרא בתיקייה.

מקרה בוחן: תשלומים קבועים ללא אישורים ידניים

מה היה

אצל הלקוח — זרם קבוע של תשלומים שגרתיים: לקבלנים, לשותפים, חלוקה בתוך הצוות. כל תשלום עבר באותה שרשרת ידנית: בקשה, אימות פרטים, איסוף אישורים מבעלי הארנק, שליחה. תשלום אחד נמשך 1-3 ימי עבודה, בקשות שוכפלו בהתכתבות, ושגיאת הקלדה בכתובת התגלתה רק לאחר שהעסקה יצאה לרשת.

מה שינו

בצד Safe{Wallet} תיארנו כללים: לוחות זמנים לתשלומים, מגבלות לפי מקבל ותקופה, רשימות כתובות מורשות, שדות חובה בבקשה. המפעיל מרכיב את העסקה ללא זכות חתימה, והבעלים מאשרים מקבצים מוכנים — עם נימוק והיסטוריית תשלומים קודמים לאותו מקבל לנגד עיניהם.

מה נהיה

מדד לפני אחרי
פעולות המבוצעות לפי כללים הכול ידני 93%
זמן מהבקשה עד הביצוע 1-3 ימי עבודה דקות
בקשות שנעצרו על ידי המגבלה לפני שליחה לא הייתה בדיקה לפני חתימה יותר מ-10 ברבעון

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

מה לעשות אם הארנק כבר פרוס ופעיל

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

היתרות, ההיסטוריה והכתובת נשארות כשהיו, ורק ההיגיון משתנה: אילו העברות עוברות ללא אישור ידני ואילו עדיין דורשות איסוף חתימות.

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

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

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

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

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

ספקות בנושא אבטחה ותפקידים: בירור שאלות

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

את התפקידים מפרידים בחומרה: יוזם התשלום, החותם ומפעיל הניטור — חשבונות שונים, ובחתימה המרובה של Safe{Wallet} סף האישורים אינו מונמך למען נוחות האוטומציה. האוטומציה מרכיבה ושולחת את החבילה, אך זכות החתימה נשארת בידי אנשים — זה גבול שאיננו מטשטשים.

היכן נשמרים המפתחות של החותמים?

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

מה יקרה אם המבצע אינו זמין?

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

האם יש מגבלות על היקף הפעולות?

כן: ספים יומיים וחד-פעמיים לפי סכום ומספר עסקאות נקבעים בנפרד לכל ארנק. כל מה שמעל הסף דורש אישור נוסף — תקלה מקרית בסקריפט לא תהפוך לסדרת חיובים.

מי אחראי לפעולה מסוימת?

כל עסקה מתועדת ביומן: היוזם, החותמים, הזמן וסיבת ההפעלה. לפי היומן הזה משחזרים את התמונה המלאה, ולכן פעולה שנויה במחלוקת נבחנת לפי עובדות ולא לפי הנחות.

נדון במשימה: נבחן את תרשים החתימות שלכם

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

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

בסיום הבדיקה תקבלו הערכה ותוכנית: איזה חלק מהחתימות עובר לאוטומציה, אילו אישורים נשארים בידי האדם, אילו בדיקות מוצבות לפני השליחה. לכך — תיאור תרשים התפקידים ונקודות הבקרה, היקף העבודות וסדר הפריסה לפי שלבים. תארו את המשימה וצרפו את מה שיש מהרשימה — נחזור עם ניתוח והצעה.