תשלומים באתר בישראל — Stripe, Tranzila, PayPlus ו-iCount

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

למה המדריך הזה קיים

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

זה לא אמור להיות מסובך. בסוף יש לך שלוש החלטות לקבל בנושא תשלומים באתר בישראל:

1. מי הספק שסולק את הכסף (Stripe / Tranzila / PayPlus / iCount / Cardcom).
2. מי מפיק את החשבונית (לעיתים אותו ספק, לעיתים מערכת נפרדת כמו חשבונית ירוקה).
3. איך מחברים את שני אלה לקוד שלך — בלי לדאוג ל-PCI, ובלי שכרטיסי האשראי יגעו בשרת שלך אי-פעם.

המדריך הזה מפרק את שלוש ההחלטות, נותן קוד אמיתי שעובד, ומסביר את המוקשים שיש בישראל בלבד — מודל חשבוניות ישראל, מע״מ, 3DS2, ו-Bit. אם הסליקה היא חלק מאתר חדש שאתה בונה, שווה לקרוא לצד זה גם על טפסי יצירת קשר עם EmailJS ו-Resend (לאישורי הזמנה) ועל אוטומציה של הפקת חשבוניות עם חשבונית ירוקה — שני הצדדים של אותו flow.

המפה של 2026 — מי המשחקים בשטח

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

ספקים ישראליים (סליקה בש״ח ישר לבנק שלך)

• Tranzila — הוותיק והגדול. אושר על ידי בנק ישראל כסולק נוסף (ב-2024). מתאים כמעט לכל מודל עסקי. iFrame, hosted page, API.
• PayPlus — מתחרה ישיר ל-Tranzila. תיעוד טוב יותר ל-API, חוויית פיתוח מודרנית יותר, תמיכה ב-Apple Pay/Google Pay/Bit מוטמעת.
• iCount (Morning) / חשבונית ירוקה (Morning) — שתי המערכות התאחדו תחת המותג Morning. הן בעיקר מערכות חשבונאות שצירפו סליקה, אז הן הכי טובות לעצמאים ועסקים קטנים שרוצים פתרון אחד שעושה הכל (חשבונית + סליקה + הנהלת חשבונות).
• Cardcom — וותיק, יציב, חזק מאוד ב-API. פחות שיווק, יותר טכנולוגיה. פופולרי אצל מפתחים.
• Hyp / Meshulam / Yaad-Sarig — ספקים נוספים, פחות נפוצים בעולם ה-web, יותר ב-POS פיזי וב-B2B.

ספקים בינלאומיים (קלים לאינטגרציה, אבל יש כוכבית)

• Stripe — הגדול בעולם, חוויית מפתחים מצוינת. אבל יש בעיה עם payouts לישראל — נדבר על זה לעומק.
• PayPal — עובד, אבל יקר (3.4%+ לעסקאות בינלאומיות, יותר על שקלים) ויש בעיות עם משיכת כספים לישראל.
• Lemon Squeezy / Paddle / FastSpring — Merchant of Record, פתרונות שמתאימים בעיקר ל-SaaS גלובלי. הם מוכרים בשמך, אתה מקבל payout נטו אחרי כל החשבוניות והמיסים. שווה לבדוק בנפרד.

ארנקים דיגיטליים (לא ספקים, אלא שיטות תשלום)

• Bit — אפליקציית התשלומים הישראלית הפופולרית, של בנק הפועלים. מוטמעת בתוך Tranzila/PayPlus/PayMe/iCount כשיטת תשלום נוספת לצד כרטיס אשראי.
• Apple Pay / Google Pay — מוטמעים בכל הספקים הגדולים, פשוט ״סוג כרטיס״ מבחינתם.
• Pepper Pay — של בנק לאומי. תמיכה מוגבלת יותר בסליקות web.

המגבלה החשובה לזכור על Bit בקבלת תשלומים עסקיים: מקסימום 5,000 ש״ח לעסקה בודדת, ויתרת ארנק עד 20,000 ש״ח (סכום מעבר לזה מועבר אוטומטית לחשבון הבנק המקושר), ואין שמירת כרטיס לחיובים עתידיים — כלומר אין subscriptions דרך Bit. זה לא מגיע ממך, זה ההגבלות של Bit עצמו.

Stripe בישראל — מצב 2026 (האמת המורכבת)

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

מה כן עובד עם Stripe מישראל:

• חשבון Stripe Test Mode — חינמי, פותחים תוך 30 שניות, אפשר לפתח ולבדוק את כל הקוד.
• Stripe Checkout / Elements / Payment Intents — כל הצד הטכני עובד מצוין.
• קבלת תשלומים בכרטיסי אשראי מכל העולם — Stripe סולק כמעט כל מטבע (135+ מטבעות).

מה לא עובד / מסובך עם Stripe מישראל:

• Payout ישיר בשקלים לחשבון בנק ישראלי — היסטורית, Stripe לא תומך בזה ישירות. נכון ל-2026, ישראל לא נמצאת ברשימת המדינות שמקבלות payout ב-ILS לחשבון ישראלי כברירת מחדל. הסטטוס משתנה לפעמים — תבדוק את stripe.com/global ביום שאתה פותח חשבון.
• המשמעות: עוסק מורשה ישראלי לא יכול פשוט להירשם ב-stripe.com, להפעיל את החשבון בלחיצה אחת, ולקבל שקלים לבנק. זה דורש workaround.

ה-workarounds לישראלים שרוצים את Stripe

אופציה 1: Stripe Atlas + LLC אמריקאית. אתה מקים LLC בדלאוור דרך Stripe Atlas (כ-$500 חד-פעמי), מקבל EIN, חשבון בנק אמריקאי דרך Mercury או Wise Business, ופותח Stripe US. ה-payouts יוצאים בדולר לחשבון האמריקאי. מתאים ל-SaaS גלובלי שמוכר רובו בחו״ל, אבל יוצר מורכבות מס משמעותית: חובת דיווח כפול (IRS + רשות המסים), צורך ב-CPA אמריקאי. לא כדאי לעסק שמוכר ללקוחות ישראלים בלבד. אם אתה בונה SaaS ושוקל את המסלול הזה, קרא קודם את בניית MVP ל-SaaS ב-2026 — לרוב כדאי לאמת ביקוש לפני שמשקיעים בהקמת ישות משפטית בחו״ל.

אופציה 2: Wise / Payoneer / Revolut Business כ-״בנק זר״. במדינות מסוימות אפשר לחבר Stripe לחשבון Wise/Payoneer שיש לו פרטי חשבון בנק אמריקאי או אירופי, ואז להעביר את הכסף משם לבנק הישראלי. זה לפעמים עובד, לפעמים Stripe חוסם את החשבון בגלל אי-התאמה בין מדינת הבעלים למדינת חשבון הבנק. אל תבנה על זה כפתרון יציב לטווח ארוך.

אופציה 3: לא להשתמש ב-Stripe ולעבור לספק ישראלי. הכי פשוט. אם כל הלקוחות שלך ישראלים — Tranzila/PayPlus/iCount הם פתרון מעולה, בלי כאב ראש של מס בינלאומי.

מה השתנה ב-2026 — Stripe Global Payouts

ב-28 בינואר 2026 Stripe הרחיבה את Global Payouts ל-15 מדינות נוספות לקבלת cross-border payouts. זו מגמה שמצטברת לאט לאורך השנים, וישראל ממשיכה לטפס בעדיפויות. אבל — נכון ליום שאני כותב את השורות האלה, עדיין אין payout ישיר ב-ILS לחשבון בנק ישראלי ללא workaround. המצב הזה הוא בדיוק מהסוג שמשתנה בלי הכרזה גדולה, ולכן הכלל היחיד שלא משתנה הוא: ביום שאתה פותח חשבון, פתח את dropdown המדינה ב-stripe.com/global ובדוק מה Stripe אומרת ל-Israel באותו רגע. אל תסתמך על מאמר (גם לא על זה) בנקודה הספציפית הזו.

עוד נקודה טכנית שאנשים שוכחים: גם אם תפתור את ה-payout, אתה עדיין צריך לארח את ה-webhook endpoint איפשהו עם HTTPS יציב. אם אתה מתלבט איפה — קרא את Vercel מול Firebase Hosting; שניהם נותנים HTTPS ו-serverless functions שמתאימים בדיוק ל-webhook הזה.

שורה תחתונה (דעה אישית, לא ייעוץ מקצועי):

• בונה SaaS גלובלי, רוב הלקוחות בחו״ל, חולם על נורת׳אמריקה? → Stripe Atlas + LLC.
• בונה אתר/חנות לקהל ישראלי? → ספק ישראלי. Stripe לא שווה את הכאב.
• לא בטוח? → תתחיל עם Tranzila/PayPlus, ואם פתאום יש לך 80% מהמכירות מחו״ל — תוסיף Stripe דרך LLC.

Tranzila ו-PayPlus — שני הספקים הישראלים שאתה צריך להכיר

Tranzila

הוותיק. עובד כמעט עם כל בנק וכל חברת אשראי בישראל, אושר ב-2024 כסולק נוסף בישראל (כלומר — סולק ישיר, לא דרך חברת אשראי אחרת). יש לו iFrame לאינטגרציה מהירה ו-API מלא לבעלי קוד אמיתי.

יתרונות:

• שוק רחב, תמיכה בכל אמצעי התשלום (כרטיסים, Bit, Apple/Google Pay, תשלומים, סטנדינג).
• iFrame שמטפל ב-PCI עבורך — שום פרט אשראי לא נוגע בשרת שלך.
• אינטגרציה ישירה ל-חשבונית ירוקה / Morning להפקת חשבונית אוטומטית.
• תמיכה ענקית בעברית, צוות סליקה זמין בטלפון.

חסרונות:

• ה-UI של הניהול נראה כאילו הוא מ-2015 (כי הוא בערך משם).
• התיעוד ל-API קיים אבל מבוזר, ולפעמים תצטרך לפנות לתמיכה כדי להבין flow ספציפי.
• העמלות לא שקופות באתר — חייבים שיחה עם איש מכירות. צפה ל-2.5%-3.5% + עמלת חשבון חודשית של ~50 ש״ח.

PayPlus

המתחרה הצעיר והמודרני. תיעוד API נקי, תמיכה ב-Webhooks, מערכת ניהול שנראית כמו 2026.

יתרונות:

• API מודרני (REST + JSON), תיעוד טוב באתר docs.payplus.co.il.
• iFrame מובנה, redirect mode, hosted page — בחר מה שמתאים לך.
• Apple Pay, Google Pay, Bit, Max Pay — הכל מוטמע.
• חיובים חוזרים (recurring) — תמיכה מובנית, טובה במיוחד ל-SaaS ישראלי.
• אינטגרציה ל-Wix, Shopify, WooCommerce, ולכל מערכת חשבונאות גדולה.

חסרונות:

• חברה יותר צעירה, פחות ״מורגלת״ אצל רו״ח מסורתיים.
• העמלות גם פה לא פורסמו פומבית, נדרשת שיחה עם איש מכירות. הטווח דומה ל-Tranzila.
• מעט פחות גמיש בעסקאות גדולות מאוד ובמודלים B2B מורכבים (השוואה ל-Tranzila הוותיק).

עמלות — מה הטווח הריאלי

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

• כרטיס מקומי (ישראלי): 1.7%-2.5% + ₪0.5-₪1.5 לעסקה.
• כרטיס בינלאומי / Diners: 2.8%-3.8%.
• דמי חשבון חודשיים: 0-150 ש״ח, תלוי בנפח.
• דמי הקמה: לרוב מאופסים אם אתה מתעקש.

תמיד לבקש הצעת מחיר משתי החברות במקביל ולמנף את ההצעה של השנייה לקבלת מחיר טוב יותר.

iCount / Morning — חשבונית + סליקה במקום אחד

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

מה אתה מקבל בחבילה אחת:

• מערכת הנהלת חשבונות מלאה (חשבוניות, קבלות, הצעות מחיר, הוצאות, דוחות).
• מסוף סליקה מובנה (~30 ש״ח לחודש בנוסף לחבילה הבסיסית).
• אינטגרציה ל-Wix/Shopify/Etsy/WooCommerce (~20 ש״ח לחודש לאינטגרציה).
• חשבוניות אוטומטיות עם כל סליקה — כולל מספרי הקצאה ממודל חשבוניות ישראל (מאוד חשוב, נדבר עליו עוד מעט).
• API גמיש להפקת חשבוניות מהקוד שלך.

למי זה מתאים:

• פרילנסר/עצמאי ישראלי שמוכר שירותים או דיגיטל לקהל ישראלי.
• חנויות אונליין קטנות (עד ~50 הזמנות ביום).
• כל מי שלא רוצה לנהל שתי מערכות נפרדות (חשבונית + סליקה) אלא רוצה שהכל יהיה ב-dashboard אחד.

למי זה פחות מתאים:

• SaaS עם billing מורכב (subscriptions, proration, usage-based) — כאן Stripe או PayPlus יביאו יותר ערך.
• חנות אונליין עם נפח של מאות הזמנות ביום — נדרש פתרון יעיל יותר.
• מי שמוכר רובו ללקוחות בחו״ל ולא צריך חשבונית ישראלית.

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

מחיר משוער (2026): החל מ-9.90 ש״ח לחודש לחבילה הבסיסית. עם סליקה — סביב 40-60 ש״ח לחודש. מסלול Express בהתחייבות שנתית עומד על כ-276 ש״ח לשנה (לפני מע״מ) ומקבל אחוז סליקה משופר. המחירים זזים מדי כמה חודשים, אז תאמת ב-מחירון iCount לפני שאתה סוגר.

Cardcom — אופציה שלישית לטכניים

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

יתרונות:

• API מצוין, תיעוד טכני מפורט (support.cardcom.solutions).
• iFrame, redirect, server-to-server — שלוש שיטות אינטגרציה.
• תמיכה ב-recurring/token, Bit, Apple/Google Pay.
• צוות תמיכה טכני שמדבר בשפת מתכנתים.

חסרונות:

• ה-UI של הניהול לא יפה (אבל לא משנה אם אתה אוטומציה דרך API).
• בדומה לאחרים, מחירים לא פומביים — שיחה חובה.
• פחות שיווק → פחות לקוחות → לפעמים תרגיש פחות ״main-stream״.

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

קוד אמיתי 1: Stripe Checkout בעמוד אחד (Next.js)

לפני שאני מראה קוד — תזכורת: זו דוגמה טכנית שעובדת מבחינת קוד, אבל כדי להפעיל אותה ל-Production מישראל, תקרא קודם את חלק ה-״Stripe בישראל״ למעלה. הקוד מתאים מצוין ל-test mode, או ל-LLC אמריקאית.

1. התקנה

npm install stripe

צור משתני סביבה ב-.env.local:

STRIPE_SECRET_KEY=sk_test_...
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_...
STRIPE_WEBHOOK_SECRET=whsec_...
NEXT_PUBLIC_BASE_URL=http://localhost:3000

2. API route ליצירת Checkout Session

app/api/checkout/route.ts:

import { NextRequest, NextResponse } from 'next/server';
import Stripe from 'stripe';

// השתמש בגרסת ה-API שמופיעה בדאשבורד שלך תחת Developers → API version.
// נכון ל-2026 קו ה-codename הוא dahlia; הצמד גרסה כדי שלא תישבר בעדכון.
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
  apiVersion: '2026-05-27.dahlia',
});

export async function POST(req: NextRequest) {
  try {
    const { priceId, customerEmail } = await req.json();

    const session = await stripe.checkout.sessions.create({
      mode: 'payment',
      payment_method_types: ['card'],
      line_items: [{ price: priceId, quantity: 1 }],
      customer_email: customerEmail,
      success_url: `${process.env.NEXT_PUBLIC_BASE_URL}/success?session_id={CHECKOUT_SESSION_ID}`,
      cancel_url: `${process.env.NEXT_PUBLIC_BASE_URL}/cancel`,
      // לישראל — תמיד תבקש כתובת חיוב לצורך חשבונית
      billing_address_collection: 'required',
      locale: 'he',
    });

    return NextResponse.json({ url: session.url });
  } catch (err) {
    // לא חושפים internal errors ללקוח
    console.error('Stripe checkout error:', err);
    return NextResponse.json(
      { error: 'payment_initialization_failed' },
      { status: 500 }
    );
  }
}

3. כפתור בצד הלקוח

'use client';

export default function CheckoutButton({ priceId }: { priceId: string }) {
  const handleCheckout = async () => {
    const res = await fetch('/api/checkout', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ priceId, customerEmail: '[email protected]' }),
    });
    const { url } = await res.json();
    if (url) window.location.href = url;
  };

  return <button onClick={handleCheckout}>שלם עכשיו</button>;
}

4. Webhook — איפה הקסם קורה

החשוב ביותר: אל תסמוך על דף ה-success בשביל לאשר את התשלום. המשתמש יכול לסגור את הדפדפן, ה-redirect יכול להיכשל, וכן הלאה. האמת היחידה היא ה-webhook.

app/api/webhooks/stripe/route.ts:

import { NextRequest, NextResponse } from 'next/server';
import Stripe from 'stripe';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
  apiVersion: '2026-05-27.dahlia',
});

export async function POST(req: NextRequest) {
  const body = await req.text(); // חשוב: raw body, לא JSON.parse
  const signature = req.headers.get('stripe-signature')!;

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!
    );
  } catch (err) {
    return NextResponse.json({ error: 'Invalid signature' }, { status: 400 });
  }

  // החזר 200 מהר. אם העיבוד כבד — דחה ל-queue.
  switch (event.type) {
    case 'checkout.session.completed': {
      const session = event.data.object as Stripe.Checkout.Session;
      // 1. סמן את ההזמנה כשולמה ב-DB שלך
      // 2. שלח חשבונית דרך Morning/Tranzila API
      // 3. שלח אימייל אישור
      console.log('Payment confirmed:', session.id);
      break;
    }
    case 'payment_intent.payment_failed': {
      // לוג + אולי אימייל ללקוח
      break;
    }
  }

  return NextResponse.json({ received: true });
}

נקודה חשובה: ב-Next.js App Router, ה-body של ה-request חייב להיות raw text — אם תקרא לו כ-req.json() תקבל שגיאת חתימה. השתמש ב-req.text().

קוד אמיתי 2: Tranzila / PayPlus Webhook

הספקים הישראלים עובדים שונה במעט מ-Stripe — בדרך כלל אתה שולח את הלקוח לעמוד hosted שלהם (או מטמיע iFrame), והם שולחים לך POST notification בסיום. הנה דוגמה מינימלית עם PayPlus (Tranzila דומה מאוד):

יצירת לינק תשלום

app/api/payplus/create-payment/route.ts:

import { NextRequest, NextResponse } from 'next/server';

const PAYPLUS_API_KEY = process.env.PAYPLUS_API_KEY!;
const PAYPLUS_SECRET = process.env.PAYPLUS_SECRET!;
const PAYPLUS_PAGE_UID = process.env.PAYPLUS_PAGE_UID!;

export async function POST(req: NextRequest) {
  const { amount, customerName, customerEmail } = await req.json();

  const response = await fetch(
    'https://restapi.payplus.co.il/api/v1.0/PaymentPages/generateLink',
    {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        Authorization: JSON.stringify({
          api_key: PAYPLUS_API_KEY,
          secret_key: PAYPLUS_SECRET,
        }),
      },
      body: JSON.stringify({
        payment_page_uid: PAYPLUS_PAGE_UID,
        amount: amount, // בש"ח
        currency_code: 'ILS',
        sendEmailApproval: true,
        sendEmailFailure: false,
        refURL_success: `${process.env.NEXT_PUBLIC_BASE_URL}/success`,
        refURL_failure: `${process.env.NEXT_PUBLIC_BASE_URL}/failure`,
        refURL_callback: `${process.env.NEXT_PUBLIC_BASE_URL}/api/payplus/webhook`,
        customer: {
          customer_name: customerName,
          email: customerEmail,
        },
      }),
    }
  );

  const data = await response.json();
  if (data.results?.status === 'success') {
    return NextResponse.json({ url: data.data.payment_page_link });
  }
  return NextResponse.json({ error: 'payment_init_failed' }, { status: 500 });
}

Webhook שמטפל באישור

// app/api/payplus/webhook/route.ts
import { NextRequest, NextResponse } from 'next/server';
import crypto from 'crypto';

export async function POST(req: NextRequest) {
  const body = await req.text();
  const signature = req.headers.get('x-payplus-signature');

  // אימות חתימה (PayPlus משתמש ב-HMAC)
  const expectedSignature = crypto
    .createHmac('sha256', process.env.PAYPLUS_WEBHOOK_SECRET!)
    .update(body)
    .digest('hex');

  if (signature !== expectedSignature) {
    return NextResponse.json({ error: 'invalid_signature' }, { status: 400 });
  }

  const payload = JSON.parse(body);

  if (payload.transaction.status_code === '000') {
    // עסקה הצליחה
    // 1. עדכן ב-DB
    // 2. הפק חשבונית דרך Morning API
    // 3. שלח אישור ללקוח
  }

  return NextResponse.json({ ok: true });
}

הנקודה החשובה: תמיד אמת חתימה, ולעולם אל תסמוך על פרמטרים ב-URL לאישור תשלום. משתמש יכול לזייף אותם. אם אתה רוצה לראות איך לוגיקת הקצה-לקצה הזו נראית בפועל — webhook שמקבל אישור ואז מפעיל תהליך עסקי — דפוס ה-server-side validation זהה למה שמתואר במדריך טפסי יצירת קשר עם EmailJS ו-Resend.

חוק חשבוניות ישראל — מה אתה חייב לדעת ב-2026

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

מה זה ״מודל חשבוניות ישראל״?

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

הלוח זמנים — ואיפה אנחנו עכשיו

הרפורמה נכנסה לתוקף ב-2024, והסף יורד במדרגות. שים לב: התאריך שאני כותב בו את העדכון הזה הוא 22 ביוני 2026, כך ששתי המדרגות הראשונות כבר עברו:

כלומר היום, כל חשבונית מס מעל 5,000 ש״ח לפני מע״מ כבר מחייבת מספר הקצאה. אם בנית את ה-flow שלך עוד כשהסף היה 10,000 ש״ח — זו הנקודה לוודא שהמערכת מבקשת הקצאה גם בסכומים הנמוכים יותר.

מה זה אומר בפועל לאתר שלך?

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

הטכנולוגיה מתבצעת ככה: בעת הפקת החשבונית, מערכת החשבוניות (Morning, Tranzila Invoice, EZcount, וכו׳) פונה ל-API של רשות המסים, מקבלת מספר הקצאה, ומדפיסה אותו על החשבונית.

המודל הרשמי נקרא CTC (Continuous Transaction Controls) — מודל ״clearance״ שבו נתוני החשבונית נשלחים למערכת שע״ם המרכזית של רשות המסים לפני שהחשבונית נחשבת תקפה, ורק אחרי אישור בזמן אמת חוזר מספר ההקצאה. בפועל זה אומר ששלוש בקשות רצות מאחורי הקלעים בכל מכירה מעל הסף:

1. הלקוח משלם → הספק (Stripe/PayPlus/Tranzila) מאשר עסקה ומחזיר לך אישור ב-webhook.
2. ה-webhook קורא ל-API של מערכת החשבוניות (Morning וכו׳) להפקת חשבונית מס.
3. מערכת החשבוניות פונה ברקע לשע״ם, מקבלת מספר הקצאה, ומשלימה את החשבונית — הכל בתוך שניות ספורות.

מקרה קצה שתופס מפתחים לא מוכנים: אם רשות המסים לא זמינה או הבקשה נכשלת (rate limit, certificate, downtime), מספר ההקצאה לא חוזר — והחשבונית נשארת ״תקועה״. ספק חשבוניות טוב מטפל בזה עם retry אוטומטי, אבל ה-webhook שלך צריך להיות עמיד: אל תסמן ״הכל הסתיים״ רק כי החיוב עבר. הפרד בין ״תשלום אושר״ ל-״חשבונית הונפקה בהצלחה״ ב-DB, ושלח התראה אם החשבונית לא הושלמה תוך כמה דקות.

עבורך כמפתח:

• אם אתה משתמש ב-Morning / Tranzila Invoice / iCount / חשבונית ירוקה — הם מטפלים בזה אוטומטית. אין מה לעשות.
• אם אתה מנסה להפיק חשבוניות לבד — אל תעשה את זה. השתמש בספק. החיבור לרשות המסים מורכב, דורש תעודות דיגיטליות, ויש לא מעט rate limits שצריך לטפל בהם.

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

חשבונית מס מול חשבונית עסקה מול קבלה — ההבדל בקצרה

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

אסמכתאות למס — מה לשמור

• שמור עותק של כל חשבונית 7 שנים (חוק).
• שמור גם את ה-webhook payload שמאשר את התשלום מהספק (Stripe / Tranzila) — זו הראיה הטכנית שלך שעסקה התרחשה.
• אם אתה משתמש ב-Stripe מ-LLC אמריקאית — תתייעץ עם רו״ח (פעם שלישית שאני אומר את זה במדריך, ולא במקרה) לגבי דיווח על הכנסות חוץ.

PCI Compliance — מה אתה חייב לדעת

PCI DSS (Payment Card Industry Data Security Standard) הוא תקן בינלאומי לאבטחת מידע על כרטיסי אשראי. אם תיגע בפרטי אשראי בשרת שלך, אתה במסלול שעולה אלפי דולרים בשנה ב-audits, vulnerability scans, ו-self-assessment questionnaires. אל תעשה את זה.

הכלל היחיד שאתה צריך לזכור

אסור שמספר הכרטיס יעבור בקוד שלך, ב-RAM של השרת שלך, או ב-Database שלך. לעולם.

איך מבטיחים את זה? משתמשים ב-tokenization דרך iFrame או hosted page:

• Stripe Elements / Stripe Checkout — Stripe מפעיל iFrame שאתה משבץ בעמוד. המשתמש מקליד את הכרטיס ב-iFrame שלהם, לא שלך. אתה מקבל בחזרה token (tok_xxx או pm_xxx) שאתה משתמש בו לחיוב. הכרטיס מעולם לא נגע בשרת שלך.
• Tranzila iFrame / PayPlus iFrame — אותו רעיון בדיוק. הספק הישראלי מספק iFrame שמוטמע באתר שלך, המשתמש מקליד בו, אתה מקבל token או transaction ID.
• Hosted Page (redirect) — האלטרנטיבה: שולח את המשתמש לעמוד תשלום ב-domain של הספק, הוא משלם שם, חוזר אליך. גם זה PCI-clean.

מה הסטטוס שלך כש-iFrame מטפל בהכל?

אתה ב-SAQ A — Self-Assessment Questionnaire הכי קצר ופשוט שיש. שאלון של ~30 שאלות פעם בשנה, ללא צורך ב-scans חיצוניים. מי שמטמיע iFrame כראוי לא צריך לעבור הליך מורכב. שים לב שגרסת PCI DSS 4.0.1 הוסיפה דרישות חדשות גם ל-SAQ A (למשל מעקב אחרי סקריפטים בעמוד התשלום), אז אם עמוד התשלום שלך טוען scripts של צד שלישי — קרא את השאלון העדכני, לא גרסה ישנה ממדריך.

מה אתה כן עושה בעצמך

• HTTPS על כל האתר (לא רק על עמוד התשלום). תקן 2026 — בלי TLS 1.2+ אתה ב-non-compliance.
• אל תלוג פרטי אשראי לאיפשהו. גם לא ארבע ספרות אחרונות בלי data minimization.
• שמור tokens במסד הנתונים, לא כרטיסים.
• אל תשלח פרטי אשראי במייל. לעולם. (אם לקוח שולח לך אשראי במייל — מחק ובקש ממנו להשתמש בטופס).

3DS2 — Strong Customer Authentication

3D Secure 2 הוא פרוטוקול שבו הבנק של המחזיק מאשר את העסקה בצורה דינמית — לרוב באמצעות אישור באפליקציית הבנק, OTP ב-SMS, או biometrics בסמארטפון.

מה זה משנה לך?

• באירופה (PSD2) — חובה כמעט תמיד. ב-Israel הרגולציה רכה יותר אבל בנקים מקומיים יכולים לדרוש 3DS לעסקאות גבוהות.
• Conversion impact — 3DS מוסיף שלב ביניים. אם הוא כושל (כי הבנק לא תומך, או אנטי-fraud בלם), העסקה נופלת. בעסקאות עם 3DS פעיל סביר לראות ירידה קלה ב-conversion לעומת חיוב חלק; כמה בדיוק תלוי בקהל ובסכום, אז תמדוד אצלך במקום להניח.
• Liability shift — אם השתמשת ב-3DS והעסקה התאשרה, הבנק נושא באחריות ל-chargeback (במקרים מסוימים). זה הצד הטוב.

הגדרה ב-Stripe

Stripe מטפל ב-3DS אוטומטית — אם הבנק דורש, יציג את החלון. ברירת מחדל היא ״automatic״ — Stripe מחליט לפי הסיכון. בשורת קוד:

const paymentIntent = await stripe.paymentIntents.create({
  amount: 5000,
  currency: 'ils',
  payment_method_options: {
    card: {
      request_three_d_secure: 'automatic', // או 'any' לכפיה תמיד
    },
  },
});

בספקים ישראלים

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

בחירה מומלצת לפי תרחיש

טבלת החלטות שמתוחזקת בהיגיון פשוט. תקרא את השורה שמתאימה לך:

שגיאות נפוצות שראיתי במאות אתרים

1. סומכים על דף ה-success. לקוח חוזר אחרי תשלום ל-/success — ואתה מסמן את ההזמנה כשולמה. רק שהוא לא חזר בכלל, הדפדפן קרס, וההזמנה לא שולמה. תמיד תאשר רק דרך webhook.

2. שומרים פרטי אשראי ״רק בשביל token עתידי״. לא. אם אתה רוצה לחייב שוב, שמור את ה-Stripe payment_method ID או את ה-Tranzila token, לא את הכרטיס. הספק שומר את הכרטיס המוצפן אצלו, אתה רק שולח את ה-token.

3. שולחים סכומים מהקליינט בלי וולידציה. ה-frontend שולח amount: 100. השרת מסליק. רק שהמשתמש פתח DevTools ושינה ל-1. תמיד תאמת את הסכום ב-server-side לפי מזהה המוצר.

4. מתעלמים מ-idempotency. Webhook יכול להגיע פעמיים (Stripe retries אם לא קיבל 2xx). אם ה-handler שלך שולח חשבונית בכל קריאה — תקבל שתי חשבוניות. השתמש ב-idempotency_key או בדוק אם ה-event.id כבר עובד אצלך.

5. לא בודקים test mode מספיק. Stripe נותן טופס מספרי כרטיסי בדיקה. תבדוק לפחות: כרטיס שעובד (4242 4242 4242 4242), כרטיס שדורש 3DS (4000 0027 6000 3184), כרטיס שנדחה (4000 0000 0000 0002), וכרטיס שנדחה ל-insufficient_funds (4000 0000 0000 9995).

6. שוכחים לוואדל webhook signature. איזה משעמם. עד שיום אחד מישהו שלח לך webhook מזויף שמסמן הזמנה של 10,000 ש״ח כשולמה. תמיד תאמת חתימה.

7. שמים את ה-Stripe Secret Key ב-frontend. זה שונה מ-Publishable Key. ה-Secret Key לעולם לא מגיע לדפדפן. אם הוא דלף — תחליף אותו מיד בדאשבורד של Stripe.

8. לא חושבים על מטבע. Stripe מחייב את הסכום ב-״smallest currency unit״. בש״ח זה אגורות. amount: 5000 = 50 ש״ח, לא 5,000 ש״ח. בעבר זה הפיל המון פיתוחים.

9. בונים חיוב חוזר ידני במקום להשתמש ב-Subscriptions/Tokens. אם אתה רוצה לחייב כל חודש — תשתמש ב-Stripe Subscriptions או ב-PayPlus recurring API, לא ב-cron job שמחייב לפי list של כרטיסים. אתה לא PCI-compliant לעשות את זה ידנית.

10. שוכחים שלקוחות B2B חייבים חשבונית עם מספר הקצאה. מעל הסף (5,000 ש״ח מ-יוני 2026) — לקוח עסקי שלך לא מקבל ניכוי מע״מ → מתעצבן → מבטל. ודא שמערכת החשבוניות שלך מחוברת לרשות המסים מהיום הראשון.

שאלות נפוצות

האם Stripe עובד בישראל ב-2026?

הצד הטכני של Stripe עובד מצוין מישראל — Test Mode, Checkout, Elements, Payment Intents, וקבלת תשלומים מ-135+ מטבעות. הבעיה היחידה היא ה-payout: נכון ל-2026, Stripe לא משלם ישירות ב-ILS לחשבון בנק ישראלי ללא workaround (LLC אמריקאית דרך Stripe Atlas, או חשבון Wise/Payoneer). אם הלקוחות שלך ישראלים — ספק ישראלי כמו PayPlus או Tranzila יחסוך לך הרבה כאב ראש.

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

אין מספר אחד כי כל הספקים נותנים מחיר אישי לפי נפח, אבל הטווח הריאלי ב-2026 לכרטיס ישראלי הוא 1.7%-2.5% + כ-0.5-1.5 ש״ח לעסקה. דמי חשבון חודשיים נעים בין 0 ל-150 ש״ח. הטיפ החשוב: בקש הצעת מחיר משתי חברות במקביל (למשל Tranzila ו-PayPlus) ומנף הצעה אחת מול השנייה. לעצמאי קטן, Morning עם הסליקה המובנית מתחיל בסביבות 40-60 ש״ח לחודש כולל חשבונית.

מה זה מספר הקצאה ומתי אני חייב אותו?

מספר הקצאה הוא מזהה ייחודי שרשות המסים מנפיקה בזמן אמת לחשבונית מס, במסגרת מודל חשבוניות ישראל. החל מ-1.6.2026 הוא חובה על כל חשבונית מס מעל 5,000 ש״ח לפני מע״מ (לפני כן, מ-ינואר 2026, הסף היה 10,000 ש״ח). בלי מספר הקצאה תקף, הלקוח העסקי שלך לא יכול לקזז את המע״מ — ולכן זו דרישת חובה. מערכות כמו Morning, iCount ו-Tranzila Invoice מטפלות בזה אוטומטית.

האם אני צריך להיות PCI compliant אם אני משתמש ב-Stripe או PayPlus?

כן, אבל ברמה הכי קלה. כל עוד אתה משתמש ב-iFrame או ב-hosted page (כך שמספר הכרטיס אף פעם לא נוגע בשרת שלך), אתה ב-SAQ A — שאלון של כ-30 שאלות פעם בשנה, ללא scans חיצוניים. הכלל המוחלט: אסור שמספר כרטיס יעבור בקוד שלך, ב-RAM, או ב-DB — לעולם. שמור tokens, לא כרטיסים.

האם אפשר לחבר Bit לאתר שלי לחיובים חוזרים?

לא. Bit מוטמע בתוך Tranzila, PayPlus, PayMe ו-iCount כשיטת תשלום נוספת לצד כרטיס אשראי, אבל יש לו מגבלות: מקסימום 5,000 ש״ח לעסקה בודדת, יתרת ארנק עד 20,000 ש״ח (מעבר לזה הכסף עובר אוטומטית לבנק), ואין שמירת כרטיס לחיובים עתידיים — כלומר אין subscriptions דרך Bit. לחיובים חוזרים תצטרך כרטיס אשראי דרך recurring API (PayPlus) או Stripe Subscriptions.

צריך חשבונית עם מספר הקצאה גם לעסקאות קטנות?

לא לכל עסקה. מספר ההקצאה נדרש רק לחשבונית מס מעל הסף (5,000 ש״ח לפני מע״מ, נכון מ-יוני 2026), ובעיקר רלוונטי ללקוחות עסקיים שרוצים לקזז מע״מ. עסקאות לאנשים פרטיים מתחת לסף לא מחייבות מספר הקצאה — אבל אתה עדיין חייב להפיק חשבונית מס/קבלה כדין. כשאתה בספק, זו בדיוק השאלה לרו״ח שלך.

מה ההבדל בין חשבונית עסקה לחשבונית מס?

חשבונית עסקה מוצאת בעת ההזמנה לפני שהכסף הגיע, ולא יוצרת חבות מע״מ. חשבונית מס מוצאת אחרי (או יחד עם) קבלת התשלום ומחייבת ב-מע״מ — וזו החשבונית שצריכה מספר הקצאה אם היא מעל הסף. באתרים הסוג הנפוץ ביותר הוא ״חשבונית מס/קבלה״ שמשלב את שניהם בו-זמנית.

האם אני יכול להתחיל לבדוק הכל לפני שאני חותם הסכם עם ספק?

כן, וזה גם מה שאני ממליץ. גם Stripe וגם PayPlus נותנים סביבת Test/Sandbox חינמית שבה אתה בונה את כל ה-flow — checkout, webhook, אימות חתימה, הפקת חשבונית מדומה — בלי לגבות שקל אמיתי. תמדוד אצלך את שיעור ההשלמה לפני שתבחר ספק; הנתון הזה משתלב היטב עם הגדרת אנליטיקס נכונה (GA4 / Plausible / PostHog) שתראה לך איפה לקוחות נושרים במשפך התשלום.

לסיכום

תשלומים באתר בישראל מתפרקים לשלוש החלטות נפרדות: מי סולק את הכסף, מי מפיק את החשבונית, ואיך מחברים את שניהם לקוד בלי לגעת בפרטי אשראי. ל-90% מהעסקים הישראלים, Morning (iCount/חשבונית ירוקה) עם סליקה מובנית הוא הפתרון הפשוט ביותר — סליקה, חשבונית ומספר הקצאה במקום אחד. למפתחים עם דרישות מתקדמות, PayPlus לסליקה + Morning לחשבוניות נותן API מודרני ו-recurring מובנה. Stripe נשאר רלוונטי בעיקר ל-SaaS גלובלי דרך LLC אמריקאית, כי ה-payout בשקלים לישראל עדיין דורש workaround ב-2026. תתחיל ב-Test mode, אמת תמיד דרך webhook (לא דרך דף success), זכור שמ-יוני 2026 סף ההקצאה כבר 5,000 ש״ח, ולפני שאתה מפעיל סליקה אמיתית — דבר עם רו״ח.

רוצה שאני אטפל בזה בשבילך?

אני בונה אתרים, חנויות אונליין ומערכות תשלום ללקוחות ישראליים מ-2019. אם אתה רוצה אינטגרציית סליקה שעובדת מהיום הראשון — עם webhook, חשבוניות אוטומטיות, 3DS, ו-PCI compliance מובטח — דבר איתי.

מקורות

• Stripe Global Availability — רשימת מדינות נתמכות מעודכנת.
• Stripe Documentation — Receive Payouts — תנאי payout לפי מדינה.
• Stripe API Versioning — שמות גרסאות ה-API (basil, dahlia וכו׳).
• Stripe Checkout Quickstart — תיעוד רשמי ל-Next.js.
• Stripe 3D Secure Documentation — הטמעת 3DS2.
• Stripe Atlas — הקמת LLC אמריקאית.
• Stripe PCI Compliance Guide — סקירת PCI DSS.
• Tranzila — אתר הספק.
• Tranzila API Documentation — תיעוד טכני.
• PayPlus API Reference — תיעוד PayPlus.
• PayPlus — אתר הספק.
• iCount / Morning — סליקה + חשבונית.
• iCount Pricing 2026 — מחירון נוכחי.
• Green Invoice / Morning API Docs — תיעוד API להפקת חשבוניות.
• Cardcom — אתר הספק.
• Cardcom API Documentation — תיעוד טכני.
• רפורמת חשבוניות ישראל — Green Invoice Magazine — מדריך מעודכן למספר הקצאה.
• iCount Blog — חשבוניות ישראל 2026 — מספר הקצאה ושלבי החוק.
• רשות המסים — בקשת מספר הקצאה לחשבונית מס — השירות הרשמי.
• Bit לעסקים — אתר Bit הרשמי של בנק הפועלים.
• Stripe Webhook Signing Example (GitHub) — דוגמת קוד רשמית.
• Stripe Testing Cards — מספרי כרטיסי בדיקה.

---

המדריך עודכן לאחרונה ב-22 ביוני 2026. המידע על תנאי Stripe לישראל ועל רפורמת חשבוניות ישראל יכול להשתנות — לפני שאתה מפעיל סליקה ל-Production, וודא את הסטטוס באתרים הרשמיים של הספקים ושל רשות המסים. ושוב — דבר עם רו״ח.