תשובה מהירה: ישראל אינה מופיעה ברשימת המדינות הנתמכות בעמוד הזמינות הרשמי של Stripe (נבדק 2.9.2026), ולכן האינטגרציה שסוכן ה-AI כותב כברירת מחדל אינה ניתנת להפעלה על ידי חברה ישראלית. שתי הדרכים שכן עובדות הן ספק סליקה ישראלי, או ספק Merchant of Record. ההחלטה צריכה להתקבל לפני הבנייה, כי היא נוגעת בארכיטקטורה.
הרגע שבו כל המדריכים נגמרים
יש בעברית שני סרטונים עם 15,000 צפיות כל אחד שמלמדים לבנות אפליקציה ב-Base44. יש עשרות מדריכים ל-Lovable. כולם מסתיימים באותה נקודה בדיוק: האפליקציה עובדת, היא באוויר, ואתם מתרגשים.
ואז אתם רוצים לגבות כסף.
זה הרגע שבו החובב הופך ללקוח, וזה גם הרגע שבו כמעט כולם נתקעים. לא בגלל שהקוד גרוע. בגלל החלטה שהסוכן קיבל בשבילכם בלי לשאול.
מה הסוכן עשה, ולמה
בקשו מכל כלי AI להוסיף תשלומים, והוא כמעט תמיד יכתוב אינטגרציה ל-Stripe. הקוד יהיה תקין. הוא פשוט לא יעבוד עבורכם.
בעמוד הזמינות הגלובלית הרשמי של Stripe, נכון לבדיקה ב-2 בספטמבר 2026, ישראל אינה מופיעה ברשימת המדינות הנתמכות. קפריסין מופיעה. יוון מופיעה. הודו, סינגפור וברזיל מופיעות. ישראל לא.
הסיבה פשוטה: המודלים אומנו בעיקר על חומרים אמריקאיים, ושם Stripe היא ברירת המחדל המובנת מאליה. הסוכן לא יודע איפה העסק שלכם רשום, והוא לא שאל.
זו דוגמה מצוינת לדפוס שחוזר בכל פרויקט שנבנה ב-AI: הקוד תקין, ההחלטה שמאחוריו לא מתאימה לכם. אותו דבר בדיוק קורה עם הרשאות מסד הנתונים - הסוכן בוחר ברירת מחדל, ואף אחד לא ביקש ממנו לבחור נכון.
שתי הדרכים שכן עובדות
ספק סליקה ישראלי
מתחבר לחשבון הבנק שלכם ולחברות האשראי המקומיות. זו הדרך המקובלת כשמוכרים ללקוחות בישראל, והיא גם זו שמסתדרת בטבעיות עם חשבונית, מע״מ וניהול ספרים.
מה שחשוב לדעת לפני שבוחרים: לא לכל הספקים יש תיעוד טכני באותה רמה, ולא כולם מציעים את אותם מנגנונים לחיובים חוזרים. אם המוצר שלכם הוא מנוי, בדקו את הנקודה הזו לפני הכל - היא ההבדל בין אינטגרציה של ימים לאינטגרציה של שבועות.
ספק מסוג Merchant of Record
הספק מוכר ללקוח הסופי בשמו, מטפל במס במדינת הלקוח, ומעביר לכם את התשלום בניכוי עמלה. נפוץ כשמוכרים מנוי דיגיטלי לחו״ל ולא רוצים להתעסק עם מע״מ אירופי או אמריקאי.
העמלה גבוהה יותר מסליקה ישירה, ובתמורה מישהו אחר מחזיק את הכאב הרגולטורי. אם רוב הלקוחות שלכם מחוץ לישראל, זו לרוב הדרך המהירה לשוק.
איך בוחרים: השאלה היא למי אתם מוכרים, לא מה נוח יותר טכנית. לקוחות ישראלים - ספק ישראלי. לקוחות בחו״ל, במיוחד במנוי - שקלו Merchant of Record. שניהם - כנראה שניהם, וזו החלטה ארכיטקטונית שכדאי לקבל מוקדם.
שלושה דברים שכמעט תמיד שבורים בקוד תשלומים שנוצר ב-AI
המחיר מגיע מהדפדפן. הסוכן כותב את הסכום בצד הלקוח ושולח אותו לשרת. מי שפותח את כלי המפתחים יכול לשנות אותו לפני השליחה. הסכום והמוצר חייבים להיקבע בשרת, תמיד.
אין אימות של החזרה מהספק. אחרי תשלום הספק מודיע לאפליקציה שהעסקה הצליחה. אם האפליקציה מאמינה להודעה הזו בלי לאמת אותה מול הספק, אפשר לזייף אותה. כל ספק רציני מספק מנגנון אימות, וכמעט אף מדריך לא מזכיר אותו.
אין טיפול בכפילויות. לקוח לוחץ פעמיים, או הרשת נופלת באמצע. בלי מזהה ייחודי לכל עסקה, הוא מחויב פעמיים. זה נראה נדיר עד שיש מאה משתמשים.
מה לעשות עכשיו
אם עוד לא בניתם - תחליטו על הספק לפני שאתם מבקשים מהסוכן לכתוב שורה. זו החלטה של עשר דקות שחוסכת שבוע.
אם כבר בניתם ויש שם אינטגרציה ל-Stripe - עוד לא איבדתם כלום. מה שקובע כמה עבודה זו החלפה הוא אם התשלומים עוברים דרך מקום אחד בקוד או פזורים בעשרים. אם אתם לא יודעים, זו השאלה הראשונה לבדוק.
ואם אתם באמצע ההחלטה, מחשבון עלות הפיתוח מתייחס לתשלומים כאחד המשתנים שהכי מזיזים את ההיקף - כי הוא באמת כזה. פיתוח מערכת מאפס וחילוץ פרויקט שנתקע שניהם מתחילים באותה שאלה: מה כבר נבנה, וכמה ממנו אפשר להציל.
