אינטגרציה של MoonPay: רכישת קריפטו בכרטיס בתוך הארנק
רכישת קריפטו בכרטיס דרך MoonPay נראית כמו כפתור אחד: בחרת סכום, הזנת פרטי תשלום, קיבלת את הנכס ליתרה. בפנים — חישוב שער בהתחשב במגבלות אזוריות, אימות זהות, פנייה לבנק המנפיק, אישור הפעולה ורק אחר כך זיכוי.
השרשרת הזו נשברת לעיתים קרובות יותר ממה שנדמה: חלק מהניסיונות נחסמים על ידי הבנק, חלק אובדים בשלב האישור, וחלק מהמשתמשים נוטשים באמצע.
כל קטיעה כזו היא צוואר בקבוק של תהליך ההצטרפות, ולא תקלה קטנה בממשק. המשתמש כבר החליט לשלם, אך נשאר בלי נכס ביתרה, ולא כל משתמש ינסה שוב. שיעור התשלומים הכושלים מגביל ישירות כמה אנשים בכלל מגיעים לעבודה עם המוצר.
הסיבה היא בדרך כלל באינטגרציה, ולא בשירות החיצוני. אם סטטוס העסקה לא חוזר לאפליקציה, המשתמש רואה רכישה תקועה ולא מבין אם הכספים חויבו. אם ניסיון חוזר אינו מוגן מכפילויות, תשלום אחד הופך לשניים. אם ביטולים ופערי שער בין הבקשה לאישור אינם מטופלים, התמיכה עוסקת בפניות במקום לחשב הכנסות.
תרחיש נפרד — מעבר לפלטפורמה חיצונית. כאשר רכישה בתוך הארנק לא עובדת גם בניסיון השני, המשתמש הולך לבורסה וחוזר לאפליקציה כבר בלי צורך בה כנקודת כניסה.
נבחן היכן בדיוק עובר הגבול בין «לחצתי קנה» ל«נכס ביתרה», כיצד נסגרת השרשרת הזו ומה נשאר בשליטת הצוות.
מה נותנת רכישת קריפטו מובנית בכרטיס
רכישת קריפטו מובנית — זה כאשר המשתמש מקבל טוקנים ישירות בארנק או בתוך הפלטפורמה, בלי לעבור לאתר צד שלישי ובלי לפתוח חשבון בבורסה. הכרטיס, אימות הזהות והזיכוי מתרחשים בתרחיש אחד: האפליקציה פותחת חלון תשלום, ממתינה לאישור ומציגה יתרה מעודכנת.
ההשפעה נראית במשפך: עלייה בהמרה של תהליך ההצטרפות וירידה בשיעור התשלומים הנטושים. נעלם השלב היקר ביותר — המרה חיצונית והעברה ידנית לכתובת אחרת; המשתמש לא מאבד את הסשן, לא מתבלבל בין רשתות ורואה את סטטוס הפעולה ישירות בממשק.
מהירות העסקה הראשונה מתקצרת לדקות: בזמן שהבדיקה מתבצעת, האפליקציה כבר יודעת את מצב הפעולה ואינה מחייבת לרענן את העמוד ידנית. בנפרד נעלם סוג של כשלים בממשק שבין הארנק לפלטפורמה — כאשר התשלום עבר אך היתרה לא התעדכנה, או שההחזר לא מצא את הנמען.
MoonPay מכסה את החלק החיצוני: קליטת כרטיסים ואמצעי תשלום מקומיים, אימות משתמש, טיפול בסירובים ובהחזרים. בצד שלנו נשארת האינטגרציה בצד השרת, התראות על שינויי סטטוס וטיפול נכון באירועים חוזרים — ולכן הזיכוי ורישום הפעולה מתכנסים בלי התאמות ידניות.
בפועל זה אומר שהנתיב מ«רוצה לקנות» ועד העסקה הראשונה נכנס למסך אחד ואינו דורש התכתבות עם התמיכה.
מצבי חיבור: ווידג'ט, קריאה מהשרת, הפניה
מצב החיבור נבחר לא לפי טעמו של המפתח, אלא לפי היכן נמצא ממשק התשלום ומי אחראי למצב הפעולה. ווידג'ט הרכישה מוטמע ישירות בעמוד, קריאה מהשרת מעבירה את התרחיש לצד השרת, וההפניה מובילה את המשתמש לפלטפורמה של הספק — לכל אפשרות אזור שליטה משלה ומערכת מגבלות משלה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ווידג'ט רכישה | התשלום לא צריך להוציא מהעמוד: ארנק, מסך מנוי, כרטיס מוצר | העיצוב וסדר השלבים נקבעים על ידי הספק, חלק מהתרחישים סגורים; מעדכנים את הלוגיקה יחד עם הגרסה שלו |
| קריאה מהשרת | נדרשים כללים משלנו: מגבלות, מטבעות, ניסיונות חוזרים, אספקה לאחר תשלום | מצבים ושגיאות מטופלים על ידינו — נדרש מטפל בהתראות, הגנה מכפילויות ויומן ניסיונות |
| הפניה לפלטפורמה | השקה מהירה ומירב כיסוי של אמצעי תשלום במינימום קוד | המשתמש יוצא מהדומיין וחוזר דרך קישור, השליטה על המראה ועל שלבי הביניים אובדת |
בפועל משלבים בין המצבים: ווידג'ט כנתיב עיקרי, הפניה כחלופה כאשר התרחיש המובנה לא נטען או שאינו זמין באזור של המשתמש. לפני הבחירה אנחנו בודקים אילו אמצעי תשלום ומטבעות עובדים עבור המדינות הנדרשות, כיצד הפלטפורמה מאשרת את התשלום ומה קורה להזמנה אם החלון נסגר באמצע. זה מה שקובע את הגבול בין הלוגיקה שלנו ללוגיקה של הספק.
אינטגרציה של MoonPay: שלבי העבודה מהאודיט ועד המסירה
רכישת קריפטו בכרטיס נראית כמו ווידג'ט מובנה, אבל מאחוריה עומד קו תשלומים: הזמנה, הסטטוס שלה, התאמה מול הספק וטיפול בפעולות שלא הושלמו. אם הקו לא תוכנן, המשתמש רואה «התשלום לא עבר», ובמערכת החשבונאית נשארת הזמנה תלויה. לכן אנחנו מנהלים את האינטגרציה בשלבים — כל שלב מסתיים בארטיפקט שניתן לבדוק.
-
אודיט של זרימות תשלום. מנתחים כיצד נוצרות הזמנות באפליקציה ובארנק, היכן נשמר הסטטוס, מי מקור האמת, אילו מטבעות ומגבלות מעורבים. בפלט — מפת זרימות ונקודות שבהן מוטמעת הרכישה.
-
סכימת אינטראקציה. מקבעים תפקידים: הממשק, צד השרת שלנו, הספק. מתארים חתימת בקשות, בדיקת סכום ומטבע בצד השרת לפני יצירת הפעולה, אידמפוטנטיות לפי מפתח הזמנה — בקשה חוזרת לא יוצרת רכישה שנייה.
-
הגדרת תשלום והתראות. מגדירים את הווידג'ט, אמצעי התשלום הזמינים וכללי אימות הזהות בהתאם לתחומי השיפוט הנדרשים. אירועים מהספק מתקבלים בכתובת נפרדת עם בדיקת חתימה וניסיון חוזר במקרה של אי-מסירה.
-
בדיקת כשלים. מריצים תרחישים: סירוב מצד הבנק, ביטול באמצע, עיבוד ממושך, כפילות אירוע, פער בסכום. לכל אחד — כלל לשינוי סטטוס והודעה ברורה למשתמש.
-
התאמה ורישום. משווים פעולות לדוחות הספק, מסמנים פערים, מנהלים יומן בירורים.
-
נוהל תמיכה ומסירה. מתארים את פעולות הנציג במקרה של פעולה שלא הושלמה, לוחות זמנים להסלמה, מקומות לצפייה בלוגים; מוסרים תיעוד והרשאות.
סכימות החלפת נתונים, מדיניות גישה ונוהלים
לאחר המסירה נשאר לצוות הלקוח לא ארכיון קבצים אלא קו עבודה פעיל: עבור כל ארטיפקט רואים את הבעלים, את מועד העדכון ואת סדר הפעולות אם התנהגות המערכת סטתה מהתיאור. המערך שלהלן מכסה את רכישת הקריפטו בכרטיס במלואה — מנקודת הקריאה ועד התשובה למשתמש.
- מפת נקודות החיבור — כל המקומות באפליקציה ובארנק שבהם מופעלת הרכישה: מסכים, כפתורים, חזרות לאחר תשלום, הפרדה בין סביבת בדיקות לסביבת עבודה.
- סכימות החלפת נתונים — רצפי בקשות: יצירת פעולה, העברת כתובת הנמען, אישור תשלום, ביטול. מסומן אילו שדות מגיעים מצד MoonPay ואילו אנחנו יוצרים.
- תיאור סטטוסים של פעולות — רשימת מצבים ומעברים: נוצרה, ממתינה לאישור, בוצעה, נדחתה, הוחזרה. עבור כל אחד מצוין מה המשתמש רואה ולאן הסטטוס יכול לעבור הלאה.
- מדיניות גישה — אילו מפתחות וחשבונות נדרשים, מי הבעלים, באיזו תדירות מתבצעת רוטציה, אילו סביבות מופרדות. בנפרד — סדר הפעולות במקרה של חשיפת מפתח.
- טיפול בכשלים — אילו שגיאות סופיות, אילו דורשות ניסיון חוזר, כיצד נמנעת חיוב כפול וכיצד מתבצעת התאמה של פערים מול שירות התשלומים.
- הוראות לתמיכה — תרחישים של קו ראשון: כיצד למצוא פעולה לפי מזהה, מה להשיב כאשר תשלום תקוע, ומתי להסלים.
- נוהל עדכונים — כיצד מתקנים סכימות בעת פיתוחים נוספים, מי מאשר שינוי תרחיש, היכן נשמרת ההיסטוריה.
מקרה בוחן: רכישה בכרטיס בארנק בלי לאבד המרה
מה היה לפני העבודה
הארנק של הלקוח כבר קיבל תשלום בכרטיס, אך הטופס נפתח בחלון חיצוני: המשתמש עזב את הפלטפורמה ולא תמיד חזר, וסטטוס הפעולה נשאר לא ברור עד להתאמה ידנית. ההמרה של רכישה בכרטיס עמדה על כ-39% — כמעט שני שלישים מהתשלומים שהתחילו לא הגיעו לעסקה שהושלמה. יותר ממחצית מהפניות לתמיכה עסקו בכספים שחויבו אך לא זוכו.
מה שינינו
חיברנו את MoonPay כתרחיש רכישה מובנה: הטופס פועל ישירות בממשק הארנק, בלי מעבר לדומיין של צד שלישי. סטטוסי הפעולה — יצירת בקשה, אימות זהות, אישור הבנק, זיכוי — מגיעים כהתראות ומשתקפים מיד בהיסטוריה, ולכן המשתמש רואה באיזה שלב התהליך נמצא.
אמצעי התשלום והמגבלות מותאמים לפי מדינה ומטבע, וסירוב של הבנק מוביל למסך עם צעד הבא ברור, ולא למבוי סתום.
מה התוצאה
החיבור ארך שלושה שבועות, מאישור התרחישים ועד להשקה על חלק מהתעבורה. ההמרה של רכישה בכרטיס עלתה מ-39% ל-63%, וזמן המעבר בתרחיש התקצר משש דקות לשתיים. פניות על כספים שלא זוכו ירדו בערך פי ארבעה, ושיעור הרכישות החוזרות בחודש הראשון עלה מ-18% ל-27%.
מה לעשות אם רכישה בכרטיס כבר מיושמת ישירות?
חיבור ישיר של סליקה וספק חיצוני מכסים משימות שונות, ולכן הבחירה כאן היא לעיתים רחוקות «או-או». את הסליקה שלכם אתם כבר שולטים: כללי בדיקת המשלם, מגבלות, החזרים והתאמה מכוילים תחת מערכת החשבונאות שלכם. שירות חיצוני — למשל MoonPay — מוסיף אמצעי תשלום ואזורים שאי אפשר לכסות בסולק אחד.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| להשאיר חיבור ישיר | הכרטיס נותן את עיקר הנתח, ההתאמה וההחזרים כבר מכוילים | מערך מצומצם של שיטות ואזורים, כל אחד חדש — פיתוח נוסף |
| להשלים בנתיב שני | נדרשות שיטות חדשות, אבל אסור לאבד המרה | שני רישומים של פעולות: התאמה משותפת והגנה מפני זיכוי כפול |
| להחליף לחלוטין | הסליקה שלכם גוזלת תמיכה, והכיסוי לא גדל | בדיקה חוזרת של לקוחות, קיטוע ההיסטוריה, החזרים על תשלומים ישנים |
מעבר בלי השבתה נבנה על ניתוב: את נתיב התשלום בוחר צד השרת לפי כלל, ולא באופן קשיח בקוד. את הנתיב החדש מפעילים תחילה עבור חלק מהלקוחות החדשים, מתאימים סכומים וסטטוסים לפי מפתח הזמנה משותף, ואחר כך מרחיבים את הנתח. פעולות שלא הושלמו מושלמות בנתיב הקודם, ולכן אף תשלום לא נתקע באמצע.
הסיכונים של ההחלפה — בדיקה חוזרת של לקוחות שכבר אומתו, פערי סטטוס בין המערכות והחזרים על פעולות ישנות. לכן את הנתיב הקודם מכבים לא לפי תאריך אלא לפי מדד: כאשר ההתאמה מתכנסת, הוא נשאר פעיל רק עבור החזרים ותשלומים שנויים במחלוקת.
שאלות טכניות נפוצות בנוגע לחיבור
לפני השקת רכישת קריפטו בכרטיס נשארות לצוות אותן הספקות: מה עובר לצד של ספק התשלומים, מי אחראי לאימות הזהות, כיצד לטפל בהחזר והאם אפשר לסמוך על ההתראות הנכנסות. להלן — תשובות קצרות לכל סעיף.
אילו נתוני לקוח מועברים לספק?
לספק עוברים מזהה המשתמש, כתובת הארנק לזיכוי, סכום ומטבע הרכישה וטוקן סשן חתום. נתוני הכרטיס והמסמכים מוזנים בצד שלו ואינם מגיעים לתשתית שלנו — הם אינם נמצאים בלוגים של האפליקציה.
כיצד מתבצע אימות הזהות וממה תלויות המגבלות?
את הזהות מאמת הספק: עד נפח מסוים הפעולות עוברות בלעדיו, ומעבר לכך נדרשים מסמך ואישור. המגבלות תלויות במדינת הנפקת הכרטיס וברמת האימות, ולכן האפליקציה מבקשת את הערכים המעודכנים מראש ומציגה אותם לפני הזנת הסכום.
מה קורה במקרה של החזר ופעולה שנויה במחלוקת?
את ההחזר יוזם הספק. באפליקציה אנחנו מטפלים באירוע ההחזר, או מחייבים את הכספים שכבר זוכו, או חוסמים את המשיכה עד לסיום הבירור — אחרת היתרה תסטה מהחישובים בפועל.
כיצד לוודא שההתראה על התשלום אמיתית?
כל התראה על סטטוס הפעולה מגיעה עם חתימה שאנחנו בודקים לפי סוד משותף, ומתאימים סכום, מטבע ומספר הזמנה מול הרשומה במסד הנתונים. בקשה לא חתומה נדחית, וחזרה של אירוע אינה גורמת לזיכוי כפול.
בואו נדון במשימה: הערכה, תוכנית וסדר העבודה
אינטגרציה של MoonPay היא משימה עם תלויות חיצוניות: אימות זהות, מגבלות לפי אזורים ורשתות, התנהגות במקרה של כשל בפעולה. כדי שההערכה תהיה עניינית ולא «טווח לפי העין», נדרש סט נתוני בסיס לגבי המוצר שלכם.
חלק מהסעיפים מתוארים בדרך כלל כבר בתיעוד — ואז הדיון במשימה מתקיים בשיחת וידאו אחת במקום התכתבות של שבוע.
- תרחישי רכישה: תשלום בתוך האפליקציה, טעינת ארנק חיצוני, רכישה חוזרת והחזר כספים במקרה של דחיית הפעולה.
- רשתות ונכסים שצריכים להיות זמינים לרוכש, והעדיפות ביניהם.
- הפלטפורמה שלכם: ווב, אפליקציה לנייד, ארנקים נתמכים, אופן אימות המשתמש.
- דרישות לאימות זהות, מגבלות גיל ואזור — אותן קובע שירות התשלומים, והן מגדירות את סדר המסכים.
- עומס צפוי: מספר פעולות ביממה, תקופות שיא, שיעור הניסיונות החוזרים.
- הרשאות לסביבת בדיקות: מפתחות סביבת בדיקות, כרטיסי בדיקה, חשבון בפאנל השירות.
- האחראים על הקבלה מצדכם והקריטריונים שלפיהם אתם מחשיבים את החיבור כמושלם.
בתגובה תקבלו סכימה של זרימת הכספים, רשימת מסכים ומצבים, תוכנית חיבור לפי שלבים והערכת עומס העבודה. בנפרד אנחנו מקבעים את המוכנות לבדיקה: כיצד משחזרים תשלום מוצלח ותשלום שנדחה, מה נכנס ליומנים, וכיצד מבצעים חזרה לגרסה קודמת של השחרור.
תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית.