Foundation Portal: Recurring Payments & Transparent Reporting

Our company is engaged in the development, support and maintenance of sites of any complexity. From simple one-page sites to large-scale cluster systems built on micro services. Experience of developers is confirmed by certificates from vendors.

Development and maintenance of all types of websites:

Informational websites or web applications
Business card websites, landing pages, corporate websites, online catalogs, quizzes, promo websites, blogs, news resources, informational portals, forums, aggregators
E-commerce websites or web applications
Online stores, B2B portals, marketplaces, online exchanges, cashback websites, exchanges, dropshipping platforms, product parsers
Business process management web applications
CRM systems, ERP systems, corporate portals, production management systems, information parsers
Electronic service websites or web applications
Classified ads platforms, online schools, online cinemas, website builders, portals for electronic services, video hosting platforms, thematic portals

These are just some of the technical types of websites we work with, and each of them can have its own specific features and functionality, as well as be customized to meet the specific needs and goals of the client.

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1358
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    956
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    947

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?

Feature Our Django Stack Custom PHP Solution
Requests per second 100 20
Successful recurring charge rate 92% 77%
Report loading time <1 sec 8-10 sec
Annual cost for accounting 0 ~120,000 RUB

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.

Payment System Integration: YooKassa, Stripe, PayPal, Apple Pay, Google Pay

Conversion dropped by 12% immediately after the redesign. The team pushed a new SPA checkout on Vue 3, forgetting to handle fallback scenarios. Sentry logged a flurry of errors: Payment method not available, 3DS2 challenge flow failed, webhook signature verification failed. Users abandoned carts at the payment method selection stage. Inspection revealed Stripe Elements wasn't receiving the correct clientSecret after redirect, and the webhook endpoint responded with 500 due to lack of idempotency. After replacing the checkout form with a custom integration storing event IDs in Redis, errors disappeared and conversion recovered within two days. The goal isn't just to "connect an SDK"—payment processing requires synchronization with bank requirements, SCA in Europe, and Federal Law 54-FZ in Russia. Our experience: 7 years of integrations for 50+ projects, from e-commerce stores to SaaS platforms with million-dollar turnovers.

What's Included in Turnkey Work

  • Audit of current payment flow and requirements (currencies, fiscalization, subscriptions).
  • Provider selection based on geography and business model.
  • Backend integration (Laravel/Node.js/Go) with webhook handling, idempotency, and retries.
  • Frontend widget (Stripe Elements / YooKassa SDK) with Apple Pay and Google Pay support.
  • Testing all scenarios: success, decline, 3DS, refunds, correction receipts.
  • Monitoring of first transactions and documentation.

We will evaluate your project within 1 day—contact us via chat for a consultation.

Provider Comparison: Which to Choose

Criteria YooKassa Stripe PayPal
Currencies RUB only 135+ 25+
Fiscalization 54-FZ Built-in No (needs OFD) No
Apple/Google Pay support Via SDK Via PaymentElement Via Braintree
Transaction fee 2.5–4% 2.9% + $0.30 2.99% + $0.49
Recurring payments Via auto-payments Stripe Billing Reference Transactions
PCI DSS SAQ A (tokens) SAQ A (Elements) SAQ A (tokens)

Stripe wins on flexibility: 135+ currencies vs. YooKassa's single currency. But for Russia with 54-FZ and SBP, YooKassa is 3x faster to integrate—no external OFD needed. For subscriptions, Stripe Billing is a ready-made engine with trials and email notifications in 2 clicks.

How to Choose the Right Provider?

Three key points. Where do your clients live? Only Russia → YooKassa; globally → Stripe. Do you need 54-FZ fiscalization? Yes → YooKassa; otherwise Stripe + cloud OFD. Do you plan subscriptions? Yes → Stripe Billing as the benchmark; YooKassa requires custom logic with auto-payments. Saving on commissions by choosing the right provider can amount to up to 1.5% of turnover. For a project with 2 million RUB per month, that's 360,000 RUB per year.

Where the Real Difficulties Lie

Setting up a test mode takes an hour. Properly handling all scenarios takes weeks.

Webhook reliability. A webhook may not arrive—server unavailable, timeout, network issues. The provider retries with exponential backoff (Stripe up to 3 days). The handler must be idempotent: if payment.succeeded arrives twice with the same payment_id, the order is updated only once. This is implemented by storing event IDs in Redis with a TTL.

3DS2 and redirect flow. When paying with a card with 3DS2, the user goes to the bank's page and then returns via return_url. During this time, the session may expire or the cart may be cleared. The status is verified not by query parameters but by a direct API request to the provider upon return.

Partial refunds and receipts. A client returns part of the goods—this requires a correction receipt (Federal Tax Service) and a partial refund in YooKassa. Stripe natively supports partial_refund. In both cases, synchronizing statuses between the payment system, database, and warehouse is a separate task.

Currency limitations. YooKassa only handles rubles. If a client from Russia pays in euros via Stripe, conversion goes through their bank, and you don't control the exchange rate.

Why Do Webhooks Require Idempotency?

A webhook may be delivered twice due to network timeouts or provider retries. Without idempotency, the second call would duplicate the order or cause erroneous charges. The solution is to store a unique event ID (e.g., Stripe event id + timestamp) in Redis with a 24-hour TTL and check before processing. If the ID already exists, return 200 without executing business logic. Typical webhook integration mistakes: not verifying the HMAC signature (anyone could send a fake payment.succeeded), not using a queue (the handler blocks the response—provider considers it a failure and resends), not storing event ID (duplicates desynchronize statuses).

How We Build the Integration

Architecture. We never store card data—only tokens from the provider. Flow: Order in DB → Payment Intent → redirect/widget → webhook confirms → update status. The source of truth is the status in the payment system.

For Laravel we use stripe/stripe-php or yookassa-sdk. Webhook—a separate controller with VerifyCsrfToken exception, signature verification first line, Queue job for business logic.

For Next.js/React—@stripe/stripe-js + @stripe/react-stripe-js. PaymentElement includes Apple/Google Pay automatically. Example:

const stripe = await stripePromise;
const { error } = await stripe.confirmPayment({
  elements,
  confirmParams: { return_url: 'https://example.com/order/thank-you' },
});

Testing. Stripe CLI: stripe listen --forward-to localhost:8000/webhook. Test cards for all scenarios (3DS, decline, insufficient funds). Cypress checkout flow test in CI—mandatory stability guarantee.

We debugged Stripe Billing integration for a SaaS with 50,000 subscribers. The issue was handling invoice.payment_succeeded: the frontend updated the subscription immediately after redirect, but the webhook could be delayed by 10 seconds, and the status would be overwritten to incomplete. Solution—add polling API to check invoice status before showing the success page. This reduced erroneous cancellations by 18%.

Process and Timeline

Audit → provider selection → backend → frontend → tests → deploy → monitoring.

Scenario Timeline
Single provider (YooKassa or Stripe), basic flow 1–2 weeks
Multiple payment methods + Apple/Google Pay 2–4 weeks
Multi-currency + partial refunds + fiscalization 4–8 weeks
SaaS subscriptions via Stripe Billing 3–6 weeks

Pricing is custom. Order integration and your checkout won't crash on the next update.

Links:

We guarantee: 7 years of experience, 50+ successful integrations. Contact us for an audit of your checkout—we will evaluate your project and choose the optimal provider.