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

למי זה

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

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

מה מקבלים

• REST עם מפתח API. יצירת תשלומים, שליפת הזמנות ולקוחות, וזיכוי, דרך בקשות HTTP רגילות.
• webhooks לאירועי תשלום. המערכת שלכם מקבלת הודעה כשתשלום עובר, במקום לשאול שוב ושוב.
• MCP. כל פעולה שיש לה מסך בכיס, יש לה גם כלי. מי שעובד עם כלי שמדבר MCP מגיע לאותן פעולות בלי לכתוב עטיפה משלו.
• קישורי תשלום ודף תשלום מתארח. אפשר להפנות לקוח לדף התשלום של כיס בלי לבנות טופס כרטיס. איך זה נראה מצד הלקוח, כתוב במדריך קישור לתשלום בוואטסאפ.
• הוראות קבע. חיוב חודשי מכרטיס שמור, מנוהל באותה קופה. הרקע העסקי נמצא במדריך תשלומים חוזרים.
• חשבונית שנפתחת לבד. אחרי שהעסק חיבר את Morning או את iCount, כל תשלום שיצרתם מקבל מסמך בלי קוד נוסף.
• דוחות. מה נכנס, מתי זה מגיע לבנק, העלות האמיתית של כל עסקה ומי לא שילם.

למה לא לחבר את הסולק ישירות

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

מה זה חוסך בפרויקט

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

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

איך זה נראה

הכתובות, שמות השדות והאימות המדויק נמצאים בתיעוד ב-WizzoMarket. בקווים כלליים, ככה מקבלים אירוע של תשלום שעבר. כל אירוע מגיע חתום בכותרת X-Kis-Signature, שהיא HMAC-SHA256 של גוף הבקשה עם הסוד שקיבלתם כשהגדרתם את הכתובת. אם השרת שלכם לא ענה, כיס מנסה שוב כמה פעמים.

// Full URLs and fields: the docs in WizzoMarket.
const crypto = require('crypto');
const raw = express.raw({ type: 'application/json' });

app.post('/kis/events', raw, (req, res) => {
  const expected = crypto
    .createHmac('sha256', process.env.KIS_RELAY_SECRET)
    .update(req.body)
    .digest('hex');
  const got = req.get('X-Kis-Signature') || '';
  const ok = got.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(got), Buffer.from(expected));
  if (!ok) return res.sendStatus(401);

  const event = JSON.parse(req.body);
  if (event.kind === 'order.paid') {
    markOrderPaid(event.order_id, event.data);
  }
  res.sendStatus(200);
});

ובצד ה-REST, כל בקשה נושאת בכותרת Authorization את מפתח ה-API והסוד של האתר. שניהם נשמרים בצד השרת, ולא בדפדפן.

איך מתחילים

1. לוחצים על "פתיחת כיס במרקט" ופותחים כיס לאתר בטופס אחד ב-WizzoMarket.
2. מסוף חדש נפתח בכמה דקות, ומסוף קיים אצל סולק נתמך מתחבר כמו שהוא.
3. מוציאים מפתח API, וקוראים את התיעוד ב-WizzoMarket.
4. מגדירים כתובת webhook ובודקים עם תשלום קטן.

לחנות WooCommerce יש תוסף מוכן, kis-for-woocommerce.zip, שבנוי על אותו API: הוא יוצר POST /v1/checkout/session כשהלקוח מסיים הזמנה, מקבל את order.paid חתום בכתובת ?wc-api=kis_hook של החנות, מזכה דרך POST /v1/refunds, ובחנות עם WooCommerce Subscriptions שומר את הכרטיס בתשלום הראשון ומחייב כל חידוש ב-POST /v1/payment-methods/{id}/charge עם מפתח idempotency, כך שחידוש שנשלח פעמיים מחויב פעם אחת. החנות מחזיקה רק את payment_method_id. הקוד פתוח לקריאה בתוך ה-ZIP, ומי שבונה חנות משלו יכול ללכת באותה דרך. מה עוד לבדוק בחנות כזו, כתוב במדריך סליקה לווקומרס ובעמוד סליקה לווקומרס בכיס.

מה כיס לא

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

מחיר

79 ₪ לחודש לאתר, לפני מע"מ, כולל REST ו-MCP, וכלול ב"אתר מנוהל" של Wizzo. את העמלה על כל עסקה גובה הסולק לפי החוזה של העסק איתו.