תיאום רכישות משותפות בין מספר רוכשים מציב אתגרים טכנולוגיים מורכבים בפני פלטפורמות מסחר דיגיטלי בישראל. הטמעת אינטגרציית Grow ו-Pelecard לתשלומים קבוצתיים בארכיטקטורות ווב מודרניות דורשת תזמור של שני מודלים שונים לביצוע עסקאות: טוקניזציה ישירה של אשראי וקישורי הפצה אסינכרוניים. בעת פיתוח ב-Next.js, על צוותי ההנדסה להקים מכונות מצבים עמידות בצד השרת כדי לאזן מאגרי קופה מבוזרים לפני סילוק היתרות המשותפות.
מדריך זה בוחן את ארכיטקטורת הליבה הנדרשת לביצוע פיצול תשלומים בין תשתית סליקת האשראי של Pelecard לבין שירות הפצת התשלומים של Grow. נסקור כיצד לנהל אישורים חלקיים, למנוע אי-התאמות בספרי חשבונות, ולשמור על תאימות לתקן PCI בעגלות של תשלומים קבוצתיים מרובי משתתפים בהיקפי פעילות גבוהים.
מדוע שערי תשלומים ישראליים סטנדרטיים מתקשים עם תשלומים קבוצתיים מרובי משתתפים?
האתגר המרכזי: שערי תשלומים למשלם יחיד מול עגלות קבוצתיות מבוזרות
שערי תשלומים סטנדרטיים בישראל פועלים על פי פרדיגמה סינכרונית קשיחה: משלם יחיד מזין פרטי תשלום, Shva מבצעת סליקה לעסקה, וההזמנה מושלמת באופן מיידי. פיצול תשלומים בשער תשלומים ישראלי שובר את הרצף הטורי הזה על ידי הפרדת יצירת ההזמנה מסילוק מלא ומיידי. כאשר מספר לקוחות מחלקים ביניהם חשבונית — כגון חשבונות משותפים במסעדות ואירוח, הוצאות תאגידיות או הזמנות נסיעה קבוצתיות — עגלת הקניות חייבת להישאר בסטטוס ממתין בזמן שטוקני תשלום נפרדים מתקבלים לאורך דקות או שעות.
טוקניזציה ב-Pelecard מול הפצת קישורים ב-Grow: הגדרת תפקידי שערי התשלום
מהנדסים המפתחים אינטגרציית Grow ו-Pelecard לתשלומים קבוצתיים חייבים להקפיד על הפרדת תחומי אחריות ברורה בין עיבוד התשלומים לבין ערוצי התקשורת. Pelecard משמשת כשער סליקה בתקן PCI DSS Level 1, ומנהלת טוקניזציה ישירה של כרטיסים, השהיות אישור J4, וסליקת אשראי סטנדרטית מול Shva. לעומת זאת, Grow פועלת כשכבת הפצה אינטראקטיבית, המייצרת קישורי תשלום מקומיים הנשלחים ב-SMS, ב-WhatsApp ובערוצי הודעות למשלמים המשניים.
במקום לחייב כל משתתף לעבור דרך קופה מרכזית ומונוליתית, המערכת מפיקה קישורי צ'ק-אאוט ייחודיים של Grow עבור עסקאות זעירות, בעוד Pelecard שומרת בכספת מאובטחת את נתוני החיוב הראשיים. תזמור מודולרי זה יוצר מאגר ספרי חשבונות מבודד לפני אישור ההזמנה הסופי.
כיצד לתכנן ארכיטקטורה של אינטגרציית Grow ו-Pelecard לתשלומים קבוצתיים?
תזמור מצבים: ניהול מאגרי תשלום משותפים ומצבי ספרי חשבונות מפוצלים
תיאום תשלומים קבוצתיים מרובי משתתפים דורש מכונות מצבים טרנזקציוניות מפורשות. הזמנת האב נותרת במצב לא סופי (uncommitted) כל עוד נאספים תשלומי החלק היחסי של המשתתפים. צד השרת עוקב אחר מאגר זמני (ephemeral pool) לאורך מצבים מוגדרים: INITIALIZED, COLLECTING, FULLY_FUNDED, SETTLING ו-EXPIRED.
היתרה של כל משתתף מנוטרת באופן עצמאי אל מול סכום היעד הכולל. שמירת ההתחייבויות במסד נתונים יחסי עם נעילת שורות (row-level locking) מבטיחה שתשלומים מקבילים לא ייצרו מצבי מרוץ (race conditions). ברגע שהסכום שנאסף מגיע לסך היעד, ההזמנה עוברת לביצוע סליקה והתחשבנות.
טוקניזציה J4 פלאקארד ותהליכי עבודה עם קישורי תשלום ישירים של Grow
ארכיטקטורות מודרניות של פיצול תשלומים Grow ו-Pelecard מפרידות בין האחריות הראשית לבין השתתפות מבוזרת. באמצעות טוקניזציה J4 פלאקארד לפיצול חיובים, יוזם הקבוצה שומר טוקן J4 לשימוש חוזר באמצעות תפיסת מסגרת ראשונית (authorization hold). טוקן זה מבטיח את ההזמנה או מכסה יתרות שלא שולמו במקרה של כשל בתשלום מצד משתתפים משניים.
במקביל, צד השרת מפעיל מטפלי נתיבים (Route Handlers) ופונה לשירות Grow payment API ב-Next.js כדי להפיק כתובות URL ייעודיות לעסקה עבור משלמים משניים. כל קישור כולל טוקן ייעודי עם טווח הרשאות מוגדר (scoped token) המשויך לרשומה בספרי חשבונות מפוצלים, ומאפשר למשתתפים לשלם באמצעות ארנקים דיגיטליים או ערוצי סליקה מקומיים ללא צורך בהרשמה. ככל שהמשתתפים משלימים את התשלום, הפלטפורמה מבצעת התאמת ספרי חשבונות וקבלות לפני עדכון אישורים חלקיים או שחרור תפיסת המסגרת של המארח ב-Pelecard.
מידול נתונים: מעקב אחר תשלומי משתתפים וסטטוסי סליקה והתחשבנות
סכמה יציבה דורשת שלוש ישויות ליבה: GroupOrder, PaymentPool ו-ContributionRecord. כל תשלום מתעד את ספק שער התשלומים (gateway provider), מזהה העסקה, הסכום וסטטוס הסליקה וההתחשבנות:
| מאפיין הישות | סוג נתונים | מטרה תפעולית |
|---|---|---|
pool_id | UUID | מאגד עסקאות קשורות תחת תהליך תשלום (checkout) ראשי אחד. |
gateway_type | Enum (Pelecard / Grow) | מזהה נתיבי סליקה לצורך התאמת ספרי חשבונות ווובהוקים (webhook reconciliation). |
authorization_status | Enum | עוקב אחר המצב החל מ-PENDING ועד CAPTURED או VOIDED. |
settled_amount_cents | Integer | שומר על דיוק של מספר שלם לניהול ספרי חשבונות ללא אובדן עשרוני במטבע. |
מבנה יחסי זה מבטיח יכולת ביקורת מלאה ומעקב מתועד לאורך כל אירועי הסליקה וההתחשבנות המפוצלים.
כיצד מיישמים אינטגרציית Grow ו-Pelecard לתשלומים קבוצתיים עם פיצול תשלומים ב-Next.js צעד אחר צעד?
יצירת נתיבי API ב-Next.js להפקת טוקנים ב-Pelecard
הטמעה של אינטגרציית סליקה Next.js פלאקארד עבור תשלומים קבוצתיים מרובי משתתפים מתחילה בסביבת השרת של Next.js באמצעות מטפלי נתיבים (Route Handlers) ייעודיים. במסגרת סליקת Shva ב-Next.js, רכיבי לקוח לעולם אינם צריכים לתקשר ישירות עם נקודות קצה של סליקה באמצעות פרטי הזדהות פרטיים של שער תשלומים. במקום זאת, נתיב API — כגון app/api/payments/pelecard/tokenize/route.ts — מבצע אימות מול שער התשלומים של Pelecard באמצעות משתני סביבה מאובטחים בצד השרת, הכוללים את מספר המסוף, פרטי המשתמש ומפתחות ה-API הסודיים.
הנתיב מקבל את הפרמטרים הראשוניים של סשן הצ'ק-אאוט, מאמת את חתימות הבקשה ויוזם בקשת טוקניזציה J4 פלאקארד לאישור מוקדם. Pelecard מחזירה מזהה סשן וכתובת URL של iframe לאיסוף מאובטח של נתוני כרטיס האשראי, בהתאם לתקני PCI DSS Level 1. עם הזנה מוצלחת של פרטי הכרטיס בתוך הפריים המוטמע, Pelecard מעבירה טוקן לשימוש חוזר וקוד אישור חזרה ל-Callback בשרת שלכם, ובכך מעגנת את התחייבות המשלם הראשי מבלי לשמור מספרי כרטיס אשראי רגישים (Primary Account Numbers - PAN) במסד הנתונים של האפליקציה.
יצירה והפצה של קישורי תשלום דינמיים ב-Grow
כחלק מתוך מדריך API פלאקארד ו-Grow, משתתפים משניים מקבלים קישורי תשלום ייעודיים במקום לבצע פעולות ישירות מול סשן הצ'ק-אאוט הראשי. פעולת צד-שרת (Server Action) מתשאלת את ספרי החשבונות המפוצלים, מחלקת את יתרת סכום ההזמנה בין המשתתפים שהוגדרו לצורך פיצול תשלומים Grow ו-Pelecard, ופונה לנקודת הקצה של Grow להפקת הקישורים.
גוף הבקשה (Payload) מגדיר את פרמטרי חשבון המשנה, קוד המטבע, פריטי ההזמנה ומטא-דאטה ייחודית של העסקה המקשרת חזרה למזהה הקבוצה המשותפת (Group pool ID). Next.js מעבדת את התגובה מ-Grow, מחלצת את כתובת ה-URL של דף התשלום המאוחסן ושולחת אותה למשתתפים בערוצי התראות כגון SMS אוטומטי, הוקים להודעות מיידיות (Messaging hooks) או הודעות דוא"ל מהמערכת. כל קישור מפנה את המשתתף לפורטל תשלום נפרד ומותאם למובייל, המוגדר לזיכוי העגלה המשותפת.
בניית מטפלי Webhook לעדכוני סטטוס תשלום אסינכרוניים
מכיוון שמשתתפים במסגרת תשלומים קבוצתיים מרובי משתתפים מסדירים את התשלומים בטווחי זמן שונים, על מטפלי נתיבים (Route Handlers) ב-Next.js לעבד קריאות חוזרות (Callbacks) אסינכרוניות הנכנסות משני שערי התשלומים. מטפל ה-Webhook בנתיב app/api/webhooks/payments/route.ts משמש כנקודת קליטה מרכזית לאירועים, ומבצע נרמול של מבני ה-Callback מ-Pelecard ומ-Grow לאירוע דומיין אחיד.
כאשר משתתף משלים תשלום דרך Grow, השירות שולח Webhook חתום. המטפל ב-Next.js מאמת את החתימה הדיגיטלית, מחלץ את קוד האישור וסכום העסקה, ומבצע עדכון אטומי בספר החשבונות שבמסד הנתונים. לאחר מכן, השירות מעריך את יתרת הקופה המצטברת: אם התשלומים שנאספו מכסים את סכום היעד הכולל של ההזמנה, המערכת מעבירה את ההזמנה לסטטוס "הושלם" ומפעילה את תהליך האספקה (Fulfillment). אם תשלום נכשל או שתוקפו פג, ה-Webhook רושם את האירוע ומתריע למנהל הקופה לצורך הקצאה מחדש של היתרה.
כיצד מתמודדים עם אישורים חלקיים, פקיעת זמן (Timeouts) והתאמת ספרי חשבונות?
ניהול מצבי מרוץ (Race Conditions) ואידמפוטנטיות באישורים חלקיים
בתרחישי עומס גבוה של אינטגרציית Grow ו-Pelecard לתשלומים קבוצתיים, מספר משתתפים עשויים לשלוח תשלומים בו-זמנית, או ש-Webhooks של שער התשלומים ינסו לבצע מסירה חוזרת בעקבות השהיית רשת. ללא מנגנוני הגנה ובקרה, בקשות מקביליות עלולות לגרום למצבי מרוץ (Race Conditions), שיובילו לגביית יתר או לרישום כפול של זיכויים בספרי החשבונות.
כדי להבטיח עקביות, כל עסקת השתתפות חייבת לדרוש מפתח אידמפוטנטיות (Idempotency Key) שנוצר בעת הפקת הקישור. בעת עיבוד קריאות חוזרות (Callbacks) של אישורים ב-Next.js, עדכוני מסד הנתונים צריכים להתבצע בתוך טרנזקציות מסוג Serializable, תוך שימוש בנעילת שורות (SELECT ... FOR UPDATE) על רשומת המאגר הראשית (Parent Pool). במידה ומתקבל Payload כפול של Webhook, מסד הנתונים מאמת את מזהה העסקה הקיים ומאשר את קבלת האירוע מבלי לשנות את יתרות ספרי החשבונות.
אוטומציה של פקיעת תוקף, ביטולים חלקיים וביצוע Rollback
לא כל תהליך תשלום קבוצתי מגיע לכדי מימון מלא. מערכות המיישמות טוקניזציה J4 פלאקארד לפיצול תשלומים חייבות להגדיר זמן חיים (TTL) אוטומטי לכל עגלת קניות משותפת. במידה ומשתתפים משניים אינם משלימים את מלוא היתרה לפני פקיעת התוקף, הפלטפורמה מפעילה תהליכי ביטול והחזרה (Reversals) אוטומטיים.
תהליכי Worker מתוזמנים מזהים מאגרים שפג תוקפם ומפעילים ביצוע Rollback אוטומטי. עבור משלמים ראשיים המחזיקים באישור מסוג Pelecard J4, המערכת מנפיקה בקשת ביטול (Void) לשחרור תפיסת המסגרת ללא חיוב בעמלות סליקה צולבות (Interchange Fees). עבור עסקאות Grow שנסלקו, השירות מפעיל בקשות זיכוי (Refund) אוטומטיות מול מזהי התשלום הייחודיים, מחזיר את הכספים למשתתפים ומסמן את המאגר כ-VOIDED.
איזון ספרי חשבונות ברישום כפול והפקת חשבוניות מס בישראל
עמידה בדרישות הרגולציה הפיננסית מחייבת שכל עסקה במסגרת תשלומים קבוצתיים מרובי משתתפים תתאזן בספר חשבונות רשמי ברישום כפול (Double-entry ledger). כנגד כל זיכוי שנרשם בחשבון המשנה של משתתף, יש לרשום חיוב שווה ערך בחשבון נכסי הסליקה של שער התשלומים. שמירה על ערכי אגורות כמספרים שלמים מונעת שגיאות עיגול שבריות בעת חלוקת ההקצאות המפוצלות.
יתרה מכך, עמידה בדיני המס בישראל מחייבת הפקת מסמכי מס דיגיטליים תקפים (חשבונית מס / קבלה) המוכרים על ידי רשות המסים בישראל. ברגע שהמאגר מגיע להתחשבנות וסליקה מלאה, האינטגרציה מנהלת את הפקת החשבוניות — בין אם באמצעות הנפקת קבלות נפרדות עבור חלקו של כל משתתף ובין אם בהפקת חשבונית מס מרוכזת לבעל ההזמנה הראשי. סנכרון ישיר של מזהי עסקאות משער התשלומים מול ממשקי API מוסמכים להפקת חשבוניות בישראל מבטיח דיווח מס תקין ותיעוד הניתן לביקורת.
היכן יצירת שלד קוד באמצעות AI כושלת בבניית תהליכי תשלום ב-FinTech?
מה מאיצים סוכני פיתוח מבוססי AI: קוד תבניתי (Boilerplate), הגדרות טיפוסים ומטפלי נתיבים (Route Handlers)
בפיתוח תשתיות תשלום מורכבות, סוכני פיתוח מבוססי AI מאיצים משמעותית את שלבי ההטמעה הראשוניים. הפקת אימותי סכמה קפדניים באמצעות Zod, הגדרת ממשקי TypeScript מדויקים עבור מטעני נתונים של סליקת Shva ב-Next.js, והקמת שלד תבניתי לנקודות קצה עבור אינטגרציית API התשלומים של Grow ב-Next.js – את כל אלה ניתן להשלים בתוך דקות במקום ימים. צוותי הנדסה נעזרים בסוכני פיתוח אלו כדי להפיק פונקציות מיפוי שגרתיות, כלי עזר סטנדרטיים לאימות חתימות של webhooks, ורכיבי תשלום מדומים (mock payment stubs) לבדיקות יחידה.
פגיעויות ב-FinTech: מדוע AI מחמיץ מקרי קצה בשער תשלומים ואבטחת PCI
למרות התפוקה המהירה של יצירת שלד הקוד באמצעות AI, מודלים אוטומטיים מתקשים בהתמודדות עם מקרי קצה קריטיים בעולמות ה-FinTech. כפי שניתן לראות ביישומים טכניים של מדריך API פלאקארד ו-Grow, קוד שנוצר על ידי AI מניח לעיתים קרובות אמינות רשת במסלול האופטימלי (happy-path). הוא מחמיץ באופן שיטתי נקודות תורפה עדינות: השמטת נעילות מבוזרות (distributed locks) בזמן גביית כספים חלקית, ניהול כושל של הצפות ניסיונות חוזרים (retry storms) ב-webhooks, או טיפול לקוי בנתונים רגישים של בעלי כרטיסים באופן המפר את גבולות התאימות המחמירים של תקן PCI DSS.
ללא מומחיות מעמיקה בתחום, מודלים של AI מציעים פעולות מסד נתונים נאיביות שכושלו תחת עומס מקבילי, מה שיוצר אי-התאמות מסוכנות בספרי החשבונות או בקשות אישור כפולות — שגיאות שכלי ניתוח קוד (linting) סטנדרטיים אינם מסוגלים לזהות. בתוכנות פיננסיות, מצב מרוץ (race condition) שאינו מטופל מוביל ישירות לכספים שלא ניתן לגבות או לחיוב כפול של לקוחות.
פיקוח הנדסי אנושי: סקירת ארכיטקטורה, מקביליות ובקרת שחרור גרסאות
אף על פי שכלי פיתוח מבוססי AI מאיצים את תהליך ההנדסה, מהנדסים אנושיים חייבים להתוות את הארכיטקטורה, לבצע סקירות קוד (code reviews) מעמיקות ולקבוע את כל אבני הדרך לשחרור גרסאות. מהנדסי תשלומים מנוסים מוודאים בידוד נתונים בסביבה מרובת דיירים (multi-tenant), מבקרים את תהליכי אימות החתימה הקריפטוגרפית, בוחנים מגבלות מקביליות תחת סימולציה של כשלי רשת, ומוודאים כי מכונות מצבים של ספרי החשבונות אוכפות ערבויות אטומיות (atomic guarantees) בטרם פריסת הקוד לסביבות ייצור (production) חיות.
אילו תקני אבטחה ואמינות נדרשים לפני השקה לסביבת ייצור?
אימות סליקת אשראי ובדיקות בסביבת Sandbox מול Shva
הטמעה של אינטגרציית צ'ק-אאוט מרובת משלמים של Pelecard ברמת פרודקשן מחייבת בדיקות קפדניות מול סביבות סליקה ב-Sandbox של Shva. על צוותי ההנדסה לאמת מקרי קצה מעבר לאישורים הסטנדרטיים: התמודדות עם אתגרי אימות ב-3D Secure, טיפול בסירובי עסקאות, זיהוי כרטיסים שפג תוקפם ואימות מגבלות תפיסת מסגרת בטוקניזציה J4. הבדיקות צריכות לוודא שכאשר כרטיס של משלם משני נדחה, המערכת מספקת טיפול מעשי בשגיאות המאפשר פעולה מתקנת, מבלי לפסול תשלומים שכבר הוסדרו בקופה המשותפת.
אימות חתימות Webhook, אחסון בכספת (Vaulting) ופרוטוקולים להגבלת קצב
אבטחה במסגרת אינטגרציית Grow ו-Pelecard לתשלומים קבוצתיים מחייבת מנגנוני הגנה רב-שכבתיים. נתיבי הקליטה ב-Next.js חייבים לאמת חתימות HMAC קריפטוגרפיות על כל מטען נתונים (Payload) של Webhook כדי למנוע התחזות (Spoofing). נתוני כרטיס אשראי גולמיים חייבים להישאר מחוץ לשרתי האפליקציה לחלוטין, תוך הסתמכות בלעדית על ייצוגים שעברו טוקניזציה ונשמרים בכספת המאובטחת של Pelecard. בנוסף, נקודות קצה ליצירת קישורים ציבוריים דורשות הגבלת קצב (Rate Limiting) מבוססת Redis כדי להתגונן מפני סריקות אוטומטיות ומתקפות מניעת שירות כספי (Denial-of-Wallet).
תיעוד ביקורת מקצה לקצה ויכולת ניטור (Observability) עבור עסקאות מרובות משתתפים
מאחר שתשלומים קבוצתיים מרובי משתתפים כוללים תלויות א-סינכרוניות, יכולת ניטור (Observability) היא חיונית. יומני ביקורת (Audit logs) מובנים צריכים לתעד כל מעבר בין מצבים, תוך הצלבת מזהי העסקה של שער התשלומים עם רשומות הקופה הפנימיות. התראות בזמן אמת עוקבות אחר אישורים יתומים (Orphaned authorizations), תפוגת זמן של קופות בהמתנה וחריגות בעיבוד Webhook, עוד לפני שהן משפיעות על התאמת ספרי חשבונות.
כיצד Canvas Developers יכולה לסייע לכם לבנות ולייצב את תשתית התשלומים שלכם?
איזון בין אספקה מואצת באמצעות AI לבין פיקוח ארכיטקטוני בכיר
Canvas Developers היא חברת הנדסת תוכנה עם משרד בדאקה, הבונה יישומי ווב מותאמים אישית, פלטפורמות SaaS ואינטגרציות תשלומים לארגונים. בארכיטקטורות מורכבות כגון אינטגרציית Grow ו-Pelecard לתשלומים קבוצתיים, אנו משתמשים בסוכני קידוד מבוססי AI כדי להאיץ משימות הנדסיות שגרתיות, בעוד שמהנדסים מנוסים מנהלים את העבודה, מובילים את ארכיטקטורת המערכת, בוחנים כל שינוי בקוד ומקבלים את החלטות הגרסה.
בין אם מדובר בבניית תהליך צ'קאאוט מותאם אישית לפיצול תשלומים מאפס ובין אם בייצוב ובהקשחה של יישום שנבנה באמצעות AI, הצוות שלנו מוודא שתהליכי העבודה של העסקאות שלכם ישמרו על שלמות קפדנית של ספרי החשבונות, אידמפוטנטיות ועמידה בתקן PCI.
התחלת הערכת אינטגרציה מוגדרת היקף בכתובת https://www.canvasdevelopers.com/contact
הנדסה של מערכות תשלומים חסינות דורשת התאמה בין תהליכי העבודה העסקיים לבין פרוטוקולים מחמירים של שער תשלומים. ההתקשרויות שלנו מול לקוחות מתנהלות לפי תהליך מוקפד: הגדרת היקף טכני מקיפה, אבני דרך מוסכמות, בדיקות QA קפדניות ומסירה מובנית לסביבת הייצור.
כדי להעריך את ארכיטקטורת התשלומים שלכם או לדון בבנייה ובייצוב של תהליכי צ'קאאוט עבור תשלומים קבוצתיים מרובי משתתפים, תאמו הערכה מוגדרת היקף באמצעות טופס יצירת הקשר בכתובת https://www.canvasdevelopers.com/contact.
שלב אחר שלב
הגדרת נתיבי API לטוקניזציה ב-Pelecard
יצירת route handlers מאובטחים בשרת ה-Next.js לצורך אימות מול Pelecard ואתחול טוקניזציה ותפיסת מסגרת J4 בהתאם לתקן PCI DSS.
הפקת קישורי תשלום דינמיים ב-Grow
שימוש ב-API התשלומים של Grow ליצירת כתובות תשלום ייעודיות עבור משתתפי המשנה בקבוצה, המשויכות למזהה מאגר מרכזי.
הטמעת מנגנוני וובהוק אסינכרוניים
אימות חתימות דיגיטליות של שערי הסליקה ועיבוד קריאות חוזרות (callbacks) על תשלומים כדי לעדכן את מאזן הקבוצה בזמן אמת.
אכיפת בקרות מקביליות ואידמפוטנטיות
הפעלת נעילת שורות במסד הנתונים ובדיקות אידמפוטנטיות למניעת תנאי מרוץ בעת גבייה מפוצלת ממשתתפים מרובים.
ביצוע התאמה סופית או ביטול אוטומטי
מימוש וסליקת היתרה הכוללת עם השלמת המימון במלואו, או הפעלת ביטולים והחזרים אוטומטיים במקרה של תפוגת עגלת הקבוצה.
