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

> Malaysia has no single rail built for "charge this donor every month." FPX is a one-time online banking payment — it cannot repeat itself [4]. DuitNow AutoDebit is a genuine recurring rail (one-time consent, then scheduled debits from a bank or e-wallet account) [1][2], but it's a distinct product a payment gateway has to integrate separately from ordinary FPX or card checkout. In practice, almost every recurring-donation setup in Malaysia — including DonorCARE's — runs on **tokenised card charges**: the donor's card is saved once, and the gateway charges it again on each due date [5]. That's why recurring giving only works by card, and why a card that expires, gets replaced, or gets blocked is the single most common reason a monthly gift stops without anyone deciding to stop it.

Source: https://donorcare.my/resources/monthly-giving-recurring-donations
Reviewed: 2026-09-28

Reference material, not legal or tax advice. Confirm with LHDN or your own advisor before acting.

## 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](https://donorcare.my/help/organisations/finance/connect-your-payment-gateway/), and see [Online donation payment methods](https://donorcare.my/resources/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](https://donorcare.my/resources/month-end-reconciliation-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](https://donorcare.my/help/organisations/donations/manage-recurring-donations/) 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](https://donorcare.my/help/organisations/donations/void-or-refund-a-donation/) without touching the other eleven months. What has to be on each receipt is covered in [What must be on a valid donation receipt](https://donorcare.my/resources/valid-donation-receipt); how consolidated e-Invoicing fits alongside per-charge receipts is in [Do we need an e-Invoice for a donation?](https://donorcare.my/resources/e-invoice-for-donations).

**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.

## Common questions

### Can we accept monthly donations by FPX or DuitNow QR?

Not as an automatically repeating charge. FPX is a one-time online banking payment with no mechanism to repeat itself [4]; DuitNow QR is a one-off scan-and-pay too. The rail built for recurring collection is DuitNow AutoDebit, a separate consent-based product [1][2] — whether it's available to you depends on your payment gateway's integration; see [Which payment methods you can use](https://donorcare.my/help/organisations/finance/connect-your-payment-gateway/).

### Why did a donor's monthly gift just stop with no warning?

Usually the saved card — expired, reissued, blocked or over-limit. Card networks require charging to stop once that happens rather than retry indefinitely [7][8], so DonorCARE retries automatically for a few days and then pauses the subscription if nothing succeeds.

### Is a bank standing instruction a better option than a card?

It solves the expiry problem, since a bank account doesn't expire. What it costs you is visibility — you can't see it was set up, see it change, or reliably match the transfer to a donor without a consistent reference field, which turns it into manual reconciliation work.

### Can a donor change their own recurring amount without calling us?

Yes, through a private management link sent by email — no account or login required. They can change the amount or frequency, pause, resume, replace the card, or cancel.

### Do we need Bank Negara Malaysia's approval to run recurring card donations?

No separate approval is needed to accept recurring card payments as a merchant — that's between your gateway and the card networks. BNM's current Policy Document on Credit Card and Credit Card-i (19 December 2025) has no dedicated provisions on recurring or standing-instruction protections beyond a narrow mention of auto-debit in the context of over-limit fee consent [6]; it isn't the source to cite for recurring-payment rules.

### Should a monthly donor get one receipt at the end of the year instead of twelve?

DonorCARE issues a receipt per completed charge, matching how every other donation is receipted and e-Invoiced. See [What must be on a valid donation receipt](https://donorcare.my/resources/valid-donation-receipt) and [Do we need an e-Invoice for a donation?](https://donorcare.my/resources/e-invoice-for-donations).

### What happens to a reserved name or slot (a tablet, a dedication) if a monthly charge fails?

Outside what this article's sources cover generally — check the specific offering or ceremony feature, since reservation rules differ by campaign type.

## Where DonorCARE fits

- **Recurring donations run through your own CHIP gateway**, charged to the donor's saved card, with automatic retries before a subscription is paused. [See Payments](https://donorcare.my/features/payments) · [Connect your payment gateway](https://donorcare.my/help/organisations/finance/connect-your-payment-gateway/)
- **Recurring health, not just a donation total.** [Recurring health](https://donorcare.my/help/organisations/insights/recurring-health/) separates committed monthly value from churn and from the at-risk subscriptions still worth working — the split this article recommends for a committee.
- **The Recurring list flags which donor needs a nudge** before you hear it from them — failed-charge counts, a card-expiring badge, and status at a glance. [Manage recurring donations](https://donorcare.my/help/organisations/donations/manage-recurring-donations/)
- **Donors change or cancel their own gift** through a private, no-login link emailed to them — amount, frequency, card, pause, resume or cancel.
- **Every charge is its own record**, so a single month's gift can be voided or flagged for reversal alone, without disturbing the rest of the subscription's history. [Void or refund a donation](https://donorcare.my/help/organisations/donations/void-or-refund-a-donation/)
- **Gateway onboarding for recurring gifts** is part of the same CHIP setup as one-off donations. [Register a CHIP account](https://donorcare.my/help/organisations/finance/register-a-chip-account/)

You can [start free](https://donorcare.my/pricing) and turn on recurring giving as soon as your CHIP gateway is connected. [Why DonorCARE →](https://donorcare.my/why-donorcare)

## Sources

1. PayNet, _DuitNow AutoDebit — Business Solutions_, accessed 28 September 2026\. <https://paynet.my/business-solutions/duitnow-autodebit.html> — collects recurring or one-off payments after a one-time customer consent given via bank or e-wallet app.
2. PayNet, _DuitNow AutoDebit — Personal Solutions_, accessed 28 September 2026\. <https://paynet.my/personal-solutions/duitnow-autodebit.html> — consumer-facing description: "Link your DuitNow ID to your preferred bank or eWallet" to set up AutoDebits.
3. PayNet Developer Documentation, _DuitNow AutoDebit — Overview_ (version SIT-2.0.4). <https://docs.developer.paynet.my/docs/duitNow-AutoDebit/introduction/overview> — states DuitNow AutoDebit payments are collected from Current Account Savings Account (CASA), Line of Credit (LOC) Account and eWallet.
4. PayNet, _FPX — Personal Solutions_, accessed 28 September 2026\. <https://paynet.my/personal-solutions/fpx.html> — describes FPX as a single online-banking payment ("pay your bills or send money"); no recurring or standing-instruction mechanism is described.
5. CHIP, _CHIP Collect API Reference — Purchases_, <https://docs.chip-in.asia/chip-collect/api-reference/purchases/create> — `remember_card` creates a reusable card token (`is_recurring_token`); a stored token is charged via `recurring_token`; `force_recurring` saves credentials without a prompt.
6. Bank Negara Malaysia, _Policy Document on Credit Card and Credit Card-i_ (BNM/RH/PD 028-141), issued 19 December 2025 (supersession not checked — see note below). <https://www.bnm.gov.my/documents/20124/938039/credit%5Fcard%5Fand%5Fcredit%5Fcard-i%5FPD.pdf> — no dedicated recurring-payment consumer-protection section; auto-debit appears only incidentally (paras 15.2(c), 50.4(c)). Not a rule source for recurring-donation mechanics.
7. Visa Inc., _Improving Authorization Management for Transactions with Stored Credentials_ (Stored Credential Transaction Framework), dated 10 May 2017 (supersession not checked — see note below). <https://usa.visa.com/content/dam/VCOM/global/support-legal/documents/stored-credential-transaction-framework-vbs-10-may-17.pdf> — requires consent before initial credential storage; merchant must not complete a transaction once the cardholder cancels.
8. Mastercard, _Gateway Integration Guidelines — Stored Credentials_. <https://na.gateway.mastercard.com/api/documentation/integrationGuidelines/supportedFeatures/pickAdditionalFunctionality/storedCredentials.html> — Confirms the `storedOnFile = TO_BE_STORED` (initial) versus `STORED` (subsequent) field values, and that a new cardholder-initiated transaction is required if the card number changes (other than reissue or network-token updates).
9. PayNet Developer Documentation, _DuitNow Consent — Consent Maintenance_. <https://docs.developer.paynet.my/docs/duitNow-consent/integration/consent-maintenance> — States "Consent maintenance will allow customers to view, update, terminate and transfer their consent via their respective banks," initiated with the issuer independent of the merchant.
