ארכיטקטורת הפלטפורמה

ליבה אחת, משטחים רבים — כך הפלטפורמה עובדת בפועל.

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

דברו איתנו לצפייה במוצרים

הליבה

לדג'ר אחד תחת הכול.

במרכז הפלטפורמה עומד לדג'ר חשבונות יחיד. כל חשבון — ארנק לקוח, יתרת סוחר, חשבון עמלות, חשבון סליקה — הוא צומת בלדג'ר הזה, וכל תנועת ערך היא רישום כפול: חשבון אחד מחויב, אחר מזוכה, ושני הצדדים תמיד שווים. הלדג'ר הוא append-only. רשומות לעולם לא נערכות ולא נמחקות; תיקון הוא רשומה חדשה הפוכה, ולכן תמיד אפשר לשחזר במלואה את ההיסטוריה שהביאה יתרה לערכה הנוכחי. חשבונות, מצב KYC, כרטיסים שהונפקו וכתובות קריפטו משויכים כולם לאותו מודל חשבון. לכן הרשאת כרטיס, העברה בנקאית והפקדה on-chain יכולות להירשם על יתרה אחת, בלי שכבת התאמות שמחברת בין מערכות נפרדות.

01רישום כפול: כל רישום מאוזן, חיובים שווים לזיכויים
02Append-only: תיקונים הם רשומות חדשות, לא עריכות
03מודל חשבון אחד לפיאט, כרטיסים וקריפטו
04מצב ה-KYC נע עם החשבון, לא בטבלת צד

תשלום, מקצה לקצה

תשלום אחד, מיצירה ועד התאמה.

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

01
יצירה
נפתח intent: סכום, מטבע, החשבונות המעורבים. עדיין שום דבר לא זז — הלדג'ר רושם רשומה ממתינה.
02
אישור
המסלול בודק יתרה וסיכון ומטיל חסימה. בכרטיס זו ההרשאה; בהעברה, החיוב נשמר בצד.
03
חיוב
הסכום החסום נקבע סופית. הלדג'ר רושם את הרישום הכפול שמזיז בפועל ערך בין שני החשבונות.
04
סליקה
הכספים מתגבשים על המסלול שמתחת — סכֶמת כרטיסים, בנק או chain — וחשבונות הסליקה מותאמים לכסף אמיתי.
05
התאמה
הפלטפורמה משווה את הרישומים שלה מול דוח הסליקה של המסלול; כל פער מסומן, לא מוסתר.

Webhooks ואידמפוטנטיות קיימים בכל קצה בזרימה הזו. המערכות שלכם לומדות שתשלום זז כשהן מקבלות אירוע, לא ב-polling, וכל בקשה שתשלחו שוב אחרי timeout נפתרת, באמצעות מפתח idempotency שלה, לאותה תוצאה, כך שחזרה לא תחייב פעמיים. השירות שמריץ authorize ו-capture הוא שער התשלומים.

שכבת האפליקציות

אפליקציות whitelabel למעלה, פלטפורמה אחת מתחת.

הליבה חושפת יכולות; שכבת האפליקציות הופכת אותן למוצרים. כל אפליקציה מול הלקוח — web ו-mobile — היא לקוח whitelabel שמציג את אותם חשבונות, תשלומים וכרטיסים דרך המותג שלו. העיצוב מונע על ידי טוקנים: צבעים, טיפוגרפיה, רדיוס ומרווחים מגיעים ממערכת design tokens (PDS), כך שמפעיל מחליף את מראה כל המשטח בשינוי טוקנים, בלי לעשות fork לאפליקציה. אותה פלטפורמה יכולה לפנות לכיוונים שונים מאוד — neobank צרכני, אפליקציית סליקה לסוחרים, תוכנית הנפקת כרטיסים, on/off-ramp לקריפטו או כלי תפעול פנימי — בלי להפוך לחמישה מוצרים נפרדים. זו פלטפורמה אחת בעורות שונים, שכל אחד מהם מוגדר ולא נבנה מחדש.

01לקוחות whitelabel ל-web ול-mobile על API משותפים
02עיצוב מבוסס טוקנים (PDS): משנים מראה בקונפיגורציה, לא ב-fork
03חמישה כיווני דוגמה — neobank, סליקה, הנפקה, ramp, תפעול
04משטחים חדשים מוגדרים, לא נבנים מחדש

תפעול

מנהלים הכול מהקונסולה, וסיבה תמיד נרשמת.

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

01קריאה רחבה, כתיבה מוגבלת — פעולות מורשות הן היוצא מן הכלל
02חובת ציון סיבה לפני כל פעולה שנוגעת בכספים
03נתיב audit בלתי ניתן לשינוי: מי, מה, מתי, למה
04הרשאה מינימלית לפי תפקיד מפעיל

גשר הקריפטו

קריפטו ופיאט על אותו לדג'ר.

הקריפטו אינו silo נפרד בפלטפורמה; כתובת קריפטו היא עוד חשבון בלדג'ר עצמו. On/off-ramp ממיר בין פיאט לנכסים דיגיטליים בקצה — לקוח מטעין יתרה בכרטיס או בהעברה ומקבל קריפטו, או מוכר קריפטו ומושך לחשבון בנק. ערך on-chain יכול להיסלק עד למסלול בנקאי: תשלום on-chain נכנס מזוכה לחשבון, מומר ומשולם ל-IBAN, וכך הנמען רואה כסף רגיל בחשבון בנק רגיל. מאחר ששני הצדדים נרשמים בלדג'ר אחד של רישום כפול, תנועה שמתחילה on-chain ומסתיימת בהעברה בנקאית היא היסטוריה אחת מותאמת, לא שתי מערכות שמתאימים ידנית.

01כתובת קריפטו היא חשבון כמו כל חשבון אחר
02On/off-ramp: המרה בין פיאט לנכסים דיגיטליים בקצה
03סליקה on-chain עד תשלום ל-IBAN
04היסטוריה אחת מותאמת על פני שני הצדדים

משטח הפיתוח

API, webhooks וסביבת sandbox לפיתוח.

כל מה שהאפליקציות עושות, הן עושות דרך API מתועד — יצירת חשבון, פתיחת תשלום, הנפקת כרטיס, הפעלת ramp. קריאות להמחשה נראות כמו POST /v1/wallets או POST /v1/payments; הממשק הוא REST עם idempotency key בכל כתיבה. שינויי מצב נמסרים כ-webhooks, כך שהמערכות שלכם מגיבות לאירועים במקום לבצע polling. הפיתוח נעשה מול tenant של sandbox — עותק מבודד של הפלטפורמה עם מסלולי בדיקה, שבו אפשר להריץ את הזרימה המלאה מיצירה ועד התאמה בלי להזיז כסף אמיתי. מה כל מוצר חושף לכם, ובאיזו דרגה, נקבע לפי רצועת הגישה שלו; דפי המוצרים מפרטים מה כוללת כל רצועה.

01REST API מתועד, כתיבות אידמפוטנטיות
02Webhooks לכל שינוי מצב — מונע אירועים, בלי polling
03Tenant של sandbox עם מסלולי בדיקה, מבודד מסביבת הפרודקשן
04היקף ומגבלות נקבעים לפי רצועות גישה לכל מוצר

הגבול, בלי עיגולי פינות

Protocore בונה את התוכנה. הרישיון מחזיק את הקו המוסדר.

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