CARE Business Apps
Partly liveSix apps, one sign-in, and two bridges already built
A donation platform should not also try to be a CRM, a ticketing marketplace and a bookkeeping ledger. Those already exist next door, under one CARE account. Two of them are wired into DonorCARE today. This page is the honest map of the rest — what crosses the line now, what we intend to build, and what is still an open question.
The shape of the family
- 6
- apps under one CARE account
- 2
- wired into DonorCARE today
- 9
- event types a sibling can subscribe to
- 0
- second passwords to remember
The spine
Live todayFederated identity is already working across all six
JomCARE is the identity hub for the suite: one account, and a set of roles held per organisation, per product. DonorCARE already reads those roles — the app switcher in your sidebar decides what to show you from evidence about you, not from a guess. This is the unglamorous part that makes everything below near rather than hypothetical: the hard question of who someone is, and what they are allowed to touch in which organisation, is answered once for the whole family.
- One account across DonorCARE, BizCARE CRM, BizCARE Books, TicketCARE, FormCARE and myRIBI
- Roles are scoped per organisation and per product, not global
- The switcher opens a door only where you actually hold a role — where the organisation has the app but you do not, it asks an owner instead of dead-ending you at another product's login
- No entitlement information means the hub said nothing, never that you are unsubscribed — the switcher is built to under-promise rather than deny
Bridge one, built
Live todayBizCARE Books — a receipt becomes a filed e-invoice
The statutory bridge is the one that had to work first, because it has a deadline attached and a regulator on the other end. A completed donation becomes a receipt; the receipt becomes an LHDN e-invoice through the BizCARE Books API — LHDN e-Invoicing (MyInvois) is the capability that is live today; a direct bookkeeping ledger link is next. The submission carries a real status back, and a cron re-checks it twice a day rather than assuming silence means success.
- TIN validation tracked per submission
- Auto-submit runs twice daily, batched inside LHDN's rate limit
- Status flows back: draft, pending, submitted, valid, invalid, cancelled
- The monthly consolidated run files on the 4th
Bridge two, built
Live todayFormCARE — a form that knows which donation it belongs to
The second bridge proves a softer case: that a sibling app can own a whole surface, and DonorCARE can still keep the join. Attach a FormCARE form to a campaign and a donor fills it during checkout, or later from a reminder email. The response comes back attached to the right donation, because DonorCARE mints the reference before the donor ever reaches the form and verifies it on the way back.
- A form step inside checkout, or a fill-later reminder email
- Responses sync back against the donation, not into a separate silo
- A FormCARE outage cannot block a donation or a campaign deletion — the link degrades, the money does not
Design intent — not built yet
Building nextBizCARE CRM: where a donor stops being only a donor
This is the next bridge, and the most interesting one, because it is where the suite stops being a bundle and starts being a system. A temple's donor is often also a member, sometimes a beneficiary's family, occasionally a supplier. DonorCARE knows the giving; BizCARE CRM holds the relationship, the membership roll, the memorial registry — and an Outreach module that sends WhatsApp through the Business Cloud API with paced delivery and consent recorded against the contact. We intend the join to run on the events DonorCARE already emits: a completed donation and a tier change are exactly the triggers an outreach module wants, and they already fire as signed webhooks with delivery failures counted. Consent is the part we will not shortcut — it has to live in one authoritative place, and a send has to be refusable from either side.
- Intended direction: DonorCARE emits, the CRM consumes — giving history enriches a contact rather than being copied into a second database
- Consent held once and honoured everywhere; a donor who opts out of WhatsApp must not be reachable through a back door
- Delivery results land back against the donor record, so a bounced message is visible where the relationship lives
- Not built. No date implied — read the ledger below before planning around it
Design intent — not built yet
Via TicketCARETicketCARE: an attendee and a donor are not the same record
Ceremony registration in DonorCARE is a gift with a dedicated name attached — a memorial tablet, a blessing slot — and it receipts under Section 44(6). A ticket is admission: a seat, a capacity, a scan at a door, and a sale rather than a gift. Collapsing the two would be the easy mistake and the wrong one, because the tax treatment differs and so does the paperwork. The genuinely hard question we have to answer before building anything is ownership: when a ticket buyer also gives, which system issues the receipt, and which number goes on it. TicketCARE also deliberately runs its own sign-in door rather than joining the federated hub, so this bridge has an identity problem the others did not.
- DonorCARE today: gift plus dedicated name, receipted under s44(6). No seats, no admission, no check-in
- TicketCARE today: a separate product with its own login and its own gateway keys
- Open question, stated rather than hidden: receipt ownership when one person both buys and gives
- Intended first step is the narrow one — syncing event donations back, not merging the two record types
Design intent — not built yet
Coming soonBizCARE Books ledger sync: a sub-ledger looking for a general ledger
DonorCARE is deliberately not an accounting system. It holds no chart of accounts, no trial balance, no fiscal-year configuration — it is a donor sub-ledger that records gifts, dates and receipts and then feeds the books you already keep. Today that hand-off is a file: a SQL Accounting XML export an admin downloads and imports, plus CSV and JSON. A direct ledger link into BizCARE Books — the same connection that already carries LHDN e-Invoicing — is the better answer to the same problem, and the discipline is the same one that makes the export trustworthy — cash-basis dates, test money excluded, and figures that reconcile rather than approximately agree.
- Today: one-way SQL Accounting XML export, downloaded and imported by hand
- DonorCARE stays a sub-ledger either way — the general ledger is not a feature we intend to grow
- Whatever crosses must carry the cash-basis date, not the entry date
Where each link actually stands
The rows above include work we intend to do. This is the part that does not. If you are choosing a platform on the strength of a sibling app, buy on this list and nothing else.
Working today, in production
- One CARE account across six apps
- Federated sign-in through JomCARE, with organisation and product roles read by DonorCARE's own app switcher.
- BizCARE Books — LHDN e-Invoicing
- Receipts filed to LHDN with TIN validation, twice-daily auto-submit and status sync, and a monthly consolidated run.
- FormCARE forms on campaigns
- A checkout form step or a fill-later reminder, with responses synced back against the donation.
- Outbound webhooks
- Nine signed event types any system — sibling or your own — can subscribe to today, with delivery failures tracked.
The next bridge we build
Actively being designed. Nothing here is available to buy, and no date is implied.
- BizCARE CRM relationship sync
- Giving history enriching a contact record, rather than a second copy of your donor database.
- WhatsApp outreach with real consent
- Paced sending through the Business Cloud API, consent held authoritatively in one place, delivery results returning to the donor record.
Named, scoped, not started
Real products with real open questions between them and DonorCARE. Listed so you can see the direction, not so you can plan around a date.
- TicketCARE event donations
- Blocked on a decision we have not made: who owns the receipt when a ticket buyer also gives, and how two sign-in doors become one journey.
- BizCARE Books direct posting
- Replacing the manual SQL Accounting export with a direct hand-off on a cash-basis date.
- myRIBI
- A companion app for NPOs and houses of worship. It holds a seat in the switcher; what it would hand DonorCARE is genuinely not settled, and we would rather say that than invent a roadmap line.
Frequently asked questions
Do I have to buy the whole suite?
No. DonorCARE stands on its own and always will — every capability on the rest of this site works without a single sibling app installed. The suite is an option, not a prerequisite, and it is priced per product rather than as a bundle you have to swallow.
Is my donor data copied into these other apps?
Not today, because the bridges that would do it do not exist yet. When they do, the intent is that DonorCARE emits events a sibling consumes, rather than replicating your donor database into a second system — one authoritative copy, enriched elsewhere. Your organisation owns that data either way, and can export it in full at any time.
You keep saying 'intend'. Why not just give a date?
Because a date on a marketing page is a promise, and we have watched enough software roadmaps to know which ones get kept. What we can commit to is the direction and the order: BizCARE CRM next, TicketCARE and Books after, and this page updated when a status genuinely changes rather than when it would be convenient.
What happens if a sibling app goes down?
Donations keep working. That is a design rule, not a hope — the FormCARE link already degrades this way: a FormCARE outage cannot block a donation, and it cannot block deleting a campaign either. Every future bridge is built to the same standard, because the money path is the one thing that must not have a second point of failure bolted onto it.
Can I connect my own systems instead of waiting?
Yes, and some organisations should. Nine event types fire as HMAC-signed outbound webhooks with failure tracking, and exports cover donation CSV, receipt batches, a full JSON export, and the LHDN and SQL Accounting formats. That is the same door the sibling apps will come through — you do not have to wait for us to walk through it first.
Is single sign-on available on every plan?
Sign-in through JomCARE is how DonorCARE accounts work — it is not an enterprise upsell. What varies by plan is which integrations you can switch on: MyInvois e-invoicing and API and webhook access are Enterprise features, while CHIP payments and email are available from Free.
Start with the donation platform
The suite is where this is going. DonorCARE is what works today — and it works on its own.