How to Add Cash Funds and Gift Funds to a Baby Registry

Here is the mistake I see teams make with baby registry cash funds: they treat it as a feature and build it as a form. Add a goal, add a progress bar, drop in a card field, done. Then real money starts flowing, a contributor pays twice, a parent cancels a half-funded nursery goal, and suddenly the "feature" is a small unlicensed bank with no ledger. Cash funds and group gift funds are the most trust-sensitive thing a registry does, because you are holding money that belongs to someone else, and the engineering has to respect that from the first line.

What a cash fund actually is

Babylist made the universal registry mainstream: a parent adds items from tens of thousands of retailers including Amazon and Target, plus cash funds and favor requests, all on one list, and Babylist reports 9M+ annual shoppers moving through that model. The cash fund is the piece that quietly changes what you are building. A boxed gift ends when it ships. A cash fund does not end when it is paid, it ends when the money reaches the parent, correctly, with every fee and refund accounted for. That gap between "paid" and "settled" is where the real work lives.

So before any UI, get precise about the money. A contributor pays into a goal. You hold that money through a processor. Some of it may be refunded. Eventually the parent withdraws it, as a payout or a gift card. Every one of those transitions is a state, and every state needs a record. That is the ledger.

The money-movement ledger

This is the framework I hand every team scoping this feature. Model a contribution as a small state machine, not a row that flips from "unpaid" to "paid". Each arrow below is a place money can be lost if you skip the record.

The practical upshot: do not store a fund as "amount raised = $340". Store it as a list of contributions, each with its own status, processor reference, fee and timestamps, and derive the $340. When a dispute lands, you can point at the exact contribution, its fee, and its current state. When you cannot do that, you are guessing, and guessing with other people's money is how registries lose trust in a single bad week.

Fees, and the honesty tax

Every contribution carries a processor cut, usually around 2.9 percent plus a fixed fee per card in most Western markets, and often a payout or currency fee when the money leaves. You have three honest options: absorb the fee as a cost of acquisition, pass it to the contributor, or pass it to the parent. There is no fourth option where the fee disappears. What matters more than which you pick is that you show it before the card is charged. A contributor who thinks they gave $100 and later learns the parent received $94 feels tricked, even though the math was always there. Surface it. The transparency is cheaper than the review.

What everyone gets wrong: treating a cash fund like a live wallet

The most expensive misunderstanding is showing parents a spendable balance the moment money lands, as if you were a bank. You are not, and you should not want to be, because becoming a money transmitter drags you into licensing you do not need. Route contributions through a licensed processor such as Stripe or Adyen, let it hold and move the regulated money, and expose payouts to the parent on a defined trigger: a scheduled release, a manual withdrawal request, or conversion to a gift card. The parent sees a clear "raised so far" and a clear "available to withdraw", and those two numbers are not the same until the money has settled and cleared its refund window. Collapsing them is how you end up paying out cash you later have to claw back.

This is the same discipline we argue for on the retail side of a registry. If you want the wider money picture, our breakdown of how Babylist makes money shows where funds fit alongside affiliate and shop revenue, and how fulfilment works covers the physical-gift half of the same ledger.

The refund matrix, written before launch

Fuzzy refund rules are how you collect chargebacks. Every refund scenario needs a coded answer decided up front, not improvised by a support agent at 2am. The matrix below is the starting point I give teams; the exact windows are yours to set, but the cells must all be filled.

What we build first

• The ledger and processor integration, so every contribution has a state, a fee and a reference before any UI ships.
• The refund matrix in code, with each cell answered and each action logged, because this is what auditors and contributors both rely on.
• Reconciliation you can run daily, proving contributions equal held plus paid plus refunded, minus fees, to the cent.
• Defer multiple currencies, recurring gifting and fancy payout options until the single-currency core reconciles cleanly.

This is exactly how our app development team scopes money features: the ledger and the refund matrix first, the progress bar second. If your registry also needs a bespoke shop or subscription layer around these funds, that is our custom software and SaaS work, built from India for US, UK and EU founders with the payment accounts in your name. Cash funds live or die on trust, and trust is a reconciliation problem before it is a design one. The next feature most teams pair with funds is favor requests, which turns the same contribution machinery toward help instead of money.

Frequently asked questions