איך להוסיף תשלומים לאתר: Bit, אשראי ו-PayPal ב-WordPress, Shopify וקוד מותאם (2026)

תשלומים, לא קסם

״תוסיפו לי Bit ואשראי״ נשמע כמו שורה אחת. בפועל זה תהליך, אבטחה, ו-webhook שמעדכן את ההזמנה.

בשיחות עם לקוחות אני שומע: ״האתר כבר מוכן, רק חסר תשלום״. לפעמים זה באמת תוסף ב-Shopify. לפעמים זה שבוע עבודה עם redirect, webhook, בדיקות sandbox, וטיפול במקרה שהלקוח סגר את הדפדפן לפני שהשרת קיבל אישור.

המדריך הזה נכתב כדי לעזור לכם באמת - בין אם אתם בונים לבד, בין אם יש לכם מפתח, ובין אם אתם רק רוצים להבין מה קורה מאחורי כפתור ״שלם עכשיו״. אני נאור, ובניתי חנויות ומערכות תשלום עם PayPal, Stripe, סליקה ישראלית, Bit, KashCash ו-iCount. אם חיבורים בין מערכות מרגישים לכם מוזרים, יש גם מאמר נפרד על אינטגרציה ו-API - כאן המיקוד הוא כסף שנכנס לאתר.

1) Redirect - הלקוח עובר לדף של ספק התשלום

הכי נפוץ והכי בטוח להתחיל. לוחצים ״שלם״, עוברים ל-PayPal / Stripe Checkout / דף סליקה / Bit, משלמים, וחוזרים לאתר שלכם. היתרון: פרטי כרטיס לא עוברים בשרת שלכם. החיסרון: צריך לטפל בחזרה + webhook, לא רק ב״תודה שקניתם״.

2) Embedded / Hosted fields - טופס בתוך האתר, שדות אצל הספק

הדף נראה שלכם, אבל שדות האשראי נטענים מ-Stripe Elements, PayPal, או iframe של חברת סליקה. עדיין לא שומרים מספר כרטיס ב-DB שלכם. דורש JavaScript נכון ו-CSP שלא חוסם scripts.

3) API ישיר (נדיר לעסק קטן)

השרת שלכם שולח את פרטי התשלום ישירות לספק. זה מגיע עם PCI DSS, אחריות משפטית, ותשתית שרוב העסקים לא צריכים. אם מישהו מציע לכם ״נשמור כרטיס בטבלה שלנו״ - עצרו ושאלו שאלות.

• Webhook / IPN: הספק שולח לשרת שלכם POST כשהתשלום אושר (או נכשל). זה מקור האמת, לא דף ״תודה״.
• Return URL: הלקוח חוזר לדף הצלחה. יפה ל-UX, אבל הוא יכול לסגור טאב לפני שה-webhook הגיע.
• Sandbox / Test mode: סביבת בדיקות. תמיד תבדקו שם לפני live.
• Idempotency: אותו webhook יכול להגיע פעמיים. הקוד שלכם לא צריך ליצור שתי הזמנות.
• HTTPS: חובה. בלי SSL תקין, ספקי תשלום לא יעבדו (ובצדק).

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

תרחיש א׳ - חנות Shopify / WooCommerce שכבר באוויר

יש מוצרים, עגלת קניות, דפי מוצר. חסר רק ״לקבל כסף״. כאן בדרך כלל מספיק הפעלה בפאנל + תוסף סליקה/Bit + הזמנת test. אל תבנו checkout מותאם מאפס - זה בזבוז. התמקדו בבחירת ספק (עמלות, מטבע, תמיכה), והגדרת webhook אם התוסף דורש URL ידני.

תרחיש ב׳ - אתר תדמית / WordPress בלי חנות

רוצים לקבל תשלום חד-פעמי: ייעוץ, הרשמה לקורס, דמי מקדמה. PayPal Smart Buttons או Stripe Payment Link יכולים לעבוד בלי WooCommerce. אם בעתיד תרצו 50 מוצרים ומלאי - עדיף לעבור ל-WooCommerce או Shopify לפני שמצטבר technical debt.

תרחיש ג׳ - מערכת מותאמת (PHP, Laravel, Next.js)

יש לוגיקה עסקית משלכם: מנויים, הזמנות מורכבות, חיבור ל-CRM. כאן redirect + webhook הוא הסטנדרט. תכננו מראש: טבלת הזמנות עם סטטוסים, endpoint ל-webhook, idempotency, ולוגים. בפרויקטים כאלה גם חשבוניות (iCount וכד׳) ו-KashCash/Bit נכנסים לזרימה אחת - לא כפתורים מנותקים.

ב-Shopify, רוב העסקים מתחילים כך:

1. Settings → Payments - הפעלת Shopify Payments (אם זמין באזור שלכם) או ספק חיצוני.
2. PayPal - לרוב הפעלה בקליק, PayPal מנהל redirect ו-webhooks ביניכם לבין Shopify.
3. Bit / סליקה מקומית - לעיתים דרך אפליקציה ב-Shopify App Store. בדקו ביקורות, עמלות, ותמיכה בעברית.

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

אם יש לכם חנות WooCommerce:

1. WooCommerce → Settings → Payments - הפעילו שיטות (PayPal, Stripe, העברה בנקאית).
2. סליקה ישראלית / Bit: חפשו תוסף רשמי מהסולק (Cardcom, Tranzila, Hyp וכו׳) או פתרון מוכר בקהילה. קראו מתי התוסף עודכן לאחרונה.
3. Webhook: רוב התוספים מטפלים. אחרי התקנה - עשו הזמנת test וודאו שהסטטוס עובר מ-pending ל-paid.

אתר WordPress בלי WooCommerce? אפשר PayPal Smart Buttons או Stripe Checkout עם תוסף קל, אבל לחנות אמיתית WooCommerce (או פלטפורמה אחרת) חוסך כאב ראש.

כשבונים מאפס (PHP, Laravel, או backend דומה), הזרימה בדרך כלל כך:

1. יצירת הזמנה בסטטוס pending - לפני תשלום.
2. יצירת session תשלום אצל הספק (Stripe Checkout Session, PayPal Order, redirect לסליקה).
3. הפניה של הלקוח ל-URL שהתקבל.
4. Webhook מגיע ל-/api/payment/webhook - מאמת חתימה, מעדכן הזמנה ל-paid, מוריד מלאי, שולח מייל.
5. Return URL - מציג ״תודה״, אבל לא סומכים רק עליו.

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

ב-frontend מודרני, הכלל הוא: סודות רק בשרת.

• API Route / Server Action (Next.js) - יוצר את session התשלום עם secret key.
• ה-client מקבל רק client_secret או URL redirect - לא API keys.
• Webhook - endpoint נפרד, לעיתים ב-serverless. חשוב: cold start לא אמור לשבור אימות חתימה.
• Environment variables ב-Vercel / hosting - STRIPE_SECRET, PAYPAL_CLIENT_SECRET. לא ב-GitHub.

Stripe ו-PayPal שניהם עובדים מצוין עם Next.js. הספריות הרשמיות מעודכנות - תמיד עקבו אחרי docs הרשמי, לא מדריך בלוג מ-2023.

PayPal מתאים כש:

• יש לכם לקוחות בחו״ל או שמעדיפים לא להקליד כרטיס.
• אתם רוצים checkout מהיר בלי להירשם אצל סולק מקומי.

שלבים:

1. חשבון PayPal Business + Developer App.
2. בחירה בין PayPal Checkout (מומלץ) ל-buttons ישנים.
3. הגדרת Webhook ל-PAYMENT.CAPTURE.COMPLETED (או אירועים רלוונטיים בגרסה שלכם).
4. בדיקה ב-Sandbox עם חשבונות test.

טעות נפוצה: לסמן הזמנה כשולמה רק כי הלקוח חזר ל-return URL. PayPal שולח webhook - תשתמשו בו.

Stripe (כרטיסים בינלאומיים)

Stripe Checkout הוא דרך מצוינת להתחיל: redirect, 3D Secure, webhook events ברורים. מתאים ל-SaaS, חנויות דיגיטל, מנויים. בדקו אם Stripe תומך במדינה ובמטבע שלכם.

סולקים ישראליים (Hyp, Tranzila, Cardcom, PayPlus ועוד)

לעסק ישראלי שרוב הלקוחות מקומיים, לרוב עובדים עם חברת סליקה מקומית - redirect לדף תשלום או iframe. כל סולק עם API/API docs שונה. מה שמשותף:

• מסוף / terminal ID / merchant ID - שומרים ב-env.
• מצב test לפני live.
• webhook או callback URL שמאשר עסקה.
• חשבונית מס - לעיתים דרך iCount, Green Invoice, או מודול נפרד (בפרויקטים שלי זה חלק מהזרימה).

Bit פופולרי בישראל כי הלקוח כבר מכיר. טכנית זה לא ״כפתור שמדביקים״ - יש API עסקי, הרשאות, ולעיתים redirect או QR.

• WooCommerce / Shopify: בדרך כלל תוסף מהחנות. בדקו תאימות גרסה.
• קוד מותאם: פונים ל-Bit לעסקים, מקבלים credentials, מממשים לפי documentation עדכני.
• חשוב: לטפל ב-webhook/callback כמו בכל תשלום - לא לסמן שולם לפני אישור.

Bit לא מחליף אשראי לכל קהל - הרבה עסקים מציעים שניהם ונותנים ללקוח לבחור.

תשלום מוצלח הוא אמצעי, לא סוף:

• עדכון סטטוס הזמנה ב-DB (paid / failed).
• מייל אישור ללקוח (ומייל פנימי לעסק).
• חשבונית / קבלה - אם חוקית רלוונטית, אוטומציה ל-iCount / Green Invoice / מערכת דומה.
• מלאי / גישה דיגיטלית - רק אחרי webhook מאושר, לא אחרי click.
• לוג - transaction ID, סכום, timestamp - לתמיכה ולחשבונות.

במאמר על מה מקבלים בסוף פרויקט כתבתי מה לקוח אמור לקבל כשהכל מחובר - כולל גישות לספקי תשלום.

• לסמוך רק על return URL - הלקוח סגר דפדפן, webhook הגיע אחרי דקה. בלי webhook אתם מפסידים הזמנות.
• Secret key ב-JavaScript - כל מי שפותח DevTools רואה. game over.
• לא לבדוק sandbox - ב-live מתגלים edge cases יקרים.
• Webhook בלי אימות חתימה - מישהו יכול לשלוח POST מזויף ולסמן הזמנות כשולמו.
• סכום מה-client בלי אימות - תמיד לחשב מחדש בשרת לפני יצירת תשלום.
• שכחתם מ-mobile - redirect ל-PayPal/Bit על iPhone חייב לעבוד חלק.

1. HTTPS תקין על כל האתר (כולל www / non-www).
2. תשלום test עבר - כולל ביטול / כישלון מכוון.
3. Webhook מגיע ומתעד ב-log.
4. הזמנה כפולה מאותו webhook - לא נוצרת (idempotency).
5. מייל אישור נשלח.
6. מדיניות החזרות / ביטול מוצגת ללקוח.
7. מפתחות live ב-production, test ב-staging - לא מעורבבים.

להוסיף תשלומים לאתר זה לא ״תוסף כפתור״. זה תהליך מאובטח: redirect או embedded, webhook שמעדכן את האמת, ו-aftermath של מייל, חשבונית, ומלאי. ב-Shopify ו-WooCommerce הרבה כבר מובנה. בקוד מותאם - אתם בונים, אבל גם שולטים.

אם אתם על WordPress / Shopify - התחילו מהפאנל, תעשו test order, תבדקו webhook. אם אתם על PHP / React - תבנו sandbox קודם, secret ב-server בלבד, ואל תדלגו על אימות חתימה.