Портал для фонда: рекуррентные платежи и отчётность

Фонд теряет до 30% пожертвований из-за ошибок платёжного шлюза на этапе подтверждения — карта отклоняется по таймауту или не проходит 3DS. Ещё 15% доноров не возвращаются после неудачной оплаты. Стандартная CMS — WordPress с плагином Donation — выдаёт N+1 запросов при формировании отчёта, страница загружается 8–10 секунд. А без рекуррентных подписок средний чек донатов одного пользователя падает в 4 раза.

Мы строим порталы на Django + PostgreSQL с Celery для фоновых задач. ЮKassa с сохранением карт даёт рекуррентные платежи с автоматическими ретраями — успешность списаний достигает 92%. А публичные отчёты в реальном времени с разбивкой по программам повышают доверие доноров: фонды с прозрачной отчётностью получают в 2,5 раза больше регулярных пожертвований. Средний чек разового пожертвования на таких порталах — 1500 руб., а рекуррентный донор за год приносит около 18 000 руб.

Типичные технические проблемы

Типичные технические сложности порталов фондов:

• N+1 запросы при формировании отчётов — тормозят страницу до 10 секунд. Решается агрегацией данных в одном запросе через select_related и prefetch_related.
• Отказ платёжного шлюза — потеря клиента в момент оплаты. Используем Webhook-ретрансляцию и очереди задач Celery для повторной обработки.
• Рекуррентные списания без автоматических ретраев — подписки отваливаются. Внедряем автоматические ретраи до 3 попыток с уведомлением администратора.
• Отсутствие онлайн-квитанций — жертвователь не может получить вычет. Генерируем PDF-квитанции с электронной подписью.
• Непрозрачность расходов — подрывает доверие к фонду. Публикуем отчёты в реальном времени с разбивкой по категориям.

Каждая проблема решается конкретным техническим решением: агрегация данных, Webhook-ретрансляция, очередь задач Celery, генерация PDF.

Как мы строим архитектуру портала?

Стандартный стек: Django как API + React на фронте + PostgreSQL + Celery для фоновых задач. Используем UUID-ключи — это исключает конфликты при миграциях и репликации. Схема данных — нормализованная, с разделением программ, донатов и подписок.

CREATE TABLE programs ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), slug VARCHAR(200) UNIQUE NOT NULL, title VARCHAR(300) NOT NULL, description TEXT, goal_amount NUMERIC(15,2), -- NULL = сбор без цели collected NUMERIC(15,2) NOT NULL DEFAULT 0, status VARCHAR(20) NOT NULL DEFAULT 'active' CHECK (status IN ('active','completed','paused','archived')), is_featured BOOLEAN NOT NULL DEFAULT FALSE, image_url VARCHAR(500), ends_at DATE, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); CREATE TABLE donations ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), program_id UUID REFERENCES programs(id), -- NULL = на уставную деятельность donor_id UUID REFERENCES users(id), -- NULL = анонимное пожертвование amount NUMERIC(15,2) NOT NULL, currency CHAR(3) NOT NULL DEFAULT 'RUB', is_anonymous BOOLEAN NOT NULL DEFAULT FALSE, is_recurring BOOLEAN NOT NULL DEFAULT FALSE, subscription_id UUID REFERENCES recurring_subscriptions(id), payment_method VARCHAR(50), -- 'card','sbp','qiwi','yoomoney' payment_id VARCHAR(200), -- ID транзакции в платёжной системе status VARCHAR(20) NOT NULL DEFAULT 'pending' CHECK (status IN ('pending','completed','failed','refunded')), donor_message TEXT, receipt_sent_at TIMESTAMPTZ, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); CREATE TABLE recurring_subscriptions ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), donor_id UUID NOT NULL REFERENCES users(id), program_id UUID REFERENCES programs(id), amount NUMERIC(15,2) NOT NULL, currency CHAR(3) NOT NULL DEFAULT 'RUB', payment_token VARCHAR(200) NOT NULL, -- сохранённый токен карты interval VARCHAR(20) NOT NULL DEFAULT 'monthly' CHECK (interval IN ('weekly','monthly','quarterly')), next_charge_at DATE NOT NULL, status VARCHAR(20) NOT NULL DEFAULT 'active' CHECK (status IN ('active','paused','cancelled','failed')), failed_count INTEGER NOT NULL DEFAULT 0, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW() ); 

Почему рекуррентные платежи — вызов для разработчика?

Сохранение карты, обработка ошибок списания, уведомления при просрочке — каждое действие критично. Мы реализуем через ЮKassa API: при первом платеже запрашиваем save_payment_method=True, получаем токен, и дальше списываем по расписанию. Celery раз в день проверяет подписки с next_charge_at <= today.

import yookassa from yookassa import Payment, Configuration Configuration.configure( account_id=settings.YUKASSA_SHOP_ID, secret_key=settings.YUKASSA_SECRET_KEY, ) def initiate_donation(donation_data: dict) -> str: """Создаём платёж, возвращаем URL для редиректа""" metadata = { 'donation_id': str(donation_data['id']), 'program_id': str(donation_data.get('program_id', '')), 'is_recurring': donation_data['is_recurring'], } payment = Payment.create({ 'amount': { 'value': str(donation_data['amount']), 'currency': 'RUB', }, 'payment_method_data': {'type': 'bank_card'}, 'save_payment_method': donation_data['is_recurring'], 'confirmation': { 'type': 'redirect', 'return_url': f'{settings.BASE_URL}/donation/thank-you?id={donation_data["id"]}', }, 'description': f'Пожертвование в фонд «{settings.FOUNDATION_NAME}»', 'metadata': metadata, 'receipt': { 'customer': {'email': donation_data['email']}, 'items': [{ 'description': 'Благотворительное пожертвование', 'quantity': '1.00', 'amount': {'value': str(donation_data['amount']), 'currency': 'RUB'}, 'vat_code': 1, # Без НДС 'payment_mode': 'full_payment', 'payment_subject': 'another', # Для некоммерческих платежей }], }, }) Donation.objects.filter(id=donation_data['id']).update( payment_id=payment.id ) return payment.confirmation.confirmation_url 

Цикл списания с ретраями: при ошибке увеличиваем failed_count, после 3 ошибок подписка отключается, и отправляется уведомление администратору.

@shared_task def charge_recurring_subscriptions(): """Celery beat: ежедневно в 10:00""" today = date.today() subs = RecurringSubscription.objects.filter( status='active', next_charge_at__lte=today ) for sub in subs: try: payment = Payment.create({ 'amount': {'value': str(sub.amount), 'currency': 'RUB'}, 'payment_method_id': sub.payment_token, 'capture': True, 'description': f'Регулярное пожертвование — {sub.get_interval_display()}', 'metadata': { 'subscription_id': str(sub.id), 'is_recurring': True, }, }) Donation.objects.create( program=sub.program, donor=sub.donor, amount=sub.amount, is_recurring=True, subscription=sub, payment_id=payment.id, status='pending', ) sub.failed_count = 0 sub.next_charge_at = get_next_charge_date(today, sub.interval) sub.save() except Exception as e: sub.failed_count += 1 if sub.failed_count >= 3: sub.status = 'failed' notify_subscription_failed.delay(str(sub.id)) sub.save() logger.error(f'Recurring charge failed for sub {sub.id}: {e}') 

Как обеспечить прозрачность сборов?

Публичные отчёты — основа доверия. Мы формируем агрегированные данные в реальном времени: общая собранная сумма, количество доноров, средний чек, динамика по месяцам, разбивка расходов по категориям.

def get_program_report(program_id: str) -> dict: program = Program.objects.get(id=program_id) donations = Donation.objects.filter( program=program, status='completed' ) expenses = Expense.objects.filter(program=program) return { 'collected': donations.aggregate(total=Sum('amount'))['total'] or 0, 'donors_count': donations.values('donor').distinct().count(), 'avg_donation': donations.aggregate(avg=Avg('amount'))['avg'] or 0, 'expenses': expenses.values('category').annotate( total=Sum('amount'), count=Count('id') ).order_by('-total'), 'utilization_rate': ( expenses.aggregate(s=Sum('amount'))['s'] or 0 ) / program.collected * 100 if program.collected else 0, 'monthly_dynamics': donations.annotate( month=TruncMonth('created_at') ).values('month').annotate(total=Sum('amount')).order_by('month'), } 

После каждого успешного пожертвования автоматически отправляется квитанция с реквизитами фонда — это важно для налогового вычета.

def send_donation_receipt(donation): """Письмо с квитанцией после успешного платежа""" if not donation.donor or donation.is_anonymous: return context = { 'donation': donation, 'foundation_name': settings.FOUNDATION_NAME, 'foundation_inn': settings.FOUNDATION_INN, 'donation_date': donation.created_at.strftime('%d.%m.%Y'), } send_mail( subject=f'Квитанция о пожертвовании на сумму {donation.amount} руб.', message=render_to_string('emails/receipt.txt', context), html_message=render_to_string('emails/receipt.html', context), from_email=settings.FOUNDATION_EMAIL, recipient_list=[donation.donor.email], ) donation.receipt_sent_at = timezone.now() donation.save() 

Что вы получаете в результате

• Архитектуру на Django + PostgreSQL с Celery для фоновых задач
• Интеграцию ЮKassa с рекуррентными платежами и автоматическими ретраями
• Публичные отчёты в реальном времени с API для внешних систем
• Личный кабинет жертвователя с историей, квитанциями и управлением подпиской
• Документацию по API и развёртыванию, обучение команды, 3 месяца гарантийной поддержки

Сравнение: почему наша архитектура выигрывает?

Наш стек на Django обрабатывает до 100 запросов в секунду — в 5 раз быстрее, чем самописное решение на PHP. Использование UUID-ключей исключает конфликты при миграциях и репликации. А Celery с ретраями повышает успешность рекуррентных списаний на 15% по сравнению с cron-скриптами. Автоматизация отчётности экономит фонду до 40 000 руб. в месяц на бухгалтерских услугах.

Сроки и стоимость

Базовый портал (программы, форма пожертвования, личный кабинет): 4–6 недель. Полный функционал с рекуррентными платежами, отчётами и дашбордами: 2–3 месяца. Стоимость рассчитывается индивидуально — пишите, оценим ваш проект.

Почему выбирают нас?

На рынке более 10 лет, реализовали более 50 проектов для НКО и фондов. Гарантируем стабильность и безопасность платежей — наши решения проходят аудит PCI DSS. Опыт работы с Django и ЮKassa позволяет делать сложные интеграции быстро и без сюрпризов.

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