חיבור Transak ל-dApp: on/off-ramp לשירות קריפטו

אינטגרציה של Transak: היכן נשבר תהליך ההפקדה והמשיכה

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

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

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

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

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

מה נותן חיבור שער תשלומים לשירות קריפטו

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

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

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

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

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

חיבור Transak: שלוש דרכים והמגבלות שלהן

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

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

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

סדר העבודה: מביקורת תרחישים ועד העברה לתמיכה

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

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

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

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

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

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

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

מה נשאר בפרויקט אחרי ההטמעה

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

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

מקרה בוחן: איך הקטנו את שיעור הפעולות שלא הושלמו

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

לפני: התאמה ידנית ו-40% מהפניות

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

אחרי: התאמה אוטומטית של סטטוסים

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

מדדים לפני ואחרי

שיעור הפעולות שלא הושלמו — מ-7.6% ל-1.2%, כאלה שהותאמו אוטומטית — 96% לעומת 71%, זמן טיפול בפנייה — מ-20 ל-3 דקות, מספר הפניות בהשתתפות אדם קטן פי ארבעה. פערים בהתאמה ירדו מ-1.8% ל-0.4%, והתור של טיפולים ידניים הפסיק לגדול יחד עם המחזור.

במה שונה הפקדה ממשיכה ומה להגדיר קודם

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

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

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

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

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

ספקות טכניים לפני חיבור השער

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

איך להנפיק גישה למפתחות?

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

העסקה נתקעה בסטטוס ביניים — מה הלאה?

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

מה יקרה כאשר הספק לא זמין?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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

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