Display installment plans in 1C-Bitrix product card

Not having an installment plan block in the product card means that a customer sees a price of 150,000 RUB and leaves. Our analytics show that up to 30% of sessions break off at the payment method selection stage. Backed by 10 years of Bitrix development experience, we guarantee stability and calcul

Our competencies:

Frequently Asked Questions

Not having an installment plan block in the product card means that a customer sees a price of 150,000 RUB and leaves. Our analytics show that up to 30% of sessions break off at the payment method selection stage. Backed by 10 years of Bitrix development experience, we guarantee stability and calculation accuracy. Our 1C-Bitrix component displays available plans with bank logos and monthly payment calculation — right in the product card. The solution works on any tariff and scales.

Problems solved by the installment block

  • Lack of information for the customer. A product costs 10,000–200,000 RUB but the possibility of paying in installments is not shown — the visitor thinks it is not available. The component displays available plans with bank logos and contribution amounts.
  • Conversion drop. According to our projects' data, BNPL presence increases average order value by 20–30%. Customers choose more expensive items knowing they will pay in installments.
  • Calculation errors. Manual amortization calculation leads to inconsistencies with the bank. We automate the annuity payment formula and verify it on test data.

Implementation of displaying installment terms

We use an HL-block InstallmentPlans to store fixed terms (partner, rate, periods). For dynamic terms, we connect bank APIs via cached requests. The PHP calculation code is duplicated in JavaScript for client interactivity.

Storing terms in HL-block

Field Type Description
UF_PARTNER String Partner name (Tinkoff, Halva)
UF_LOGO File Logo for display
UF_MIN_AMOUNT Double Minimum product amount for installment
UF_MONTHS String Available periods (3,6,10,12,18,24)
UF_RATE Double Interest rate (0 for interest-free)
UF_ACTIVE Flag Whether the plan is enabled

Calculating monthly payment

For interest-free: monthly = price / months. For interest-bearing — annuity formula. PHP function:

function calcInstallment(float $price, int $months, float $annualRate): float { if ($annualRate <= 0) { return $price / $months; } $r = $annualRate / 12 / 100; return $price * $r / (1 - pow(1 + $r, -$months)); } 

JavaScript counterpart for recalculation when selecting a period:

function calcInstallment(price, months, annualRate) { if (annualRate <= 0) return price / months; const r = annualRate / 12 / 100; return price * r / (1 - Math.pow(1 + r, -months)); } 

We attach handlers to period selection buttons. Each partner is displayed with a logo and month buttons. The minimum payment is shown for the longest period.

Displaying the block in the product card

In the catalog.element template, after the price, we load matching plans:

$price = (float)$arResult['CATALOG_PRICE_1']; $plans = \Local\Installment\InstallmentPlanTable::getList([ 'filter' => ['=UF_ACTIVE' => true, '<=UF_MIN_AMOUNT' => $price], 'order' => ['UF_MIN_AMOUNT' => 'ASC'], ])->fetchAll(); 

On the frontend, for each partner we render a block with logo and period selection buttons. On click, the monthly installment updates.

Caching API requests: criticality and approach

Each card opening without cache generates an HTTP request to the bank. With 10,000 card views per day — that's 10,000 requests. Caching reduces them to the first few within 10 minutes. We use Bitrix tagged caching to invalidate cache when partner terms change. The 1C-Bitrix documentation recommends this approach for high-load projects.

Caching makes the installment block 100 times more efficient in terms of server load.

What is included in the work

  1. Requirements analysis — determine term sources (static/API), agree on block design.
  2. HL-block and component development — create storage, write output component.
  3. Calculation logic integration — implement PHP and JS functions, test on edge values.
  4. Bank API integration — connect, configure caching, handle errors.
  5. Layout and styling — adapt block to site design, add legal texts.
  6. Testing and deployment — test on all devices, record results.
  7. Documentation and training transfer — describe setup, provide manager instructions.
Example of API error handling If the bank API is unavailable, we show a fallback static plan with fixed terms. We log the error and notify the administrator.

Typical setup errors

  • Not considering the minimum product threshold. If the amount is below UF_MIN_AMOUNT, the block is not shown — the customer sees nothing. We should also display a placeholder or message.
  • Forgetting recalculation when price changes. If the page has option selection, the price changes — the installment must update. We use the event BX.addCustomEvent('onCatalogPriceChange').
  • Not including legal text. According to 54-FZ, it is mandatory to display that the installment is provided by the partner bank. We add it below the block.

Indicative timelines

Step Time
Partner terms storage 1–2 h
Payment calculation (PHP + JS) 2–3 h
Block in product card 3–4 h
Bank API integration (optional) 4–8 h

Cost is calculated individually depending on the number of partners and API complexity.

If you already have agreements with banks or want to connect BNPL services — we will evaluate your project and offer a solution. Contact us for a consultation. Order customization of installment plan display in the 1C-Bitrix product card.