Insurance Company Website Development on 1C-Bitrix
Insurance companies sell promises. A customer pays now for protection needed maybe a year from now — or never. The only way to convince them through a website is to let them independently calculate the cost and buy a policy in 5 minutes, without calls or office visits.
The central site element is an online insurance calculator. It's a multi-step form with tariff logic that recalculates the premium in real-time. Let's examine its architecture in 1C-Bitrix.
Insurance Product Catalog
Insurance products — infoblock with sections by direction:
- Auto Insurance — OSAGO, CASCO
- Medical Insurance — voluntary medical for individuals, organizations
- Property — apartment, house, commercial property
- Travel — international, domestic tourism
- Life and Health — term, endowment
Infoblock element properties:
| Property | Type | Purpose |
|---|---|---|
| COVERAGE_LIST | HTML | List of covered risks |
| EXCLUSIONS | HTML | Exclusions from coverage |
| SUM_INSURED_MIN | number | Minimum insured amount |
| SUM_INSURED_MAX | number | Maximum insured amount |
| CALCULATOR_LINK | string | Link to calculator for this product |
| DOCUMENTS | file (multiple) | Insurance rules, sample policy (PDF) |
| TARGET_AUDIENCE | enumeration | Individuals / Legal entities / Both |
Each product has detailed page describing conditions, coverage, claim procedures. This isn't ad copy — customers carefully read conditions before purchase.
Online Insurance Calculator with Tariff Logic
The calculator is the site's most complex component. Each insurance product has its own form with unique fields and calculation formula.
Let's examine CASCO — the most loaded with parameters.
Step 1: Vehicle Data. Customer fills: brand, model, year, engine power, VIN (optional), vehicle value, anti-theft system presence.
Step 2: Driver Data. Age, experience, number of permitted drivers (or "multi-drive"). Each driver gets a KVS coefficient (age-experience coefficient).
Step 3: Insurance Parameters. Insured amount, deductible (unconditional, 0-1000 USD), additional risks inclusion (GAP, accidental injury, replacement vehicle), insurance period.
Step 4: Premium Calculation.
Base premium formula for CASCO:
Premium = Insured_Amount × Base_Rate × KVS × KM × KS × KF × KPS × KT
Where:
- Base_Rate — depends on brand/model (theft frequency) and year
- KVS — age-experience coefficient (minimum of all drivers)
- KM — engine power coefficient
- KS — insurance period coefficient (6 months ≠ half annual)
- KF — deductible coefficient (higher deductible — lower coefficient)
- KPS — anti-theft system coefficient
- KT — territorial coefficient
Tariff Reference in Highload Blocks:
InsuranceBaseTariff — base tariffs:
| Field | Type | Example |
|---|---|---|
| UF_PRODUCT_TYPE | enumeration | CASCO |
| UF_CAR_BRAND | string | Toyota |
| UF_CAR_MODEL | string | Camry |
| UF_YEAR_FROM | integer | 2020 |
| UF_YEAR_TO | integer | 2025 |
| UF_BASE_RATE | float | 0.035 (3.5%) |
| UF_RISK_GROUP | enumeration | Low / Medium / High (theft frequency) |
InsuranceCoefficient — coefficients:
| Field | Type | Purpose |
|---|---|---|
| UF_COEFF_TYPE | enumeration | KVS / KM / KS / KF / KPS / KT |
| UF_PARAM_FROM | float | Parameter lower bound |
| UF_PARAM_TO | float | Parameter upper bound |
| UF_VALUE | float | Coefficient value |
| UF_PRODUCT_TYPE | enumeration | Which product this applies to |
Example KVS entries:
| UF_COEFF_TYPE | UF_PARAM_FROM (age) | UF_PARAM_TO | Experience from | Experience to | UF_VALUE |
|---|---|---|---|---|---|
| KVS | 18 | 21 | 0 | 2 | 1.87 |
| KVS | 22 | 25 | 3 | 5 | 1.04 |
| KVS | 30 | 65 | 10 | 99 | 0.93 |
For KVS two parameters are needed (age and experience), so Highload Block adds additional fields UF_PARAM2_FROM and UF_PARAM2_TO — or separate InsuranceCoefficientKVS Highload Block is created with explicit fields.
Server-Side Calculation. Calculator works through AJAX request to custom Bitrix controller. Client side collects form parameters and sends POST request. Server:
- Finds base tariff by brand/model/year
- For each coefficient queries
InsuranceCoefficientby type and parameter range - Multiplies all coefficients
- Returns JSON with total and breakdown
$baseTariff = InsuranceBaseTariffTable::getRow([
'filter' => [
'UF_PRODUCT_TYPE' => 'kasko',
'UF_CAR_BRAND' => $brand,
'UF_CAR_MODEL' => $model,
'<=UF_YEAR_FROM' => $year,
'>=UF_YEAR_TO' => $year,
],
]);
$coefficients = [];
// KVS — take minimum age-experience from driver list
$kvs = InsuranceCoefficientTable::getRow([
'filter' => [
'UF_COEFF_TYPE' => 'kvs',
'<=UF_PARAM_FROM' => $driverAge,
'>=UF_PARAM_TO' => $driverAge,
'<=UF_PARAM2_FROM' => $driverExperience,
'>=UF_PARAM2_TO' => $driverExperience,
],
]);
$coefficients['kvs'] = $kvs['UF_VALUE'];
// Similarly for KM, KS, KF, KPS, KT
// ...
$premium = $insuredSum * $baseTariff['UF_BASE_RATE'];
foreach ($coefficients as $coeff) {
$premium *= $coeff;
}
Breakdown for Customer. Calculator doesn't just output a number — shows table: "base rate 3.5%, KVS 1.04, deductible reduces by 15%...". Calculation transparency increases trust.
Variability. Customer can change parameters (increase deductible, remove driver, change amount) and see price change. Recalculation — via AJAX without page reload.
Online Policy Purchase
After calculation customer clicks "Issue Policy." Order created through sale module. Special features:
- Product — insurance product from catalog with dynamic price (calculated by calculator)
- Order Properties — all policy parameters: vehicle data, drivers, coverage conditions
-
Payment — via payment gateways. Integration through
sale.paysystem -
After Payment —
OnSaleOrderPaidhandler generates policy PDF and sends to customer email
PDF generation — via TCPDF or mPDF library. Policy template with data substitution from order properties.
Policyholder Personal Account
Account functionality:
- My Policies — list of active and expired policies with PDF files
- Deadlines — notification 30 days before policy expiry (Bitrix agent + email/SMS)
- Renewal — "Renew" button pre-fills calculator with current policy data
-
Claim Form — form with document upload (accident photos, report, inspection act). Files saved via
CFile::SaveFile(), claim — element of "Insurance Claims" infoblock - Claim Status — customer sees processing stages: received → under review → document request → decision → payment
Integration with 1C:Insurance and AIS
Insurance companies work in specialized accounting systems. Main options:
1C:Insurance. Exchange through 1C HTTP services. From site to 1C: new policies (after payment), claim forms. From 1C to site: claim statuses, tariff references (if tariffs maintained in 1C).
Insurer AIS (departmental system). Integration via SOAP or REST. For OSAGO often mandatory link to state database (RSA in Russia, analogs in other countries). KBM check (bonus-malus coefficient) — query external API before calculation.
Exchange format depends on specific AIS. Typical pattern: Bitrix sends XML/JSON with policy data to AIS endpoint, receives policy number and status.
Agent Portal (B2B)
Insurance agents — separate user category. Their portal:
- Authentication — by agent number, tied to "Agents" group in Bitrix
- Agent Commission Calculator — same calculator but showing agent commission (percent of premium)
- Client Funnel — CRM-like interface: leads, calculations, issued policies. Implemented via custom "Agent Applications" infoblock with statuses
-
Reporting — sales export for period, accrued commission. Formatted via
PhpSpreadsheetto XLSX
Agent portal access restricted through $APPLICATION->GetUserGroupArray() and group membership check.
Implementation Timeline
| Scale | Scope | Timeline |
|---|---|---|
| One Product (OSAGO or travel) | Calculator, online purchase, basic account | 8-10 weeks |
| 3-5 Products (auto + property + medical) | + multiple calculators, 1C integration, claim forms | 14-20 weeks |
| Full-Featured Site | + agent portal, AIS integration, renewal, mobile account | 22-30 weeks |
What Determines Complexity
Each insurance product is a separate calculator with unique formula. CASCO and OSAGO use different coefficient sets, medical insurance calculated by number of insured and clinic set, property insurance — by object type and risks. Can't unify formulas: can unify coefficient storage mechanism in Highload Blocks and AJAX wrapper, but each calculator's business logic must be written separately.
Second factor — actuarial data. Tariff reference should update regularly when rates change. If tariffs maintained in 1C — set automatic sync. If on site — need convenient admin interface for actuary to update coefficients through Bitrix admin without developer involvement.







