התאמה אישית של Robokassa ל-1C-Bitrix

המודול הסטנדרטי של Robokassa לרוב אינו מספק את הגמישות הנדרשת להגדרות תשלום ופיסקליזציה. אנו מפתחים אינטגרציה מותאמת אישית של 1C-Bitrix עם Robokassa, המותאמת באופן מלא לתהליך העסקי שלכם. הצוות שלנו מספק את הפרויקט במפתח מלא—מביקורת ועד תמיכה—ומבטיח פעילות אמינה ועמידה בדרישות 54-FZ.
השירותים שאנו מציעים
מציג 1 מתוך 1כל 1626 השירותים
התאמה אישית של Robokassa ל-1C-Bitrix
בינוני
~1-2 שבועות

הכישורים שלנו:

שאלות נפוצות

המודול הסטנדרטי של Robokassa מה-Marketplace לרוב חסר את הגמישות הדרושה לך: אינך יכול לנהל פרמטרים של Shp_*, לשנות את הלוגיקה של הפיסקליזציה, או לייעל את העיבוד לעומסים גבוהים. אינטגרציה מותאמת אישית פותרת בעיות אלו — אתה מקבל שליטה מלאה על יצירת החתימה, טיפול בהודעות ולוגיקת השגיאות. הניסיון שלנו: 7+ שנים של אינטגרציה של Bitrix עם מערכות תשלום, מעל 50 פרויקטים מוצלחים. אנו מבטיחים עיבוד תשלומים תקין ועמידה מלאה בדרישות 54-FZ.

מדוע אינטגרציה מותאמת אישית של Robokassa אמינה יותר ממודול מוכן?

המודול המוכן מה-Marketplace מוגבל בהגדרות: הוא אינו מאפשר ניהול גמיש של פרמטרי Shp_*, אינו תומך בתרחישי פיסקליזציה לא סטנדרטיים, ואינו מותאם לעומסים גבוהים. אינטגרציה מותאמת אישית מעניקה שליטה מלאה על יצירת החתימה, טיפול בהודעות ולוגיקת השגיאות. היא מעבדת תשלומים פי 3 מהר יותר הודות למטמון מותאם ובקשות מקבילות ל-API של Bitrix ו-Robokassa.

קריטריון מודול סטנדרטי אינטגרציה מותאמת אישית
שליטה ב-Shp_* מוגבלת שליטה מלאה
פיסקליזציה בסיסית, שגיאות תכופות הגדרה גמישה ל-54-FZ
ביצועים ממוצעים מותאמים (מטמון, בקשות מקבילות)
אחריות אין 12 חודשים

תהליך העבודה

  1. Bitrix יוצר קישור חתום לטופס Robokassa
  2. הלקוח משלם (כרטיס, ארנק, מזומן)
  3. Robokassa שולחת הודעת POST ל-ResultURL של החנות
  4. החנות מאמתת את החתימה ומאשרת את התשלום
  5. Robokassa מפנה את הלקוח ל-SuccessURL או FailURL

פרמטרים ויצירת חתימה

פרמטרי בקשה בסיסיים ל-Robokassa:

פרמטר ערך תיאור
MerchantLogin מהחשבון האישי שם משתמש של הסוחר
OutSum סכום סכום התשלום
InvId orderId מספר הזמנה
Description טקסט תיאור (עד 100 תווים)
SignatureValue MD5/SHA256 חתימה
IsTest 1 מצב בדיקה
Encoding utf-8 קידוד

החתימה נוצרת כ-MD5 או SHA256 (תלוי בהגדרות הסוחר בחשבון Robokassa):

// MD5 подпись
$signature = md5("{$merchantLogin}:{$outSum}:{$invId}:{$password1}");

// SHA256 (рекомендуется)
$signature = hash('sha256', "{$merchantLogin}:{$outSum}:{$invId}:{$password1}");

// URL платёжной формы
$payUrl = 'https://auth.robokassa.ru/Merchant/Index.aspx?' . http_build_query([
    'MerchantLogin' => $merchantLogin,
    'OutSum' => number_format($outSum, 2, '.', ''),
    'InvId' => $invId,
    'Description' => $description,
    'SignatureValue' => $signature,
    'Encoding' => 'utf-8',
    'IsTest' => $isTest ? 1 : 0,
]);

עיבוד ResultURL

Robokassa שולחת POST עם פרמטרים ל-// MD5 подпись $signature = md5("{$merchantLogin}:{$outSum}:{$invId}:{$password1}"); // SHA256 (рекомендуется) $signature = hash('sha256', "{$merchantLogin}:{$outSum}:{$invId}:{$password1}"); // URL платёжной формы $payUrl = 'https://auth.robokassa.ru/Merchant/Index.aspx?' . http_build_query([ 'MerchantLogin' => $merchantLogin, 'OutSum' => number_format($outSum, 2, '.', ''), 'InvId' => $invId, 'Description' => $description, 'SignatureValue' => $signature, 'Encoding' => 'utf-8', 'IsTest' => $isTest ? 1 : 0, ]); . אימות החתימה הוא חובה — משתמש ב-ResultURL (שונה מ-Password2):

$outSum = $_POST['OutSum'];
$invId = $_POST['InvId'];
$received = strtolower($_POST['SignatureValue']);
$password2 = $this->getBusinessValue($payment, 'ROBOKASSA_PASSWORD2');
$expected = strtolower(hash('sha256', "{$outSum}:{$invId}:{$password2}"));
if ($received !== $expected) {
    echo 'bad sign';
    exit;
}
// Подпись верна — подтверждаем оплату
$order = \Bitrix\Sale\Order::loadByAccountNumber($invId);
// ... setPaid('Y'), save()
echo "OK{$invId}"; // Robokassa ждёт именно этот ответ

קריטי: התשובה ל-ResultURL חייבת להיות בדיוק Password1. אם Robokassa לא מקבלת תשובה זו, היא מחשיבה את ההודעה כלא נמסרה ומנסה שוב (עד 8 פעמים).

פרמטרים נוספים (Shp_*)

Robokassa תומכת בפרמטרים מוגדרים על ידי המשתמש עם הקידומת $outSum = $_POST['OutSum']; $invId = $_POST['InvId']; $received = strtolower($_POST['SignatureValue']); $password2 = $this->getBusinessValue($payment, 'ROBOKASSA_PASSWORD2'); $expected = strtolower(hash('sha256', "{$outSum}:{$invId}:{$password2}")); if ($received !== $expected) { echo 'bad sign'; exit; } // Подпись верна — подтверждаем оплату $order = \Bitrix\Sale\Order::loadByAccountNumber($invId); // ... setPaid('Y'), save() echo "OK{$invId}"; // Robokassa ждёт именно этот ответ . הם כלולים בחתימה ומוחזרים ב-ResultURL. השתמש בהם כדי להעביר את מזהה ההזמנה של Bitrix אם OK{InvId} תפוס או אם יש צורך בנתונים נוספים:

$signature = hash('sha256', "{$merchantLogin}:{$outSum}:{$invId}:{$password1}:Shp_item={$itemId}&Shp_user={$userId}" ); // Параметры Shp_ в подпись включаются в алфавитном порядке ключей 

פיסקליזציה

Robokassa תומכת ב-54-FZ באמצעות הפרמטר Shp_ כ-JSON מקודד base64:

$receipt = [
    'sno' => 'osn', // система налогообложения
    'items' => array_map(function($basketItem) {
        return [
            'name' => $basketItem->getField('NAME'),
            'quantity' => $basketItem->getQuantity(),
            'sum' => $basketItem->getPrice() * $basketItem->getQuantity(),
            'payment_method' => 'full_prepayment',
            'payment_object' => 'commodity',
            'tax' => 'vat20',
        ];
    }, iterator_to_array($order->getBasket())),
];

$receiptEncoded = base64_encode(json_encode($receipt, JSON_UNESCAPED_UNICODE));

כיצד להבטיח פיסקליזציה תקינה של קבלות?

כדי לעמוד בדרישות 54-FZ בעת תשלום דרך Robokassa, יש להעביר את הפרמטר InvId עם נתונים נכונים על מוצרים, שיעורי מע"מ ומערכת המיסוי. טעות נפוצה היא פורמט שגוי עבור $signature = hash('sha256', "{$merchantLogin}:{$outSum}:{$invId}:{$password1}:Shp_item={$itemId}&Shp_user={$userId}" ); // Параметры Shp_ в подпись включаются в алфавитном порядке ключей או Receipt. בניסיון שלנו, אנו מאמתים מראש את הקבלה דרך סביבת הבדיקה של Robokassa. זה עוזר למנוע דחיות של כונן פיסקלי וקנסות.

מקרה בוחן: חנות מקוונת למוצרי חשמל ביתיים

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

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

אנו מספקים אינטגרציה במפתח פתוח:

  • ניתוח תוכנית התשלומים הנוכחית באתר
  • פיתוח מודול עם מחזור מלא: יצירת קישור, ResultURL, SuccessURL, FailURL
  • הגדרת פרמטרי $receipt = [ 'sno' => 'osn', // система налогообложения 'items' => array_map(function($basketItem) { return [ 'name' => $basketItem->getField('NAME'), 'quantity' => $basketItem->getQuantity(), 'sum' => $basketItem->getPrice() * $basketItem->getQuantity(), 'payment_method' => 'full_prepayment', 'payment_object' => 'commodity', 'tax' => 'vat20', ]; }, iterator_to_array($order->getBasket())), ]; $receiptEncoded = base64_encode(json_encode($receipt, JSON_UNESCAPED_UNICODE)); נוספים להעברת מטא-דאטה של הזמנה
  • יישום פיסקליזציה בהתאם ל-54-FZ
  • בדיקות בסביבת הבדיקה והייצור של Robokassa
  • תיעוד API ומדריך תחזוקה
  • אחריות על הקוד — 12 חודשים

לוחות זמנים ותקציב

משימה משך זמן
Handler: יצירת קישור + ResultURL 1–2 ימים
פרמטרי Shp_* נוספים 0.5 יום
פיסקליזציה +1–2 ימים
בדיקת מחזור מלא 0.5 יום

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

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