שילוב Robokassa: חתימה, פיסקליזציה ותיקון ResultURL

שילוב Robokassa: בעיות נפוצות ופתרונות

שגיאת חוסר התאמה בחתימה (bad sign) — הגורם הנפוץ ביותר לאובדן תשלומים בעת שילוב Robokassa. לאחרונה פנה אלינו חנות מקוונת: 20% מהעסקאות לא הגיעו לסטטוס שולם. גילינו — מטפל ה-ResultURL השתמש ב-Password1 במקום ב-Password2. זה עלה להם כ-1.4–1.9 אלף דולר בהכנסות אבודות בחודש. לצוות שלנו יש ניסיון של למעלה מ-10 שנים ו-53 שילובי תשלום מוצלחים, מה שמאפשר לנו להימנע מטעויות כאלה. צרו קשר — אנו נגדיר קבלת תשלומים ללא הפסדים.

Robokassa הוא אגרגטור תשלומים פופולרי ברוסיה. הגדרה נכונה של Robokassa מבטיחה תשלומים חלקים. אנו בודקים דרישות פיסקליזציה במהלך השילוב. השתמשו במצב הבדיקה של Robokassa לניפוי באגים. קבלו תשלומי כרטיסים באתר דרך Robokassa. Robokassa תומך גם ב-SBP (מערכת תשלומים מהירה) להעברות מיידיות.

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

כיצד להימנע משגיאות חתימה?

חתימה — MD5 של מחרוזת עם פרמטרים. סדר: Login:OutSum:InvId:Receipt(если есть):Password1/2. טעות נפוצה היא רווחים מיותרים או סדר שגוי. אנו משתמשים ב-hash_equals להשוואה ורושמים פרמטרים נכנסים. כפי שצוין בתיעוד Robokassa: "חתימה היא מחרוזת המתקבלת מפרמטרי בקשה המפורטים בסדר מסוים." שימוש בסיסמאות שונות — Password1 ליצירת הקישור ו-Password2 לאימות הודעות — הוא המפתח. לניפוי באגים, הפעילו רישום של כל הפרמטרים הנכנסים ב-ResultURL. ודאו שהסיסמאות בקונפיגורציה תואמות לאלה שבחשבון האישי של Robokassa.

האם פיסקליזציה היא חובה לחנויות מקוונות?

ללא פיסקליזציה, אי אפשר לקבל תשלומים באופן חוקי מיחידים לפי 54-FZ. Robokassa תומך בקופה רושמת בענן, שהיא מהירה פי 2 משכירת קופה משלך. הקבלה מועברת בפרמטר Receipt בעת יצירת הקישור. החתימה עם Receipt מחושבת כ-MD5(Login:OutSum:InvId:urlencode(Receipt):Password1). הסדר הוא קריטי. ניתן לאמת את נכונות החתימה על ידי השוואת החתימה שנוצרה עם זו שהתקבלה בקריאה החוזרת. השתמשו ב-hash_equals להגנה מפני התקפות תזמון. רשמו פרמטרים נכנסים לאבחון.

מטפל ResultURL אידמפוטנטי

Robokassa חוזר על בקשות עד לקבלת OK{InvId}. אם הסטטוס כבר שונה, עדכון חוזר יגרום לשגיאה. אנו משתמשים בעדכונים אטומיים עם נעילת רשומות. שימוש בעובד תורים לעיבוד קריאות חוזרות אמין פי 3 מגישה סינכרונית, מכיוון שהוא מונע פסקי זמן בעומס גבוה.

public function result(Request $request): Response
{
    $outSum = $request->input('OutSum');
    $invId = $request->input('InvId');
    $received = strtolower($request->input('SignatureValue'));

    // Проверяем подпись с Password2
    $expected = strtolower(md5("{$outSum}:{$invId}:" . env('ROBOKASSA_PASS2')));
    if (!hash_equals($expected, $received)) {
        return response('bad sign', 400);
    }

    $order = Order::findOrFail($invId);

    // Дополнительно проверяем сумму
    if (abs((float)$outSum - $order->total) > 0.01) {
        return response('amount mismatch', 400);
    }

    $order->update(['status' => 'paid']);

    // Robokassa ожидает ответ строго в формате "OK{InvId}"
    return response("OK{$invId}");
}

אם Robokassa לא מקבל public function result(Request $request): Response { $outSum = $request->input('OutSum'); $invId = $request->input('InvId'); $received = strtolower($request->input('SignatureValue')); // Проверяем подпись с Password2 $expected = strtolower(md5("{$outSum}:{$invId}:" . env('ROBOKASSA_PASS2'))); if (!hash_equals($expected, $received)) { return response('bad sign', 400); } $order = Order::findOrFail($invId); // Дополнительно проверяем сумму if (abs((float)$outSum - $order->total) > 0.01) { return response('amount mismatch', 400); } $order->update(['status' => 'paid']); // Robokassa ожидает ответ строго в формате "OK{InvId}" return response("OK{$invId}"); } , ההודעה חוזרת. לכן המטפל חייב להיות אידמפוטנטי: בקשה חוזרת עם אותו InvId לא צריכה לשנות את הסטטוס שוב.

טיפול בשגיאות פיסקליזציה

פיסקליזציה שגויה היא הגורם השני בשכיחותו לדחיות. הקבלה מועברת בפרמטר OK{InvId} (JSON, URL-encode). מבנה: Receipt, sno עם items, sum, tax. שגיאה בפורמט מובילה לסירוב. אנו מריצים בדיקת ריצה לפני העלייה לאוויר כדי לוודא נכונות הנתונים. הקפידו להשתמש במצב הבדיקה של Robokassa עם נתונים אמיתיים אך ללא חיוב כספים.

מדריך שילוב שלב אחר שלב

תהליך עבודה

לוח זמנים ועלות

השילוב אורך בין 2 ל-5 ימים תלוי במורכבות (פיסקליזציה, מרקטפלייס). העלות מחושבת באופן אישי לאחר ניתוח. פרויקטים טיפוסיים נעים בין 300–800 דולר, כאשר רובם סביב 450–650 דולר. הנתונים שלנו מראים ש-15% מבעיות השילוב נובעות משגיאות חתימה — אנו עוזרים להימנע מהן.

שגיאות נפוצות ופתרונות

מה כלול בעבודה

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

הניסיון של הצוות שלנו — למעלה מ-53 שילובי מערכות תשלום מוצלחים, 10+ שנים בשוק. תיעוד Robokassa — המקור הראשי. קבלו ייעוץ — כתבו לנו, אנו נגדיר קבלת תשלומים אמינה.