אינטגרציה של YooKassa באתר: קבלת תשלומים תוך 3–7 ימים

אינטגרציה של ЮKassa: היכן נשברת קליטת התשלומים באתר

התקלה היקרה ביותר בקליטת תשלומים באתר נראית שקטה: הלקוח לוחץ על «שלם», הכסף מחויב, אך ההזמנה במערכת לא מופיעה. בפאנל הספק התשלום מוצג כירוק, אצלכם — «ממתין לאישור», ועד לפנייה הראשונה לתמיכה איש לא יודע על כך. המחיר של תקלה כזו — תשלומים חוזרים של אלה ששילמו פעמיים, וטיפול ידני בכל מקרה.

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

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

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

מה משתנה לאחר חיבור קליטת התשלומים באתר

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

שיעור התשלומים המוצלחים עולה בזכות כך שהלקוח רואה את סיבת הסירוב מיד ומשלם בדרך אחרת, בלי לאבד את הסל ובלי להתחיל את ההזמנה מחדש.

זמן זיכוי הכספים מפסיק להיות תלוי בייצוא ידני. השירות שולח התראה על שינוי סטטוס, המערכת מסמנת את ההזמנה כשולמה ומפעילה אספקת מוצר או גישה; ההתאמה מתבצעת לפי מזהה תשלום, ולא לפי סכום ותאריך. סוג הפערים «הכסף הגיע, ההזמנה לא שולמה» נעלם יחד עם החיפוש הידני בדוח התנועות.

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

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

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

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

אינטגרציה של ЮKassa: דרכי חיבור והמגבלות שלהן

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

המגבלות מתגלות לא בתשלום בדיקה, אלא בהחזרים, בתשלומים חלקיים ובחיובים חוזרים. להלן חלופות אמיתיות שבין בחירה בעת החיבור.

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

כיצד מתבצע חיבור מודול התשלומים: שלבי העבודה

מודול התשלומים אינו כפתור «שלם» בדף הסל, אלא מעגל שמשנה את מצב ההזמנה, מתעד את הכסף וחוזר לאחור כראוי בעת תקלה. לכן מתחילים לא בקוד, אלא בביקורת: כיצד בנויה ההזמנה כעת, מי מחשב את הסכום, היכן מאוחסנים הסטטוסים ומה קורה להזמנה אם התשלום לא עבר.

1. ביקורת תרשים ההזמנה. מנתחים כיצד נוצרת ההזמנה, היכן נשמרים הסכומים והסטטוסים, כיצד נלקחים בחשבון הנחות ומשלוח. מסמנים מקומות שבהם הסכום לתשלום עלול לסטות מהסכום בפועל.
2. תכנון תרחיש התשלום. מתארים את כל המסלול: בחירת אמצעי תשלום, יצירת תשלום, שריון ההזמנה עד לאישור, ניסיון חוזר לאחר סירוב הבנק, החזר. מתעדים מה רואה הקונה אם יסגור את הדף ברגע התשלום.
3. הגדרת קליטת התשלום. מחברים את החנות ב-ЮKassa, מגדירים מפתחות, אמצעי תשלום זמינים, קבלות והעברת נתונים למערכת החשבונאית.
4. בדיקת תרחישי תשלום. בסביבת בדיקות מריצים תשלום מוצלח, סירוב, תשלום שהופסק, התראה חוזרת והחזר. בנפרד בודקים שהתראה חוזרת אינה יוצרת הזמנה שנייה.
5. מסירת הרשאות. מוסרים חשבון אישי ומפתחות, מחלקים תפקידים, מראים כיצד לבצע החזר ולטפל בתשלום שנוי במחלוקת.
6. מסירת הפרויקט. מוסרים תרשים מעבר התשלום ותיעוד ההגדרות, מדריכים את עובדי התמיכה, נשארים בקשר בתקופת הליווי.

מסלול כזה מסיר את הסיכון העיקרי — «הכסף חויב, אך ההזמנה אינה קיימת». חיבור לפי תרשים זה נמשך 3–7 ימים.

הרכב התיעוד והתצורות הנמסרים

מערך התיעוד נאסף תוך כדי העבודה, ולא לאחר ההשקה: כל תרחיש מוגדר מתועד מיד בתיאור, כדי שכעבור חצי שנה איש לא ישחזר את הלוגיקה מתוך הקוד. להלן מה בדיוק נשאר אצל המזמין לאחר המסירה.

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

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

ניתוח פרויקט: כיצד צמצמנו את שיעור התשלומים הכושלים

הפרויקט — חנות מקוונת עם תשלום בכרטיס ודרך СБП, התשלומים עברו דרך ЮKassa. בצד האתר הטיפול בתוצאה הצטמצם למעבר לדף «תודה»: אם התשלום לא עבר, הלקוח ראה שגיאה כללית, חזר לסל ולרוב עזב.

מה הראו המדדים לפני

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

מה עיבדנו מחדש

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

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

מה היה לאחר מכן

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

במה קישור לתשלום שונה מטופס באתר?

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

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

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

שאלות טכניות נפוצות בנושא חיבור התשלום

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

מספר דומיינים — תשלום בכל אחד?

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

האם יש מצב בדיקה לתשלום?

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

מי אחראי לתקלה בצד הבנק?

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

מה קורה לתשלום בעת השבתת האתר?

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

נדון במשימה: מה לשלוח להערכה ולתוכנית

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

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

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