Приход храма: сайт, расписание и пожертвования без комиссии платформы

MAATRIX

У прихода обычно нет отдела веб-разработки — есть настоятель, староста и несколько добровольцев, которые ведут страницу в соцсетях и вешают объявления у входа. Когда встаёт вопрос о полноценном сайте с расписанием богослужений и приёмом пожертвований, самый быстрый путь — подключить готовую платформу для сбора пожертвований. У этого пути есть цена: платформа берёт свой процент с каждого поступления, и для храма, где рубль идёт на свечи, ремонт кровли или помощь нуждающимся, это ощутимо. Ниже — как поднять сайт прихода с расписанием и приёмом пожертвований на собственном сервере, чтобы до общины доходило больше, а посредник не стоял между жертвователем и приходом.

Что на самом деле нужно сайту прихода

Задача скромнее, чем кажется на старте, и это хорошая новость — не придётся тянуть сложную инфраструктуру.

Базовый набор страниц:

• Расписание богослужений — регулярное (будни, воскресенье) и особое (посты, престольные праздники, крестные ходы), с возможностью быстро отметить перенос или отмену службы;
• О приходе и контакты — адрес, схема проезда, часы работы церковной лавки, телефон дежурного;
• Новости и объявления — сборы на конкретные нужды, ремонт, приходские мероприятия, воскресная школа;
• Пожертвования — отдельная страница с понятным объяснением, на что собираются средства, и формой оплаты;
• иногда — расписание треб (крещение, венчание, отпевание) и форма записи.

Это низконагруженный сайт: посещаемость прихода даже в крупном городе редко превышает пару сотен уникальных визитов в день, всплесками — перед праздниками. Для такой нагрузки достаточно самого младшего VPS: 1 vCPU, 1-2 ГБ оперативной памяти, 20-40 ГБ диска. Платить за мощности «на вырост» здесь не нужно — сайт прихода не превратится в интернет-магазин с миллионом посетителей, а если когда-нибудь понадобится больше ресурсов, конфигурацию всегда можно расширить за несколько минут.

Почему платформа для пожертвований обходится дороже, чем кажется

Готовая платформа сбора пожертвований выглядит соблазнительно: виджет вставляется на сайт за пять минут, не нужно думать про эквайринг и чеки — всё уже настроено. Но у удобства есть механизм: помимо комиссии банка за обработку платежа (она есть всегда, вне зависимости от того, кто принимает деньги), платформа обычно удерживает свой собственный процент сверху — за инфраструктуру, поддержку и сервис.

Для интернет-магазина это просто статья расходов, заложенная в цену товара. Для прихода — это не абстрактная «комиссия сервиса», а конкретные деньги, которые могли пойти на дрова для котельной или зарплату регенту хора. И чем больше оборот пожертвований, тем заметнее становится этот процент в абсолютных цифрах за год.

Есть и менее очевидные издержки:

• Данные жертвователей — имена, суммы, иногда контакты — хранятся на серверах стороннего сервиса, а не там, где приход может это контролировать;
• Зависимость — если у платформы меняются условия, блокируется аккаунт из-за формальной причины или сервис вовсе закрывается, приём пожертвований останавливается вместе с ним;
• Шаблонный вид — виджет платформы редко вписывается в облик сайта прихода, выглядит как чужеродная вставка;
• Отчётность — выгрузка данных о пожертвованиях для внутренней бухгалтерии прихода часто ограничена форматом, который придумала платформа, а не тем, что удобно старосте.

Честно: порог входа у своего решения действительно выше — платформу подключить быстрее. Но это разовая работа, которую можно сделать один раз и дальше просто пользоваться, а комиссия посредника — расход, который повторяется с каждым переводом, из года в год.

Свой сервер: минимальный стек

Понадобится три вещи: домен, сервер и CMS, с которой сможет самостоятельно работать не самый технически подкованный человек в приходе.

Домен. Регистрируется на приход как юрлицо (местную религиозную организацию) или на доверенное физлицо — исторически многие приходские сайты живут в зоне .ru, но подойдёт любая. После регистрации нужно только указать A-запись на IP сервера.

CMS. Для сайта, который будут редактировать не программисты, а настоятель или староста, разумнее взять систему с понятной админкой, а не голый статический генератор. Хороший баланс простоты и знакомости интерфейса — WordPress: у него низкий порог входа, множество готовых тем под сайты организаций и плагин-календарь для расписания служб.

Минимальный docker-compose.yml для связки WordPress + MySQL + Caddy (Caddy сам выпускает и продлевает SSL-сертификат):

version: "3.8"
services:
  db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: parish
      MYSQL_USER: parish
      MYSQL_PASSWORD: ${DB_PASSWORD}
      MYSQL_RANDOM_ROOT_PASSWORD: "1"
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:6-php8.3-apache
    restart: unless-stopped
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: parish
      WORDPRESS_DB_USER: parish
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
    volumes:
      - wp_data:/var/www/html
    depends_on:
      - db

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
    depends_on:
      - wordpress

volumes:
  db_data:
  wp_data:
  caddy_data:

Caddyfile:

prihod-hrama.ru {
    reverse_proxy wordpress:80
    encode gzip
}

Caddy сам получит сертификат Let's Encrypt при первом запуске — вручную настраивать certbot не придётся. Подробный разбор установки Caddy с автоматическим SSL есть в отдельной статье: Caddy с авто-SSL — пошаговая установка. Если WordPress кажется тяжеловесным для небольшого сайта из пяти-шести страниц, вариант проще — статический сайт с CMS-надстройкой для одной страницы расписания, но для прихода, где обновлять контент будут разные люди без опыта в IT, привычный WordPress обычно оказывается практичнее.

Приём пожертвований напрямую, без платформы-посредника

Здесь два рабочих пути, и они хорошо дополняют друг друга.

Система быстрых платежей (СБП). Банк, где у прихода открыт расчётный счёт, подключает приём переводов по QR-коду или по номеру телефона на реквизиты организации. Комиссия за такие переводы обычно ниже, чем при оплате картой через эквайринг, а сам QR-код можно сгенерировать один раз и разместить и на сайте, и на табличке у свечного ящика — это уже привычный многим приходам инструмент. На странице «Пожертвования» такой QR встраивается изображением или динамически формируется через API банка под конкретную сумму, если жертвователь указывает её заранее.

Банковский эквайринг для оплаты картой. Здесь важный технический нюанс: сайт прихода не должен сам принимать и хранить номера карт — это требует соответствия стандарту PCI DSS, и для небольшой организации это неоправданно сложно. Правильная схема — подключить у обслуживающего банка платёжный виджет (хостированную форму оплаты), которая открывается поверх сайта или во всплывающем окне: посетитель вводит данные карты на защищённой странице банка, а сайт прихода только инициирует платёж и получает уведомление об успехе через вебхук. Технически это не сложнее, чем интеграция с платформой-посредником — просто банк-эквайер выступает единственным звеном между жертвователем и расчётным счётом прихода, без наценки третьей стороны сверху.

Практическая деталь, которая экономит потом много времени: заведите отдельные ссылки или QR-коды под разные цели сбора («на ремонт кровли», «на нужды воскресной школы», «на храм в целом»). Это можно сделать простыми статическими страницами-обёртками с разным текстом перед одной и той же формой оплаты, но с разным описанием платежа — тогда в выписке банка сразу видно, сколько собрано на каждую цель, и старосте не придётся вручную сверять переводы с комментариями жертвователей.

Отдельный вопрос — отчётность для самих жертвователей. Многие охотнее жертвуют, когда видят, что деньги расходуются прозрачно: короткий пост в новостях сайта раз в квартал («собрано на кровлю — потрачено на кровлю») укрепляет доверие лучше любого редизайна формы оплаты.

Расписание богослужений, которое реально обновляют

Самая частая проблема приходских сайтов — не техническая, а организационная: расписание давно устарело, потому что обновлять его неудобно или некому. Здесь стоит закладывать простоту редактирования выше любых других требований.

Практичная схема:

• одна страница-таблица с регулярным расписанием (она меняется редко — раз в сезон);
• отдельный блок «Особые дни» или «Ближайшие службы» для престольных праздников, крестных ходов, изменений времени по случаю архиерейской службы — его редактирует один ответственный человек через обычный визуальный редактор WordPress, без кода;
• дублирование ключевых изменений в приходский Telegram-канал или чат со ссылкой на сайт — так расписание видят и те, кто не заходит на сайт специально.

Если в приходе несколько человек могут редактировать сайт, стоит сразу завести им отдельные учётные записи с ролью «редактор», а не раздавать общий пароль администратора — это упрощает и безопасность, и разбор «кто что поменял», если расписание вдруг разъехалось.

Надёжность, резервные копии и безопасность

Сайт с формой приёма пожертвований — точка, где приходится быть особенно аккуратным, даже если сам приход не обрабатывает данные карт напрямую.

HTTPS обязателен, и не только для сайтов, принимающих оплату — без него браузер прямо предупреждает посетителя, что сайт «не защищён», а это подрывает доверие ровно на той странице, где нужнее всего доверие. С Caddy из конфигурации выше сертификат выпускается и продлевается автоматически, вручную ничего делать не нужно.

Резервные копии — обязательны, потому что база данных WordPress хранит и тексты новостей, и настройки, а восстанавливать сайт с нуля вручную не хочется никому. Минимальная рабочая схема — ежедневный дамп базы и архив файлов с ротацией на несколько дней:

#!/bin/bash
DATE=$(date +%F)
BACKUP_DIR=/opt/backups/parish
mkdir -p "$BACKUP_DIR"

docker exec db mysqldump -u parish -p"$DB_PASSWORD" parish > "$BACKUP_DIR/db-$DATE.sql"
tar czf "$BACKUP_DIR/wp-files-$DATE.tar.gz" -C /var/lib/docker/volumes/parish_wp_data/_data .

find "$BACKUP_DIR" -type f -mtime +14 -delete

Строку стоит добавить в cron (crontab -e):

0 3 * * * /opt/backups/backup-parish.sh

Для более надёжной схемы с шифрованием и хранением копий вне сервера подойдёт готовый инструмент вроде BorgBackup — он умеет дедупликацию и шифрование «из коробки», что особенно уместно, раз в базе хранятся персональные данные жертвователей.

Защита админки — обязательный минимум: сложный пароль, двухфакторная аутентификация через плагин (их для WordPress несколько бесплатных), регулярные обновления самого WordPress и плагинов, ограничение числа попыток входа (например, плагином или на уровне Caddy/fail2ban). Персональные данные жертвователей (имена, если они указываются, суммы) — чувствительная информация, и относиться к ней стоит так же серьёзно, как если бы это были данные прихожан из церковной книги.

Частые вопросы