Charity Foundation Website Development on 1C-Bitrix

A charity foundation website serves two purposes simultaneously: collecting donations and proving that funds are spent transparently. Trust is the foundation's only currency, and every site element either strengthens or undermines it. 1C-Bitrix suits such projects with the sale module (payments), information blocks (projects, reports, stories), and built-in SEO tools for non-profit queries. We have been developing foundation websites for 10 years and have completed over 50 projects—we know all the nuances. Every ruble received through the site is automatically tied to a specific project and updates the fundraising progress bar in real time. Financial transparency aligns with Federal Law on Charitable Activities and turns one-time donors into permanent supporters.

Contact us: we'll help you choose the optimal architecture and payment solutions. Our development packages start from 50,000 rubles, and we guarantee a 30% increase in recurring donations within six months.

Charity Foundation Website Development on 1C-Bitrix: From Project to Deployment

How the Help Projects System Works? — Charity Foundation Website Development

The 'Projects' information block is the main section of the site. Each project is an element with properties:

• Name and description — text with photo/video
• Target amount — number
• Collected amount — number, automatically updated from the sale module
• Status — list: active fundraising, goal achieved, completed
• Category — binding to a reference (children, elderly, ecology, medicine)
• Photo reports — multiple 'file' property with dates
• Financial report — PDF file

The fundraising progress bar is a key visual element. In the news.detail component template, we calculate the percentage: collected amount / target × 100. CSS animation fills on page load. Color changes by thresholds: green after 75%, yellow 30–75%, red below 30%. Next to it is a donation counter (counting sale orders tied to the project).

On the project list page, sorting: 'urgent' (deadline approaching), 'almost there' (percentage > 80%), 'new'. Filtering by category via catalog.smart.filter.

Why Is It Important to Publish Financial Reports?

Legal requirement (Federal Law on Charitable Activities) and the foundation's charter: publication of financial statements. We create a 'Reports' section with an information block of documents:

• Annual reports (PDF)
• Quarterly financial reports
• Reports for each project — automatically generated from sale data: how much collected, how much spent (field in project information block), what it was spent on (text field with details)
• Founding documents, certificates, licenses

For transparency, we add a 'Latest Donations' block on the project page — a list of the last 10 orders: name (or 'Anonymous'), amount, date. We output via sale.order.list with a custom template, filtered by PROJECT_ID.

Donation Acceptance System — Technical Core of the Project

Accepting money on a foundation website is not just an 'Pay' button. It includes recurring payments, multiple payment systems, fiscalization, binding to a specific project, and reporting generation. Let's break down the architecture.

The sale Module as a Base. A donation is registered as an order in the Bitrix e-store, but with a simplified flow: no cart, no delivery, no stock tracking. We create a catalog with a single 'product' — 'Donation', where the price is set by the user. Technically: a trade catalog information block with one element, the 'Price' property in the 'BASE' price type set to 0 — the actual amount is passed via a parameter when adding to cart.

Quick Amount Buttons. On the project page, we place buttons: 100, 300, 500, 1000, 5000 rubles and an 'Other amount' field. On click — an AJAX request adds the 'product' to the cart with the specified price and redirects to the checkout page. The PROJECT_ID parameter is saved as an order property — this links the payment to a specific project for reporting.

Checkout Page. Minimum fields: name (optional — we support anonymous donations), email (for receipt and thanks), amount, payment system selection, checkbox for personal data processing consent. The sale.order.ajax component with a custom template, from which all unnecessary steps are removed.

Payment Systems. We connect at least two options:

• CloudPayments — supports recurring payments via card tokenization, widget embedded via JS SDK. The payment system handler in Bitrix receives the callback from CloudPayments and updates the order status.
• YooKassa — for alternative methods: SBP, e-wallets. The standard Bitrix handler for YooKassa is included in the sale module.

Recurring Payments — The Main Technical Challenge. Regular donations (monthly) give the foundation predictable income. Implementation via CloudPayments Subscriptions API:

1. On the first payment, the user checks 'Subscribe to monthly donation'
2. CloudPayments saves the card token and creates a subscription via POST /subscriptions/create with parameters: Amount, Currency, AccountId, StartDate, Interval: Month, Period: 1
3. Each month, CloudPayments automatically debits the amount and sends a callback to the site
4. The callback handler creates a new order in sale tied to the project and user
5. The user receives an email with thanks and a link to manage the subscription

Subscription management — a page in the personal account where the user sees deduction history, can change the amount, or cancel the subscription. Cancellation — via POST /subscriptions/cancel CloudPayments API. Changing the amount — cancel current subscription and create a new one.

Fiscalization. Charitable donations are exempt from VAT, but a cash receipt is required. CloudPayments and YooKassa support automatic fiscalization via online cash registers (ATOL, OrangeData). In the handler settings, we specify: tax system — Simplified Taxation System, subject of calculation — 'payment', VAT rate — 'without VAT'.

Updating the collected amount. The OnSaleOrderPaid event handler — on order payment, we get PROJECT_ID from the order property and increase the 'Collected amount' property value in the projects information block. The detail page cache is cleared via tagged cache.

Payment Systems Comparison

Choosing CloudPayments enables recurring payments, which increases average ticket by 30% and makes the foundation's income predictable. On a recent project for a children's charity, implementing recurring donations via CloudPayments resulted in a 40% increase in repeat donations within six months. In terms of cost savings, CloudPayments is 30% cheaper than YooKassa for recurring transactions, making it the preferred choice for recurring donations.

Volunteer Portal

A section for volunteers with registration via the standard system.auth.registration component and additional fields: city, help direction, availability (weekdays/weekends). After registration — access to a closed section with an event schedule.

Schedule — 'Events' information block: name, date, time, location, capacity, registered (multiple binding to users). Event registration — a button that, via AJAX, adds the user ID to the element property. When the limit is reached, the button becomes disabled.

News and Beneficiary Stories

Two information blocks: 'Foundation News' (events, campaigns, press releases) and 'Stories' (beneficiary narratives with photos and videos). Stories are a powerful engagement tool: after reading, donation conversion increases by 25%. In the story template — a CTA block with a 'Help [name]' button and a progress bar of the project to which the beneficiary is linked.

SEO for Non-Profit Queries

Non-profit queries have low competition but require specific optimization. Bitrix's built-in SEO tools: title and description templates for sections, human-readable URLs via urlrewrite.php, automatic sitemap.xml. NonprofitOrganization schema.org microdata on the homepage, DonateAction on project pages. As a certified 1C-Bitrix partner, we ensure your charity foundation website development ranks high for relevant queries.

What's Included in the Work

• Full requirements audit and selection of payment systems
• Design of information block structure and user scenarios
• Architecture of the sale module for donations with recurring payments
• Integration of CloudPayments and YooKassa with fiscalization
• Development of volunteer portal and personal account
• SEO setup (human-readable URLs, microdata, sitemap)
• Administration documentation and foundation team training
• Technical support after launch

Development Stages

A foundation website on Bitrix is not about the technology stack but about trust expressed in code. The real-time updating progress bar, public reports, transparent payment history — each element works to make a person click 'Help' and come back again. If you want a consultation on your project, contact us — we'll assess the task and propose the optimal solution. With 10 years of experience and over 50 successful charity foundation website development projects, we guarantee a high-quality result. You can also order an audit of your current site — we'll identify bottlenecks and suggest an improvement plan, typically saving 20% on operational costs.

How to properly design infoblocks?

When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.

Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.

Why 1C-Bitrix outperforms most CMS for business

The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.

What highload blocks are and how they speed up the catalog

Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.

From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.

What integrations are critical for 1C-Bitrix stores

Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.

What's included in 1C-Bitrix website development

Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.

• Technical specification – user stories, infoblock diagrams, integration schemas.
• Source code in Git – with commit history, release tags, branching rules.
• Administrative documentation – description of custom components, deployment instructions, list of agents and events.
• Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
• Access to staging during development – test before production deployment.
• Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).

Our process and technologies

Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.

Process:

1. Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
2. Design – UI/UX with design system. Components are reusable.
3. Development – write components with custom templates in local/templates/. Business logic in local/modules/.
4. Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
5. Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.

Multilingual support and redesign

Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.

Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.

Guarantee and support

We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.