אנו משתמשים ב-Google Analytics לסטטיסטיקות תנועה. קובצי Cookie לאנליטיקה יופעלו רק אם תאשרו. ללא הסכמה, הסטטיסטיקות מוערכות מאותות ללא קובצי Cookie. מדיניות קובצי Cookie.
Gateway · תשלומים
דוגמה אחת עוברת לאורך כל העמוד — Arc Studio SRL, הזמנה 9F21-0716, €49.00. הלקוח בוחר כרטיס, Apple Pay, Google Pay, USDC או העברה בנקאית, וצד בית העסק זהה בכל מקרה: אסמכתה אחת, קבלה אחת, סכום אחד באירו.
הבטחות
פיצול אמצעי התשלום הוא הבעיה של בית העסק, והוא רק מחמיר: מעבד כרטיסים עם דשבורד משלו, SDK של ארנק עם מחזור גרסאות משלו, אפשרות קריפטו שחיה בעמוד אחר ולא מתיישבת מול שום דבר. כל אמצעי שמתווסף הוא עוד אינטגרציה, עוד סט דוחות, עוד מקום שבו תשלום יכול ללכת לאיבוד. Gateway מכווץ את כל זה לעמוד אחד ולרשומה אחת.
אותו checkout במובייל — כרטיסים, ארנקים ו-USDC בעמוד אחד. · הקבלה — 52.95 USDC נכנסו, €49.00 נסלקו, בבהירות.
כרטיסים, Apple Pay, Google Pay, USDC, העברה בנקאית ואמצעי התשלום המקומיים שהקונים שלכם מצפים להם נמצאים באותו עמוד מאוחסן, בסדר שנקבע לפי מה שהלקוח שמולו צפוי להשתמש בו. העמוד מתאים את עצמו לדסקטופ, לטלפון ולאפליקציה; הוספת אמצעי תשלום חדש היא מתג, לא פרויקט.
ה-back office של הקישורים — כל קישור עם הסטטוס שלו, €2,304.50 נגבו החודש.
USDC מתומחר בשער שמוצג בעמוד לפני שהלקוח מאשר, נסלק לאירו ונכנס לאותה העברת תשלומים כמו הכרטיסים. אתם לא מחזיקים פוזיציית טוקן, לא פותחים פונקציית טרזורי, ורואה החשבון שלכם לא רואה מטבע שני. הקבלה מציינת את ההמרה בשורה אחת — הלקוח שילם בקריפטו; הספרים אומרים €49.00.
החזר בתהליך — מול ההזמנה, סיבה חובה, חוזר באותו מסלול מקורי.
הכול תלוי בהזמנה ולא באמצעי התשלום. הזמנה 9F21-0716 נושאת את פריטי השורה שלה, עמלת עיבוד של €0.50, סכום כולל, תוצאת הרשאה, קבלה והחזרים. בגלל זה התאמה היא חיפוש, מחלוקת היא מסך אחד, והחזר מצביע על הזמנה ולא על כרטיס, ארנק או רשת.
מיתוג ה-checkout — לוגו, צבעים, גופן ופינות, בתצוגה מקדימה חיה לפני השמירה.
הכרטיסים נשמרים בכספת אצלנו ומופנים באמצעות טוקן, כך שלקוח חוזר משלם בנגיעה והמערכות שלכם שומרות הפניה ולא מספר כרטיס. מנויים רצים לפי הלוח שתגדירו מול הטוקן, מנסים שוב לבד soft declines, ועוקבים אחרי בעל הכרטיס גם אחרי הנפקה מחדש — וכל מחזור יוצר הזמנה וקבלה משלו.
הגדרת אמצעי תשלום — מתג לכל אמצעי בכל checkout, עם סליקה וניתוב לצידם.
תנועת כרטיסים עוברת לפי מדיניות ניתוב הכתובה במונחים מוכרים, מנסה שוב soft decline במסלול חלופי לפני שהלקוח רואה כשל, ועוברת ל-3-D Secure כשהמדיניות דורשת זאת ולא כברירת מחדל. כשתשלום באמת נדחה, הסיבה מגיעה בשפה שמפעיל יכול לפעול לפיה ולא כקוד גולמי של המנפיק.
מעלים לוגו, קובעים צבעים, גופן ופינות, ורואים תצוגה מקדימה של ה-checkout האמיתי לפני השמירה. מריצים אותו בדומיין שלנו, בדומיין שלכם או בתוך האפליקציה שלכם — עם footer של powered-by או כ-whitelabel מלא. ה-checkout בהדגמה שייך ל-Arc Studio SRL, וזה נראה כמו שלהם.
שיטות
כל שיטה שה-checkout מציג, התשתית שמאחוריה והמטבע שבו הכסף נוחת. העמודה האחרונה היא העיקר: לא משנה מה הלקוח בוחר, התשלום לסוחר הוא סכום אחד ביורו.
אינטגרציה
יוצרים הזמנה עם מפתח אידמפוטנטיות, מפנים ל-checkout המתארח וקולטים תוצאה חתומה. כל האינטגרציה היא קומץ endpoints ו-webhook אחד.
בלי אינטגרציה בכלל — יוצרים קישור במשרד האחורי, חד-פעמי או רב-פעמי, ושולחים. התשלומים נוחתים באותו מקום כמו תשלומי ה-API.
iOS ו-Android מציגים את אותו checkout באופן נטיבי, והלקוח נשאר באפליקציה שלכם גם במסכי הארנק וב-3-D Secure.
מחברים חנות קיימת בלי מפתח: מתקינים, מדביקים את המפתחות ומבצעים תשלום בדיקה עם כרטיס sandbox.
שומרים על העיצוב שלכם ומטמיעים את שדות התשלום. הם נשארים מתארחים ובתחום PCI אצלנו, כך שפרטי הכרטיס עדיין לא נוגעים בשרתים שלכם.
אינטגרציה
ה-backend שלכם יוצר הזמנה דרך ה-API: סכום, מטבע, ההפניה שלכם.
הלקוח בוחר כרטיס, ארנק או USDC בעמוד המתארח.
הכספים מאומתים ומוחזקים; 3-D Secure נכנס לתמונה רק כשהמדיניות דורשת.
החיוב הושלם ונכנס לתור הסליקה.
webhook חתום מסוג order.paid מגיע; מאמתים את החתימה ומספקים.
הזמנות היום נאספות באצווה ומשולמות ב-EUR — הפניה אחת מה-checkout ועד שורת הבנק.
יכולות
ה-checkout המתארח מציג כרטיסים, Apple Pay, Google Pay ו-USDC זה לצד זה. הזמנה 9F21-0716 משמאל — שלושה פריטים, עמלת עיבוד של €0.50, €49.00 לתשלום — ובחירת השיטה מימין. הלקוח בוחר; הדף מסתגל; הסוחר שילב פעם אחת.
אותו URL של checkout מסתדר מחדש לפריסת טלפון: ההזמנה מתקפלת לשורת סיכום, כפתורי השיטות נשארים במקומם, וטופס הכרטיס שומר על התוויות שלו. מה שעולה בדסקטופ עולה גם במובייל — וכשרוצים שהתשלום יתבצע בתוך האפליקציה שלכם ולא בדפדפן, ה-SDK של iOS ו-Android מציגים את אותו checkout באופן native מול אותה הזמנה.
תשלום ב-USDC מסתיים בקבלה שרואה החשבון של הסוחר יכול לקרוא. שיטה: 52.95 USDC ב-Base →︎ סליקה ב-EUR, לפי השער שמודפס על הקבלה, 1 EUR = 1.0807 USDC. אסמכתה 9F21-0716, נשלחת ללקוח במייל וניתנת להורדה במקום. הלקוח שילם בקריפטו; הספרים אומרים €49.00.
ללינקי תשלום יש שולחן עבודה אמיתי: 8 לינקים של Arc Studio SRL בסטטוסים שולם, פעיל ופג תוקף, עם סכום, מספר תשלומים וסטטוס בכל שורה. הכרטיסים למעלה מנהלים את התוצאה — 4 לינקים פעילים, €2,304.50 שנגבו החודש מ-18 תשלומי לינק, €49.00 ששולמו היום. יוצרים, מחפשים, מייצאים, וזהו.
החזר מצביע על ההזמנה, לא על שיטת תשלום. המגירה נפתחת על 9F21-0716 עם הסכום המלא של €49.00 כברירת מחדל, סיבה חובה והערה אופציונלית שמגיעה לייצואים ולקבלת הלקוח. הכסף חוזר אוטומטית באותו מסלול תשלום מקורי — החזרי כרטיס לכרטיס, הזמנות USDC כסליקת ה-EUR שלהן — בדרך כלל תוך 1–3 ימי עסקים.
מיתוג הוא עמוד הגדרות, לא פרויקט שירותים: מעלים לוגו, קובעים צבעי הדגשה, טקסט ורקע, ובוחרים גופן וסגנון פינות. התצוגה המקדימה החיה מציגה את ה-checkout האמיתי שלכם — בדסקטופ או במובייל — לפני השמירה, וצבע ההדגשה קובע את מיקוד כפתור התשלום, סימוני הסטטוס והטאב הפעיל. אפשר להריץ אותו על ה-host שמונפק עם ה-sandbox שלכם, או על הדומיין שלכם.
שיטות תשלום הן מתגים עם ספקים מאחוריהם: כרטיסים עם 3-D Secure, Apple Pay ו-Google Pay ככפתורי ארנק, USDC ברשתות Ethereum, Base ו-Solana, והעברה בנקאית SEPA לפי אסמכתת vIBAN. לצידם, פאנל הסליקה מציג את העסקה בפשטות: הלקוחות רואים את ההמרה לפני האישור; אתם תמיד נסלקים ב-EUR.
יוצרים הזמנה, מפנים לעמוד המתארח, מקבלים את התוצאה. Gateway מספק את ממשק התשלום, את לוגיקת השיטות ואת הקבלות. אין frontend של checkout שהצוות שלכם צריך לבנות, לתקן או לעדכן בכל פעם שהשיטות משתנות.
הכול תלוי בהזמנה, לא בשיטת התשלום. הזמנה 9F21-0716 נושאת את הפריטים שלה — ספרינט זהות מותג ב-€38.50, רישוי גופנים ב-€6.00, משלוח מהיר ב-€4.00 — עמלת עיבוד של €0.50 וסכום כולל אחד. לא משנה איך משלמים, האסמכתה הזו היא מה ששולפים, מתאימים ומחזירים מולו.
שינויים בשיטות ובמיתוג חלים על sessions חדשים של checkout — וזה כתוב במסך שבו שומרים אותם. לקוח באמצע תשלום לא רואה את הדף משתנה מתחת לידיים.
מסלול הכרטיס הוא החלק המשעמם, והוא מטופל: ולידציה בשדה, 3-D Secure עם אימות לקוח חזק מובנה בתהליך תחת מדיניות ניתוב קריאה, וכרטיסי בדיקה לכל sandbox להרצות אינטגרציה. קבלת קריפטו אף פעם לא פוגעת בתהליך הכרטיס.
הארנקים הם כפתורים, לא פרויקטים. Apple Pay ו-Google Pay מוצגים כגיליון בנגיעה אחת באותו עמוד ומשלמים באמצעות טוקנים של המכשיר — מספר הכרטיס האמיתי לעולם לא מגיע לדף — דרך אותה הזמנה ואותה קבלה. הפעלתם היא מתג במסך השיטות.
קריפטו מתומחר לפי שער שמוצג ב-checkout ונסלק ליורו. הסוחר לא מוצא את עצמו מחזיק פוזיציית טוקן בטעות; הספרים נשארים במטבע אחד.
שיטת USDC פרוסה על Ethereum, Base ו-Solana מאחורי מתג אחד. הלקוח משלם ברשת שבה נמצא הארנק שלו; הצד של הסוחר לא משתנה.
תשלום בהעברה נושא אסמכתת vIBAN, כך שתשלום SEPA נכנס מזהה את ההזמנה שלו מעצם התכנון. מפעילים אותו ללקוחות שרוצים חשבונית שאפשר לשלם מהבנק, וההתאמות נשארות אוטומטיות.
מעבר לכרטיסים וארנקים, ה-checkout כולל את שיטות ה-account-to-account והשיטות המקומיות שקונה אירופי מצפה לראות, ומוצגות לפי מדינת הלקוח ולא נזרקות לרשימה ארוכה אחת.
BNPL נמצא באותה שורת שיטות כמו כל השאר — הלקוח מפצל את התשלום, הסוחר מקבל תשלום פעם אחת, ואסמכתת ההזמנה לא משתנה. מתג אחד, אותה קבלה, אותה התאמה.
הדף מסדר את השיטות לפי מה שהלקוח צפוי להשתמש בו — מדינה, שפה, מכשיר, והאם כבר שילם לכם בעבר — כך שהאפשרות הרלוונטית היא הראשונה, לא הרביעית.
מציגים את הסכום במטבע הלקוח עם ההמרה מוצהרת לפני האישור, ונסלקים ל-EUR בכל מקרה. הלקוח רואה מספר מוכר; ה-ledger שלכם שומר מספר אחד.
העמוד המתארח מתאים לשפה את התוויות, השגיאות והקבלות. אף אחד לא נוטש תשלום כי הכפתור היה בשפה הלא נכונה.
לקוח חוזר משלם בכרטיס שמור בנגיעה אחת. הכרטיס נשמר ב-vault אצלנו ומופנה לפי טוקן, כך שהמערכות שלכם שומרות הפניה, אף פעם לא PAN — והרכישה השנייה קצרה מהראשונה.
חיובים מחזוריים רצים לפי לוח זמנים שאתם מגדירים — סכום, מחזור, התחלה וסיום — על כרטיס מטוקן. כל מחזור מפיק הזמנה וקבלה משלו, כך שמנוי מותאם שורה אחר שורה כמו כל דבר אחר.
דחייה רכה בחיוב מחזורי מנוסה שוב לפי לוח זמנים במקום להימחק, והלקוח מקבל הודעה רק כשזה משנה. חידושים שנכשלו מפסיקים להיות churn שקט.
כרטיסים שמורים נשמרים כ-network tokens ועוקבים אחרי בעל הכרטיס לאורך הנפקות מחדש ופקיעות תוקף. המנוי שנהג להישבר כשהכרטיס הוחלף ממשיך לחייב.
הזמנות נוצרות ב-API עם idempotency keys — בקשה שנשלחה שוב מחזירה את התוצאה המקורית, אף פעם לא חיוב שני — ואזור המפתחים כולל את המפתחות ואת התיעוד. ה-checkout מתארח; האינטגרציה היא קומץ endpoints, מתועדת איפה שההגדרות נמצאות.
ה-backend שלכם שומע על תשלומים ברגע שהם קורים: אירועי webhook חתומים על מחזור חיי ההזמנה — שולם, נכשל, הוחזר — עם אימות חתימה אצלכם והגנת replay אצלנו.
אפליקציות native מציגות את אותו checkout בתוך האפליקציה ולא מעיפות את המשתמש לדפדפן. ה-SDK כולל את לוגיקת השיטות, גיליונות הארנקים ו-3-D Secure; ההזמנה והקבלה הן אלה שה-backend שלכם כבר מכיר.
Plugins של עגלות קניות מחברים חנות קיימת ל-Gateway בלי מפתח: מתקינים, מדביקים את המפתחות, מבצעים תשלום בדיקה. אותן הזמנות מגיעות לאותו back office כמו אלה שנוצרו ב-API.
כשהתשלום חייב להתרחש בתוך הפריסה שלכם, מטמיעים את שדות התשלום ישירות: השדות מתארחים ומוגדרים תחת PCI אצלנו, העמוד סביבם שלכם לגמרי, ונתוני הכרטיס לעולם לא נוגעים בשרתים שלכם.
קישור יכול להיסגר אחרי תשלום אחד או להמשיך לגבות — מקום בסדנה בדמו נרכש ב-3 תשלומים, שעת הייעוץ ב-6. כברירת מחדל קישורים פגים אחרי 30 יום, וקישור שפג תוקפו אומר זאת במפורש במקום להיכשל בשקט.
הרצות האינטגרציה מתבצעות מול סשנים לבדיקה, עם כרטיסים שמונפקים לצד מפתחות ה-sandbox, לפני שמוזז כסף אמיתי. הזרימות זהות, ולכן מה שעובר בבדיקה הוא מה שעולה לאוויר.
תעבורת כרטיסים מתנהלת לפי מדיניות ניתוב שמנוסחת במונחים מוכרים — מותג כרטיס, מדינת הנפקה, מטבע, סכום — ולא קופסה שחורה. אפשר לראות באיזה נתיב עבר תשלום, באותו מסך שבו מופיע התשלום.
סירוב רך מנוסה שוב בנתיב חלופי באותו סשן checkout, לפני שהלקוח רואה כשל. רוב התשלומים שהוצלו הם כאלה שהלקוח לא ידע שהיו בסכנה.
קודי מנפיק גולמיים מתורגמים לסיבות שאפשר לפעול לפיהן — כרטיס שפג תוקפו, יתרה לא מספקת, סיכון מצד המנפיק — ומקובצים כך שדפוס בין הרבה תשלומים נראה כדפוס.
רוב התשלומים עוברים על סמך אותות מכשיר והתנהגות בלבד; אתגר אימות נוסף מופיע כשהמדיניות דורשת. אתם קובעים את המדיניות — תמיד, מבוססת סיכון, או פטור במקום שהכללים מתירים — והדף המאוחסן מנהל את הזרימה.
Checkout, קבלה וסליקה נושאים את אותה אסמכתת הזמנה. מי שמחפש 9F21-0716 מוצא רשומה אחת של €49.00 — ולא רשומת כרטיס במערכת אחת ורשומת קריפטו באחרת.
הסליקה מוגדרת במקום שבו מגדירים אותה: המרה אוטומטית ל-EUR, סליקה ל-RO49 •••• 0421, העברה יומית ב-23:00. המספר שרואה רואה החשבון מחר נקבע היום במסך שהסוחר יכול לקרוא.
כל העברה נפתחת להזמנות שמימנו אותה, עם עמלות מפורטות. שורת הבנק תואמת רשימה שאפשר לייצא, כך שסוף חודש הוא חיפוש ולא חקירה.
סכום ההחזר ניתן לעריכה עד לחיוב המקורי — המגירה מציגה את המקסימום ומתייחסת לכל סכום נמוך יותר כהחזר חלקי. עשרה החזרים חלקיים על הזמנה אחת עדיין מתיישבים מול אסמכתה אחת.
כל החזר נושא סיבה חובה והערה אופציונלית, וההערה נודדת איתו: היא מופיעה בייצואים ובקבלה של הלקוח. אחרי חצי שנה אף אחד לא צריך לזכור למה הזמנה 9F21-0716 זוכתה.
קבלות נשלחות ללקוח במייל וניתנות להורדה במקום, וקבלות החזר עוברות באותו מסלול. הסוחר לא צריך לבנות תבנית קבלה.
ביטול לפני סגירת האצווה היומית משחרר את חסימת האישור וכסף לא זז — בלי החזר, בלי עמלה, בלי שום דבר בדף החשבון של הלקוח שצריך להסביר.
תשלומי כרטיס עוברים 3-D Secure לפי מדיניות ניתוב שאפשר לקרוא. תשלומי ארנק נושאים את האימות של המכשיר עצמו, ואירועי webhook עוברים אימות חתימה לפני שסומכים עליהם.
כללי סינון נקראים כמו משפטים — סכום מעל X ממדינה Y בכרטיס חדש — ופועלים לפיהם: לאשר, לאתגר או לחסום. רשימות של כרטיסים, מיילים וכתובות מהימנים וחסומים נמצאות באותו מסך.
ניסיונות חוזרים מאותו כרטיס, מכשיר או כתובת נתפסים בכללי קצב ולא כשאדם מבחין בהם מאוחר יותר. האותות מוצגים על התשלום עצמו, ולא קבורים בציון.
chargeback נפתח עם ההזמנה שמאחוריו: תוצאת האישור, תוצאת 3-D Secure, קבלה, משלוח, היסטוריית החזרים. עונים מאותו מסך, וחבילת הראיות נבנית מהרשומה ולא מהזיכרון.
הדף שאוסף את פרטי הכרטיס הוא שלנו, בהיקף PCI ומאוחסן אצלנו. בין אם הלקוח משלם בדומיין שלנו, בשלכם או בתוך האפליקציה שלכם, השרתים שלכם רואים טוקן ואסמכתת הזמנה — אף פעם לא מספר כרטיס.
נתוני תשלום מוצפנים במנוחה ומעובדים באיחוד האירופי. לסוחר אירופי, איפה הנתונים נמצאים הוא תשובה, לא הערת שוליים.
החזרים, שינויי אמצעי תשלום, שינויי מיתוג, החלפות מפתחות — כל אחד נרשם ביומן ביקורת עם המפעיל, חותמת הזמן והסיבה. פעולות מורשות דורשות סיבה לפני שהן רצות.
הכספים רואים העברות, התמיכה רואה הזמנות ומבצעת החזרים, המפתחים רואים מפתחות ולוגים. הגישה ניתנת לפי תפקיד ולא בשיתוף משתמש אחד.
משלמים מצטברים לתצוגת לקוחות — מי שילם, באיזו תדירות, באיזה אמצעי — כך שלקוח חוזר הוא רשומה, ולא צירוף מקרים של מיילים תואמים בייצואים.
מוצאים תשלום לפי קישור או אסמכתה בתיבת החיפוש; מייצאים את התצוגה הנוכחית ל-CSV כשהספרים דורשים. הבק-אופיס מניח שרואה חשבון עוד ישאל.
נפח, שיעור אישור, החזרים ותמהיל אמצעי תשלום, לאורך התקופה שבחרתם. מספיק כדי לענות לאן הלך הכסף ואיזה אמצעי כדאי לקדם — בלי לייצא דבר.
Gateway מתחבר ל-Protocore Center: הבק-אופיס של קישורי התשלום שם מציג כל קישור עם העברת הסליקה שלו וקישור לפתיחה ב-Tracer למעקב מלא. צוות התפעול רואה דרך ה-checkout עד לפנקס.
ה-checkout בדמו שייך ל-Arc Studio SRL: השם שלהם, הסימן שלהם, ההזמנה שלהם. אפשר להריץ אותו עם פוטר powered-by-Protocore או ב-whitelabel מלא — כך או כך, הדף נראה שלכם.
FAQ
תשלומי כרטיס מתבצעים בשני שלבים: האישור (authorization) מעמיד את הכספים בהחזקה ברגע הרכישה, והסליקה (settlement) מעבירה אותם. Gateway מבצע capture אוטומטית, סוגר את הזמנות היום באצווה ומעביר ב-EUR לחשבון הרשום על שמכם בשעת התשלום היומית שהוגדרה בהגדרות.
תזמון. לפני הסליקה, ביטול משחרר את ההחזקה ואף כסף לא זז. אחרי הסליקה זה החזר — מונפק על ההזמנה, מלא או חלקי, וחוזר דרך אמצעי התשלום המקורי עם הסיבה ברשומה.
כמדיניות, לא כחיכוך כברירת מחדל. רוב הזרימות עוברות על סמך נתוני מכשיר והתנהגות בלבד; אתגר נוסף מופיע רק כשמדיניות הניתוב דורשת זאת. אתם קובעים את המדיניות — העמוד המתארח מנהל את הזרימה.
יורו. סכום ה-USDC מתומחר בעמוד לפני שהלקוח מאשר, מוסדר ל-EUR בשער שהוצג, והקבלה מתעדת את ההמרה. ה-checkout, הקבלה והסליקה חולקים הפניית הזמנה אחת — אף פעם לא תחזיקו פוזיציית טוקנים.
ההזמנה היא תיק הראיות שלכם. תוצאת האישור, הקבלה, היסטוריית ההחזרים ומסירת ה-webhook תלויים כולם בהפניה אחת — חיפוש אחד עונה על הערעור, ולעיתים קרובות החזר מאותו מסך הוא הפתרון המהיר יותר.
לא. הזמנות נוצרות עם מפתחות אידמפוטנטיות, ולכן בקשה חוזרת מחזירה את התוצאה המקורית במקום חיוב שני — וה-webhooks חתומים עם הגנה מפני replay בדרך חזרה.
העמוד שאוסף את פרטי הכרטיס הוא שלנו — מתארח ובתחום PCI אצלנו. השרתים שלכם מקבלים טוקן והפניית הזמנה, אף פעם לא מספר כרטיס. כך זה גם כשהלקוח משלם בדומיין שלנו, בדומיין שלכם, באפליקציה שלכם או דרך שדות תשלום המוטמעים בעיצוב שלכם.
כן. אפשר להריץ אותו ב-host שהונפק עם ה-sandbox שלכם, בדומיין משלכם, או מוטמע בעמוד שלכם עם שדות תשלום מתארחים. המיתוג — לוגו, צבעים, גופן, פינות — הוא מסך הגדרות עם תצוגה מקדימה חיה, והפוטר הוא powered-by או whitelabel מלא, לפי בחירתכם.
הכרטיסים נשמרים אצלנו בכספת כטוקני רשת; המערכות שלכם שומרות הפניה. מנוי מחייב את הטוקן לפי הלוח שהגדרתם, מנסה שוב דחיות רכות בעצמו ועוקב אחרי בעל הכרטיס גם בהנפקה מחדש. כל מחזור יוצר הזמנה וקבלה משלו, כך שמנוי מתואם שורה אחר שורה.
את הסכום במטבע שלו, עם ההמרה מוצגת לפני האישור, וה-checkout בשפה שלו. אתם עדיין נסלקים ב-EUR. אותו עיקרון כמו ב-USDC: צד הלקוח מסתגל, והספרים שלכם נשארים במטבע אחד.
הצד שלכם הוא חייבים ביורו. Gateway מטפל בחלק הקריפטו — תמחור, התשלום on-chain וההמרה — ומה שמגיע לחשבון שלכם הוא EUR מנתיב סליקה מפוקח, כשהשער שחל מתועד בקבלה. אתם לא מחזיקים טוקנים בנאמנות, לא מפעילים ארנק ולא מחזיקים פוזיציה, כי ההמרה מתבצעת לפני הסליקה ולא אחריה.
קישור תשלום עובד ביום שבו יש לכם חשבון. אינטגרציית API היא endpoint להזמנה, הפניה ו-webhook חתום אחד — רוב הצוותים מריצים אותה בבדיקות באותו שבוע ועוברים ל-live אחרי תשלום בדיקה מקצה לקצה. תוספים לחנויות חוסכים את הפיתוח לגמרי.
כן — מריצים את שניהם. מפנים הזמנות חדשות ל-Gateway בזמן שהספק הישן מסיים לסלוק ולהחזיר את שלו, כי החזרים תמיד חוזרים דרך המסלול שקלט את התשלום. כרטיסים שמורים עוברים כטוקנים, כך שהמנויים שלכם לא מזינים פרטי כרטיס מחדש.
את קריאת ההזמנה ואת ה-handler של ה-webhook. עמוד התשלום, לוגיקת השיטות, מסכי הארנק, 3-D Secure, הקבלות וכל שיטה חדשה שתתווסף בהמשך — עלינו לעדכן. זו כל הרעיון של checkout מתארח.
תמחור
עולים לאוויר בלי עמלת פלטפורמה — Gateway מרוויח מהתשלומים שהוא מעבד, כך שהעלות עוקבת אחרי הנפח שעובר ב-checkout.
מפעילים checkout תחת המותג שלכם ברישיון המותאם למסלולים שאתם מפעילים ולתפוקה שאתם מתכננים.
המותג שלכם בעמוד התשלום, התשתית שלנו מתחת, מופעל עבורכם — ההיקף נגזר מאמצעי התשלום שתפעילו.
העלות עוקבת אחרי הנפח שעובר ב-checkout והמסלולים שאתם מפעילים — כרטיסים, ארנקים וסליקת USDC. עצמאי או whitelabel מלא.
הערכה
נריץ איתכם את הדוגמה — Arc Studio SRL, הזמנה 9F21-0716 — תשלום בכרטיס, בארנק וב-USDC, ונראה את ה-back office של בית העסק שמאחוריה.
בית עסק לבדיקות עם מפתחות API, כדי שהצוות שלכם יוכל ליצור הזמנות, להריץ את ה-checkout המאוחסן ולקבל תוצאות חתומות מקצה לקצה.
ה-order API, ה-webhook order.paid ומדריך האינטגרציה — כל מה שצריך כדי לחבר checkout ל-Gateway במקום לבנות אחד.
העמוד המאוחסן עם הלוגו, הצבעים והגופן שלכם, כדי לראות את ה-checkout שלכם לפני העלייה לאוויר.
לקריאה נוספת
פועל עצמאית או כ-whitelabel — המותג שלכם ב-checkout, התשתית שלנו מתחת.
במערכת האקולוגית: PoS משתמש באותו מודל הזמנות של Gateway בקופה, vIBAN מספק להזמנות בהעברה בנקאית הפניות מזהות, Chain מסדיר תשלומי USDC ל-EUR, Center הוא קונסולת המפעיל שמאחורי ה-checkout, ו-Agents מחיל את אותו מודל הזמנות על תשלומים שיוזמת תוכנה במסגרת מדיניות אנושית.
כל מה שלמעלה רץ בדמואים בפרודקשן שנוכל להדריך אתכם בהם — standalone, whitelabel או כפלטפורמה אחת. ספרו לנו מה אתם בונים ונראה לכם את הדרך הקצרה ביותר.
