Integration of 1C-Bitrix with Pokupay with Sber
The "Pokupay with Sber" service (formerly "Sberbank Credit", aka SberPay installment) allows a buyer to arrange installment or credit right on the checkout page. For an e-commerce site on 1C-Bitrix this is an additional payment system connected to the sale module. Sber's audience is the largest customer base among Russian banks, so for stores with check from 3,000 rubles, integration has direct economic sense.
How It Works
Mechanics similar to other lending services:
- Buyer selects "Pokupay with Sber" at checkout
- Store sends order data to Sber API
- Buyer redirects to Sber page to fill application
- Sber makes decision (scoring — from 2 minutes for Sber clients)
- If approved and signed — store gets notification, order is paid
Sber API for partners: https://api.sberbank.ru/fintech/api/v1/credit-gate/. Documentation is closed — issued after signing partner agreement.
Getting Access
Connection process is longer than technical integration:
- Application at
sberbank.ru/ru/s_m_business/bankingservice/credit_products— register as partner - Verification of legal entity (1–2 weeks)
- Sign agreement
- Receive credentials:
partnerId,partnerToken, test requisites - Technical integration and testing
- Pass Sber's acceptance testing
- Switch to production
Acceptance testing — Sber checks that integration works correctly: correct item transmission, handling all statuses, correct returns. Without passing acceptance, production access won't be given.
Technical Integration with sale Module
Like any payment system in 1C-Bitrix, create handler in /local/php_interface/include/sale_payment/sber_credit/.
File .description.php:
$data = [
'NAME' => 'Pokupay with Sber',
'SORT' => 500,
'CODES' => [
'PARTNER_ID' => ['NAME' => 'Partner ID', 'SORT' => 100],
'PARTNER_TOKEN' => ['NAME' => 'Token', 'SORT' => 200],
'TEST_MODE' => ['NAME' => 'Test mode', 'SORT' => 300, 'INPUT' => ['TYPE' => 'Y/N']],
]
];
Handler class (handler.php) inherits \Bitrix\Sale\PaySystem\ServiceHandler. Key methods:
Forming Order for API
Method initiatePay forms request to Sber. Order data structure:
$orderData = [
'partnerOrderId' => $payment->getField('ORDER_ID'),
'partnerOrderDate' => date('Y-m-d\TH:i:sP'),
'amount' => $payment->getSum(),
'currency' => 'RUB',
'returnUrl' => $this->getSuccessUrl($payment),
'failUrl' => $this->getFailUrl($payment),
'callbackUrl' => $this->getCallbackUrl($payment),
'items' => []
];
$basket = $payment->getOrder()->getBasket();
foreach ($basket as $item) {
$orderData['items'][] = [
'name' => $item->getField('NAME'),
'quantity' => $item->getQuantity(),
'price' => $item->getPrice(),
'sum' => $item->getPrice() * $item->getQuantity(),
'category' => $this->mapCategory($item),
];
}
Important: sum of product items must exactly match amount. If there are discounts or delivery — they must be separate items in items. Even a kopeck difference will cause application rejection.
Product Categorization
Sber requires category for each item (category). List of categories is fixed: electronics, clothing, furniture, household, other, etc. Mapping Bitrix categories to Sber categories must be implemented:
- Via custom property of infoblox section (
UF_SBER_CATEGORY) - Or via mapping table in module settings: catalog section ID → Sber category code
Without proper categorization application can be rejected or processed longer.
Status Handling
Sber sends POST-notifications to callbackUrl on status change. Status model:
| API Status | Description | Action |
|---|---|---|
CREATED |
Application created | Log |
PROCESSING |
Under review | Nothing |
APPROVED |
Approved by bank | Nothing (wait for signing) |
SIGNED |
Contract signed | $payment->setPaid('Y') |
REJECTED |
Bank refusal | Cancel payment |
CANCELED |
Canceled by client | Cancel payment |
REFUNDED |
Refund | Create refund in Bitrix |
Handler processRequest must:
- Check request signature (HMAC-SHA256 from body +
partnerToken) - Find payment by
partnerOrderId - Update payment status
- Return HTTP 200 (otherwise Sber will retry notifications)
Refunds
"Pokupay with Sber" supports partial and full refunds via API. When processing refund in 1C-Bitrix (Store → Orders → Refund) handler should send request to POST /credit-gate/refund:
public function refund(\Bitrix\Sale\Payment $payment, $refundAmount)
{
$response = $this->apiRequest('refund', [
'partnerOrderId' => $payment->getField('ORDER_ID'),
'amount' => $refundAmount,
]);
return $response['status'] === 'SUCCESS';
}
Refund processed by Sber in 1–5 business days. Refund status comes via callback-notification.
Widget on Product Card
Sber provides JS-widget for displaying monthly payment on product page:
<div id="sber-credit-widget" data-sum="80000"></div>
<script src="https://iss.sberbank.ru/partner/widget.js" data-partner-id="YOUR_ID"></script>
Widget shows: "from 3,500 rubles/month" — near the price. Embedded in template bitrix:catalog.element via component_epilog.php or custom template.
Differences from Tinkoff Credit
- Audience is wider (Sber clients — ~60% of population)
- Acceptance testing process is stricter
- API-documentation is closed (only after agreement)
- Scoring is faster for Sber clients (data available for assessment)
- Minimum order amount usually lower (from 3,000 rub. vs 3,000–5,000 for Tinkoff)







