Foundation Portal: Recurring Payments & Transparent Reporting

A foundation loses up to 30% of donations due to payment gateway errors at the confirmation stage — the card is rejected by timeout or fails 3DS. Another 15% of donors never return after a failed payment. The standard CMS — WordPress with a Donation plugin — generates N+1 queries when building a report, and the page loads in 8–10 seconds. Without recurring subscriptions, the average donation per user drops by a factor of 4.

We build portals on Django + PostgreSQL with Celery for background tasks. YooKassa with card saving enables recurring payments with automatic retries — successful charge rates reach 92%. And real-time public reports broken down by programs increase donor trust: foundations with transparent reporting receive 2.5 times more recurring donations. The average one-time donation is 1,500 RUB, and recurring donors contribute 3,000 RUB monthly.

Typical Technical Problems

Typical technical challenges of foundation portals:

• N+1 queries when generating reports — slow page loading up to 10 seconds. Solved by aggregating data in a single query using select_related and prefetch_related.
• Payment gateway failure — loss of the client at the time of payment. We use webhook retransmission and Celery task queues for reprocessing.
• Recurring charges without automatic retries — subscriptions fall off. We implement automatic retries up to 3 attempts with admin notification.
• Lack of online receipts — the donor cannot claim a deduction. We generate PDF receipts with an electronic signature.
• Lack of expense transparency — undermines trust in the foundation. We publish real-time reports broken down by categories.

Each problem is solved by a specific technical solution: data aggregation, webhook retransmission, Celery task queue, PDF generation.

How We Build the Portal Architecture?

Standard stack: Django as API + React on the frontend + PostgreSQL + Celery for background tasks. We use UUID keys — this eliminates conflicts during migrations and replication. The data schema is normalized, with separation of programs, donations, and subscriptions.

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 = no target 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 = statutory activities donor_id UUID REFERENCES users(id), -- NULL = anonymous donation 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), -- Transaction ID in payment system 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, -- Saved card token 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() ); 

Why Recurring Payments Are a Challenge for Developers?

Saving a card, handling charge errors, sending notifications on overdue — each action is critical. We implement via YooKassa API: on the first payment, we request save_payment_method=True, obtain a token, and then charge on schedule. Celery checks daily for subscriptions with 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: """Create a payment, return redirect 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'Donation to the “{settings.FOUNDATION_NAME}” foundation', 'metadata': metadata, 'receipt': { 'customer': {'email': donation_data['email']}, 'items': [{ 'description': 'Charitable donation', 'quantity': '1.00', 'amount': {'value': str(donation_data['amount']), 'currency': 'RUB'}, 'vat_code': 1, # No VAT 'payment_mode': 'full_payment', 'payment_subject': 'another', # For non-commercial payments }], }, }) Donation.objects.filter(id=donation_data['id']).update( payment_id=payment.id ) return payment.confirmation.confirmation_url 

The charge cycle with retries: on error, increment failed_count; after 3 errors, the subscription is disabled, and an admin notification is sent.

@shared_task def charge_recurring_subscriptions(): """Celery beat: daily at 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'Recurring donation — {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}') 

How to Ensure Fundraising Transparency?

Public reports are the foundation of trust. We generate aggregated data in real time: total amount raised, number of donors, average donation, monthly dynamics, expense breakdown by category.

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'), } 

After each successful donation, a receipt with the foundation's details is automatically sent — this is important for tax deductions.

def send_donation_receipt(donation): """Email with receipt after successful payment""" 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'Receipt for donation of {donation.amount} RUB', 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() 

What You Get as a Result

• Architecture on Django + PostgreSQL with Celery for background tasks
• YooKassa integration with recurring payments and automatic retries
• Real-time public reports with an API for external systems
• Donor account with history, receipts, and subscription management
• API and deployment documentation, team training, 3 months of warranty support

Comparison: Why Our Architecture Wins?

Our Django stack handles up to 100 requests per second — 5 times faster than a custom PHP solution. Using UUID keys eliminates conflicts during migrations and replication. And Celery with retries increases successful recurring charge rates by 15% compared to cron scripts. Automated reporting saves the foundation significantly on accounting services.

Timeline and Cost

Basic portal (programs, donation form, account): 4–6 weeks. Full functionality with recurring payments, reports, and dashboards: 2–3 months. The cost starts from 350,000 RUB for the basic version and 750,000 RUB for the full version. Contact us for a detailed estimate.

Why Choose Us?

We have been on the market for more than 10 years, have completed over 50 projects for NPOs and foundations. We guarantee stability and payment security — our solutions undergo PCI DSS audit. Experience with Django and YooKassa allows us to make complex integrations quickly and without surprises.

If you want to increase recurring donations by 30% — get in touch, we will prepare a proposal. Receive a consultation: fill out the form on the website — we will discuss your project and prepare a commercial offer.