Recorder: native app engineering and donation platform for independent journalism

The client

Recorder is the leading independent investigative-journalism newsroom in Romania. Funded almost entirely by reader donations, it produces long-form video investigations that repeatedly shape the public debate — by every reasonable metric, one of the most consequential newsrooms in the country.

A platform like that doesn't get to crash on Sunday morning. The apps and the donation stack have to just work.

The challenge

When we joined, Recorder already had native iOS and Android apps in production — but they needed a steady engineering partner to maintain them, ship major features, and keep both platforms in sync for 3k+ recurring subscribers. Underneath, the money was the harder problem: a payments stack handling hundreds of thousands of transactions across four processors, with Braintree being wound down. Donor data was fragmented across Braintree, Stripe, PayPal, Patreon and Benevity, with no single source of truth for retention or reporting. And Form 230 — Romania's 3.5% income-tax redirection to NGOs — had already produced almost 40k submissions through a manual, PII-heavy paperwork process feeding batch PDFs to the tax authority (ANAF).

The apps

The platform

A REST API on top of WordPress

The Recorder editorial team lives in WordPress. Asking them to migrate to a headless CMS just so the apps could have a clean API would tax the people who actually produce the journalism every day.

Instead, we shipped a WordPress mu-plugin that exposes a clean mobile-api/v1 namespace — authentication, articles, dashboard, FAQ, donations, profile and a GDPR consent log. Firebase verifies the ID token; the server issues an app JWT; every authenticated request additionally carries an x-recorder-auth header. The apps consume the same contract, so a feature shipped on one platform lands on the other within days.

Braintree → Stripe

The most stressful part of the whole engagement. Payment-method tokens don't convert between processors, so a lift-and-shift was off the table. We built a transactional migration that recreates each subscription in Stripe first and only cancels the Braintree side on success — preserving billing-cycle anchors and leaving an auditable trail. A WordPress self-service card re-collection flow covered the subset that needed a fresh payment method.

Result: thousands of subscribers moved between processors with billing-date continuity, a transactional import-then-cancel pipeline, and a logged outcome for every subscription — on top of a payments layer already processing hundreds of thousands of transactions.

How it unfolded

Architecture

Two native clients (iOS SwiftUI, Android Compose) talk to a WordPress REST backend (mobile-api/v1) for content, auth and profile, authenticating via Firebase ID token → app JWT with a GDPR consent log. Payments run through a WordPress Stripe plugin plus a standalone Node/Express service on Render, which integrates Stripe, Braintree, PayPal and Patreon and stores Form 230 contracts in PostgreSQL. A Salesforce CRM consumes that service via daily Apex importers, consolidating every source into one donor view and exporting segmented lists for retention. Batch work — the Braintree→Stripe migration, invoice localization and ANAF PDF generation — runs as offline ops scripts.

Decisions that mattered

• Braintree→Stripe via recreate-then-cancel (transactional), not lift-and-shift — payment-method tokens don't convert, so recreating subscriptions preserved billing anchors and gave an auditable trail, at the cost of a self-service re-collection flow for some donors.
• WordPress as the mobile content/auth backend — reuse the existing editorial workflow, at the cost of shaping REST and auth as mu-plugins and keeping payments in a separate service.
• A dedicated payments service on Render fronting every provider — keeps PCI-adjacent, multi-provider logic and the CRM integration out of WordPress, at the cost of another deployable.
• Strip CNP before CRM import — minimize PII in Salesforce for GDPR, at the cost of keeping ANAF reconciliation in the dedicated Form 230 pipeline.
• A single dynamic Stripe product with per-amount prices — donation amounts vary continuously, so this avoids a brittle plan lookup table, at the cost of many Price objects.

Outcomes

• Two native apps maintained and extended on iOS and Android, serving 3k+ recurring subscribers
• Hundreds of thousands of payment transactions processed across four processors via a dedicated payments service
• Complete Braintree → Stripe migration with billing-date continuity and auditable transactional imports
• Almost 40k Form 230 submissions automated end to end — public intake plus ANAF batch PDFs
• Five payment and donor sources unified into a single Salesforce CRM with automated retention segmentation
• Operational guardrails: automated Stripe health checks and duplicate-customer remediation

Real journalism deserves real engineering. We're proud this one is in our portfolio.