Monthly giving in Malaysia: how recurring donations actually work (and why they matter)

The donor who calls asking why their gift stopped

A donor set up RM50 a month in March. In August, nothing came through. Nobody at your organisation noticed until the donor called, faintly annoyed, asking if something was wrong with their account.

This is the most common recurring-giving failure, and it usually has one cause: the card the donor used has expired, been reissued, or been blocked by their bank — not fraud, not a change of heart.

When a donor agrees to give monthly by card, the gateway doesn't keep the card number the way a wallet app might. It stores a token — a reference it can use to charge that same card again without the donor re-entering anything. Visa and Mastercard both require consent before that token is created, and both require charging to stop the moment the cardholder cancels under the agreed terms ^[7][8]. Visa frames this as its Stored Credential Transaction framework (10 May 2017) ^[7]; Mastercard's gateway rules mark the first payment "to be stored" and every later one as "stored" ^[8].

The catch is that a token tied to a physical card doesn't survive that card's expiry, cancellation, or reissue the way a bank account reference would. Some networks auto-update a token on reissue, but that isn't universal, and a blocked or over-limit card fails regardless. Either way, the charge simply doesn't go through — quietly, until someone notices.

Practical tips:

• Never assume silence means the donor changed their mind. Check the failure reason before assuming disengagement.
• Card failures cluster: a batch of donors on the same bank's reissued card range can all fail in the same week. Don't treat each one as an isolated case.
• Warn donors before it happens, not after — a "your card expires next month" nudge converts far better than "we noticed your gift stopped."

Can FPX or DuitNow just do this automatically?

The honest answer is: not the way most NPOs assume.

FPX is built for a single push of money from the donor's own online banking session — log in, confirm, done. PayNet's own description of FPX is a one-time "pay your bills or send money" flow; there is no mechanism in it for the bank to repeat the payment on its own next month ^[4]. If a donor "sets up FPX for monthly giving," in practice someone has to come back and repeat the FPX flow every month — which is exactly the manual, forgettable process this article's readers are trying to get away from.

DuitNow AutoDebit is the rail actually designed for this. PayNet describes it as letting a business "collect payments automatically from your customers with just one-time consent" ^[1] — the donor authorises it once, through their bank or e-wallet app, and the biller can then debit their CASA, Line of Credit account, or e-wallet on a recurring or ad-hoc basis ^[3]. Consent is managed on the bank's side too: PayNet's own consent-maintenance documentation states a customer can "view, update, terminate and transfer their consent via their respective banks" — initiated with their issuer, independent of the organisation collecting the money ^[9]. That's a real advantage over a card: a bank account doesn't expire.

Why it isn't simply "switched on" for a donation platform is integration, not policy: a payment gateway has to build a separate connection to PayNet's AutoDebit consent and collection APIs, on top of ordinary card and FPX checkout. Whether it's available to you depends on whether your gateway has built that connection — check current support in Which payment methods you can use, and see Online donation payment methods for how the methods differ for one-off gifts.

Practical tip: if someone asks "why can't we just do this through FPX", the honest answer is that FPX was never built to repeat itself — the rail for that is DuitNow AutoDebit, and whether it's available to you is a question for your payment gateway.

The old-school bank standing instruction

Long before any of this, the standard advice to a monthly donor was "set up a standing instruction at your bank." It still works, technically — the donor's own bank pushes a fixed amount to your account on a fixed date, indefinitely, until the donor cancels it themselves.

The problem isn't whether it works — it's that it's invisible to you until the money lands. You can't see it was set up, see when the donor changes or cancels it, or automatically tie an incoming transfer to a donor, campaign or month unless the donor is scrupulous about the reference field (most aren't). Every standing instruction becomes a manual matching task at reconciliation time — see Month-end reconciliation for donations.

Practical tips:

• If a donor insists on a standing instruction rather than a card or DuitNow AutoDebit setup, ask them to use a fixed, consistent reference (their name or a donor ID) every time — it's the only thing that makes matching possible later.
• Don't promise a donor on a standing instruction the same real-time confirmation you'd give a card donor. The money genuinely might take a day or more to appear, and you have no visibility before it does.

The donor who wants to change or stop giving

A donor's circumstances change. They want to give RM30 instead of RM50, skip a month, or stop altogether — and the worst experience you can give them is having to phone your office and ask someone to do it for them.

Because DonorCARE's recurring giving runs on a saved card, changes to it — pausing, resuming, changing the amount, replacing the card, or cancelling — go through a private management link emailed to the donor, rather than requiring a login. The donor confirms their email address on that link and can adjust the amount or frequency (minimum RM10), pause, resume, update the card, or cancel outright; cancelling is final. This is deliberately separate from the donor's own /my-account dashboard, where they can review giving history and download receipts but not manage the recurring plan itself.

From your side, the Recurring list shows every donor's standing gift and its status — Active, Paused, Canceled, or Expired — along with how many charges have failed in a row and whether a "Card expiring" badge is showing. When retries run out on a failing card, DonorCARE pauses the subscription on its own; nothing further is charged until someone — you or the donor — updates the card.

Practical tips:

• Point donors to the management link in every recurring-related email rather than asking them to remember a URL — it's tied to that specific donation, not a general login.
• A "Paused" subscription is not the same as a lost donor. Treat it as a worklist, not a write-off, and reach out before it lapses into Canceled.

One receipt a month, not one certificate a year

A well-meaning donor sometimes asks for "one annual receipt" for their monthly giving, the way some other countries' donation platforms bundle a year's giving into a single certificate at tax time.

In DonorCARE, each successful monthly charge is its own completed donation — the same record type as a one-off gift, with its own status, receipt, and (where applicable) e-Invoice. That's also why a single month's charge, and only that charge, can be voided or flagged for a gateway reversal without touching the other eleven months. What has to be on each receipt is covered in What must be on a valid donation receipt; how consolidated e-Invoicing fits alongside per-charge receipts is in Do we need an e-Invoice for a donation?.

Practical tip: if a donor specifically wants one document to show their accountant, a "giving summary" listing every receipt in the tax year is a reasonable thing to offer alongside — not instead of — the per-charge receipts your approval requires.

Forecasting monthly income for the committee

A committee member asks, reasonably, "how much can we count on next month?" That needs a different lens from your usual donation totals, because a recurring gift is a standing commitment, not a one-off event that either happened or didn't.

Track two numbers separately: what's currently committed (every active subscription's amount added together as it stands — monthly, quarterly and yearly gifts at face value, not converted to a common rate) and what actually stopped this month, counted only once a subscription is cancelled or its card has expired with no replacement. A subscription still retrying a failed charge isn't gone yet — it's "at risk," a separate worklist from anything reported as lost. Counting a retrying subscription as churn understates your base; counting it as healthy hides a problem before the committee sees it.

Practical tips:

• Report committed monthly value and at-risk subscriptions as two separate lines, not one blended number.
• Recovery matters as much as the initial failure rate — of the subscriptions that ever hit a failed charge, track how many go on to recover, since that's the number a nudge campaign or a card-update reminder actually moves.

What this means for your organisation

1. Decide your recurring rail deliberately. Card-based recurring giving is the practical default — treat DuitNow AutoDebit and bank standing instructions as alternatives with real trade-offs, not upgrades.
2. Build card-expiry handling into donor communications, not just automatic retries — a nudge before expiry keeps more gifts alive than a recovery email after failure.
3. Give donors a self-service way to change or stop their own gift. One who has to phone your office to reduce their amount is at risk of cancelling instead.
4. Treat "paused" and "at risk" subscriptions as an active worklist, separate from churn, and work through it regularly rather than only when a donor complains.
5. Keep receipts and e-Invoices per charge, matching the rules for any other completed donation — don't improvise a once-a-year certificate your approval or e-Invoice obligations don't call for.
6. Report committed monthly value and churn separately to your committee, and never let a retrying subscription hide inside either number.