מה זה וייב קודינג ולמה הסליקה היא הקיר הראשון
וייב קודינג היא בנייה של אפליקציות דרך שיחה עם AI – מבקשים מ-Cursor, Lovable, Bolt, Replit, v0 או Claude Code "תבנה לי X" והם מייצרים את הקוד [3]. המונח התפשט ב-2024-2025 כשהכלים הפכו טובים מספיק לייצר אפליקציות שלמות ולא רק להשלים שורות קוד בודדות.
רוב האפליקציות שנבנות בוויב קודינג צריכות, בשלב מסוים, לקבל כסף: SaaS, מנויים, חנויות אונליין, חיובים חד-פעמיים. החיבור לסליקה הוא הפיצ'ר הכי לא טריוויאלי באפליקציה וויב-קודית, ולא רק מסיבות טכניות. הוא דורש החלטות עסקיות (אילו אמצעי תשלום לקבל, מודל תמחור, חוקי החזרים), אבטחה אמיתית (PCI, secrets management), ועמידה ברגולציה מקומית. אלו שלושה תחומים שכלי AI לא תופסים טוב מבלי הנחיות מפורטות.
למה Stripe לא הפתרון לאפליקציה ישראלית
Stripe היא חברת התשלומים הברירת-מחדל בעולם המפתחים. הבעיה: היא לא מקבלת חברות עם רישום עסקי בישראל. מנסים לפתוח חשבון, ובשלב KYC המערכת דוחה אותך בגלל המיקום [1].
הפתרון העוקף הוא לפתוח חברה זרה לרוב באסטוניה (e-Residency), דלאוור או בריטניה — לפתוח חשבון Stripe דרכה, ולעבוד מולה. החיסרון: עלויות חודשיות של מאות דולרים, חשבון בנק זר, חובות דיווח כפולות, ומורכבות מס לא טריוויאלית.
מה שכן עובד בישראל: חברות סליקה ישראליות עם תקן PCI DSS Level 1 [2] ורישיון סולק של בנק ישראל. הן מקבלות אשראי בינלאומי, ביט, Apple Pay, Google Pay אותם אמצעי תשלום כמו Stripe, רק תחת תשתית ישראלית.
שלושת הדרכים לחבר סליקה לאפליקציה שבניתם בוייב-קוד
חברות הסליקה הישראליות מציעות שלוש דרכים שונות לחיבור. הבחירה ביניהן תלויה במידת השליטה שאתה רוצה על חוויית המשתמש, וכמה אתה מוכן לטפל באבטחה.
Hosted Payment Page (95% מהמקרים)
איך זה עובד: יוצרים קישור לעמוד תשלום מאובטח של חברת הסליקה. האפליקציה שלך מפנה את המשתמש לקישור, חברת הסליקה מטפלת בכל התשלום (כולל ה-PCI), ושולחת webhook חזרה כשהעסקה הסתיימה.
מתי לבחור: כשלא רוצים להתעסק עם PCI בכלל או כשהאפליקציה לא דורשת UI מותג חזק לדף התשלום.
יתרון: שורות קוד בודדות בצד שלך. כל המורכבות עוברת לחברת הסליקה. החיסרון היחיד: הלקוח רואה דף תשלום שמרגיש "כמו עוד אתר", לא ממש שלך.
Prompt מעשי לכלי וייב קודינג:
Build a checkout button that POSTs to a serverless function.
The function calls EasyCard's create-payment-link API with the amount and
returns the redirect URL. Handle the success webhook by marking the order
paid in Supabase. Use environment variables for the API key — never expose
it in the frontend.
דף תשלום מאובטח של איזיקארד מתאים בדיוק לתרחיש הזה.
REST API (לאינטגרציה מותאמת)
איך זה עובד: האפליקציה שלך שולחת בקשת POST ל-API של חברת הסליקה עם פרטי העסקה (סכום, מטבע, success URL). ה-API מחזיר token, ואתה מציג ללקוח טופס תשלום מובנה (iframe או SDK native) שמרגיש חלק מהאפליקציה שלך.
מתי לבחור: כשרוצים UI מוטמע באפליקציה ולא להפנות החוצה. כשיש לוגיקה עסקית מסביב לתשלום (קופונים דינמיים, חישוב מס מורכב, פיצול תשלום).
דוגמה pseudo-code:
POST https://api.example-clearing.co.il/v1/charge
Headers: { Authorization: "Bearer SERVER_SIDE_KEY" }
Body: {
amount: 1990,
currency: "ILS",
success_url: "https://myapp.com/thanks",
webhook_url: "https://myapp.com/api/payment-webhook"
}
API סליקה של איזיקארד מתועד עם דוגמאות לכל endpoint.
SDK ופלטפורמות ייעודיות
איך זה עובד: ספריית SDK ספציפית לפלטפורמה (Node.js, Python, React Native, iOS, Android), עם טיפוסים, Sandbox מובנה, ניהול אוטומטי של mediathirties וצורות תשלום.
מתי לבחור: אפליקציה native (iOS / Android) שצריכה מעקב מעמיק אחרי states של עסקה. תרחישים של החזרי תשלום אוטומטיים. SaaS עם מנויים מתחדשים שצריך לטפל ב-failed renewals.
הדרישות ב-PCI חלקיות וקלות יותר מ-REST API ישיר, כי ה-SDK מטפל בקלט של פרטי הכרטיס מתחת לכובע.
בעיות אבטחה שכל כלי וייב קודינג מייצר באינטגרציית סליקה
כלי הוויב קודינג מייצרים את הקוד מהר, אבל הם נוטים לחזור על שלוש שגיאות אבטחה ספציפיות באינטגרציות תשלום. אם לא מודעים אליהן, האפליקציה יוצאת ל-production עם פרצות אמיתיות.
חשיפת Secret Key בצד הלקוח
מה קורה: ה-AI שם את ה-API secret key של חברת הסליקה ב-.env.local ואז משתמש בו ישירות בקומפוננטה של React, ב-useEffect או ב-useState. כשהאפליקציה רצה בדפדפן, אפשר לראות את המפתח דרך DevTools ← Network ← מענה של ה-API.
איך לבדוק: פותחים את האפליקציה בדפדפן, F12 << Network tab >> מבצעים עסקת בדיקה >> מחפשים את התחילית של ה-API key (לרוב משהו כמו sk_live_ ) בכל בקשה ותגובה.
איך לתקן: כל קריאת API לחברת הסליקה חייבת לעבור backend או serverless function (Vercel Functions, Supabase Edge Functions, Cloudflare Workers). המשתמש מקבל רק את התוצאה הסופית, לא את המפתח. ה-prompt לכלי הוויב קודינג צריך להיות מפורש: "Never call the payment API from client code. Always route through a serverless function."
היעדר ולידציה של Webhook Signature
מה קורה: ה-webhook מ-חברת הסליקה מגיע ל-endpoint שלך עם הודעה "התשלום אושר". ה-AI מקבל את ה-callback ומסמן את ההזמנה כשולמה בלי לבדוק שהבקשה באמת הגיעה מחברת הסליקה.
ההשלכה: כל אחד שיודע את ה-URL של ה-webhook שלך יכול לשלוח HTTP POST עם payload תקין, והאפליקציה תסמן הזמנות כשולמות בלי שאף שקל נכנס.
איך לתקן: כל חברת סליקה מספקת signing secret. את ה-webhook חותמים ב-HMAC-SHA256, ובצד שלך מאמתים את החתימה לפני שעושים משהו עם התוכן. הספריות הסטנדרטיות של כל פלטפורמה תומכות בזה, צריך רק לבקש מה-AI במפורש: "Verify every webhook signature before processing. Use the SIGNING_SECRET from environment variables."
חוסר טיפול בשגיאות תשלום
מה קורה: ה-AI מטפל רק במסלול "happy path" כרטיס אושר, עסקה הצליחה. בפועל, 15-25% מהתשלומים נכשלים בפעם הראשונה: כרטיס פג תוקף, מסגרת אשראי מלאה, חסימה זמנית של הבנק, כתובת חיוב שגויה.
מה שקורה ללקוח כשהאפליקציה לא מטפלת בזה: מסך שגיאה גנרי שלא מסביר מה לעשות. הלקוח נוטש. אתה מאבד את העסקה ולא יודע למה.
איך לתקן: לבקש מה-AI במפורש לטפל בקודי שגיאה ספציפיים. רשימת הקודים הנפוצים בישראל: card_expired, insufficient_funds, card_declined, bank_temporary_decline, cvv_mismatch. לכל אחד מהם צריך הודעת UI ספציפית בעברית — לא "Payment failed" באנגלית. ה-prompt: "Handle these specific decline codes with localized Hebrew error messages: …"
בניית מסך תשלום באפליקצית Bolt/Lovable מ-0
תהליך של 6 שלבים שמלמד איך לבנות מסך תשלום פונקציונלי, בלי הבעיות שצוינו למעלה.
- הקמת חשבון סליקה: פתיחת חשבון סולק באיזיקארד. תהליך KYC, 1-3 ימי עסקים.
- קבלת API keys מסביבת ה-Sandbox. סביבה נפרדת לבדיקות, עם כרטיסי בדיקה שלא יחייבו אף אחד באמת. אסור להשתמש בכרטיסים אמיתיים בשלב הזה.
- כתיבת ה-prompt הנכון לכלי הוויב קודינג. ה-prompt חייב לכלול במפורש: שימוש בסביבת Sandbox, קריאות API דרך serverless בלבד, ולידציה של webhook signature, וטיפול בקודי שגיאה ספציפיים.
- הוספת backend endpoint. Vercel Function או Supabase Edge Function שמתווכים בין הקונה לחברת הסליקה. כל הקריאות עוברות דרכו.
- בדיקת תהליך עם כרטיסי בדיקה. כרטיסי Sandbox של חברת הסליקה כוללים תרחישים: תשלום מוצלח, כרטיס פג תוקף, יתרה לא מספיקה. לבדוק את כל המסלולים לפני production.
- החלפה ל-Production keys + ניטור. הגדרת alerting על webhook failures, transaction timeouts וקריאות API שנכשלות.
כמה זה עולה? תמחור סליקה לאפליקציות
לאפליקציה וייב-קודית בשלב MVP, מודל "לא סלקת לא שילמת" (אפס דמי מנוי, רק עמלה לעסקה) הוא לרוב הנכון ביותר. בשלב MVP אין לך עדיין נפח עסקאות יציב, ומנוי קבוע של 99 ₪ לחודש שבו לא היו עסקאות הוא בזבוז.
המחירון של איזיקארד כולל את המסלול הזה כברירת מחדל. השוואה מפורטת בין כל מודלי התמחור של חברות סליקה בישראל נמצאת במדריך מודלי התמחור.
איזיקארד היא שותף הסליקה למפתחים ולא-מפתחים בישראל — תיעוד API מסודר, סביבת Sandbox מלאה, ותמיכה בעברית למי שתקוע בשלב האינטגרציה.
שאלות נפוצות
האם אפשר להשתמש ב-Stripe בישראל?
לא ישירות. Stripe לא מקבל חברות עם רישום עסקי ישראלי. הפתרון העוקף הוא לפתוח חברה זרה (אסטוניה, דלאוור, בריטניה) ולעבוד מולה, אבל זה כרוך בעלויות חודשיות גבוהות, חשבון בנק זר, וחובות דיווח כפולות.
איזה כלי וייב קודינג הכי מתאים לאינטגרציית סליקה?
כולם עובדים. ההבדל הוא באיכות ה-prompt ובמודעות שלך לאבטחה. Bolt ו-Lovable טובים יותר ל-frontend מהיר ו-UI. Cursor ו-Claude Code טובים יותר לעבודה עם backend, ניהול secrets ו-webhook validation. רוב המייקרים משלבים שני כלים.
האם אני צריך להיות PCI Compliant?
לא אם משתמשים ב-Hosted Payment Page או ב-iframe של חברת הסליקה. במקרים האלה פרטי הכרטיס לא נוגעים בשרת שלך והאחריות על PCI נופלת על חברת הסליקה. כן אם בונים ידנית את טופס הזנת הכרטיס בקוד שלך — אז נכנסים לחובות PCI מלאות.
כמה זמן לוקח לחבר סליקה לאפליקציה וייב-קודית?
עם Hosted Payment Page: 30 דקות עד שעה לאפליקציה פשוטה, שעתיים-שלוש לאפליקציה עם לוגיקה. עם REST API: 2-4 שעות כולל בדיקות ב-Sandbox. עם SDK native: 4-8 שעות תלוי בפלטפורמה.
מה לעשות אם ה-AI כתב קוד עם secret key חשוף?
לעצור הכל, לסובב מיד את המפתחות מול חברת הסליקה (במחיקה של המפתח הישן והנפקה של חדש). להעביר את כל הקריאות לחברת הסליקה לbackend או serverless. לבדוק ב-DevTools שלא חוזרת חשיפה אחרי התיקון. אם המפתח החשוף היה ב-production ויש סיכוי שמישהו השתמש בו לבדוק היסטוריית עסקאות.
האם אפשר לקבל ביט וגוגל פיי ב-API?
כן. חברות סליקה ישראליות תומכות בכל אמצעי התשלום המקומיים (אשראי, ביט, Apple Pay, Google Pay) דרך אותו API. הלקוח בוחר את אמצעי התשלום בעמוד התשלום עצמו — אתה לא צריך לטפל בזה בקוד.
מקורות
[1] Stripe – Stripe Global Availability. דף רשמי של Stripe על המדינות הפעילות. ישראל אינה ברשימה לעסקים מקומיים.
[2] PCI Security Standards Council – Official Site. הגוף שמגדיר את תקן ה-PCI DSS Level 1 שמחייב את כל מעבדי כרטיסי האשראי בעולם.
[3] Wikipedia – Vibe Coding. הגדרת המונח, ההיסטוריה והכלים המרכזיים. ערך הוקם ב-2025.