One donation, several legal entities, and a donor database that never misses a gift

A gift here is never just one transaction

Club for Growth raises money online for several separate legal entities. Each one keeps its own books and files its own reports, and the rules about who may give, and how much, differ from one to the next. A donor sees none of that, and should not have to. They see one page and one checkout.

The person who answers for that page is the organization's digital lead. Behind them is a finance team that has to reconcile every entity to the cent, and a donor database, Crimson, that the whole organization works from. If a gift lands in the wrong account, or never reaches Crimson, somebody finds out weeks later, in the middle of an election cycle, when there is no time to untangle it.

What the organization had outgrown

The donation flow we had built years earlier still worked, but the organization needed more from it. Donors wanted to give monthly. Supporters increasingly expected to pay with the wallet on their phone. The digital lead wanted a page where a supporter could give to more than one entity, or split a gift across several endorsed candidates, in a single visit.

Finance had its own list. Each entity needed to see what it truly received, with processing fees charged to the entity that incurred them and never quietly absorbed by another. Corporate gifts are allowed for some entities and prohibited for others, and that rule could not be left to the donor to get right.

There was also a practical worry. Crimson has no practice mode. Anything sent to it becomes a real record, so rebuilding the system that feeds it takes unusual care.

What we built, and who each piece was for

One checkout, many committees. A donor fills one cart and pays once, and to them it is a single gift. Behind the page, each entity receives its own separate transaction in its own Stripe account, so every committee's contributions stay distinct, to help the organization stay within FEC guidelines. Each one is tied back to the original payment, so finance can trace any dollar from the donor's card to the entity that received it.

Fees follow the money. The system reads the actual processing fee on each payment and divides it in proportion to each entity's share. Every entity's records show its true net, and no treasurer inherits another entity's costs.

The rules are built into the page. When a donor marks a gift as corporate, the options that federal rules prohibit switch off, and the page says why. The donor cannot make the mistake, so nobody on staff has to catch it afterward.

A gift is never lost to a busy database. The payment completes first. The record then goes to Crimson, and if Crimson is slow or unreachable, the gift waits in line and is delivered when it answers. Donors who sign in see their giving history, drawn from Crimson, and can cancel a monthly gift themselves, with no phone call.

We tested it like the money it moves. Because Crimson has no practice mode, we built a test routine that walks the whole donation path in a real browser and stops for a person to confirm before anything real is created.

How it runs now

The new system went live on a quiet Sunday morning in May 2026, and the first real gift came through within minutes. A few weeks later we added payment by Apple Pay and Google Pay, which the digital lead had asked for to make giving easier on a phone. In September, ahead of the busiest stretch of the cycle, two more affiliated committees joined the same system, at their team's request, so the option would simply be there when it was needed.

For the digital lead, a supporter's gift is one smooth visit, whatever is happening behind it. For finance, each entity's numbers arrive already separated, with the fees in the right place. We keep refining the system with their team between cycles, which is how something this central should be looked after.