Recurring payments on your own store

Subscription boxes, refill plans and standing monthly orders are increasingly common on Malaysian stores, and they are attractive for obvious reasons: predictable volume, better customer lifetime value, less acquisition spend per sale.

The mechanics underneath are meaningfully different from a one-off checkout, and the differences all land on finance rather than on marketing.

Tokenisation and where the card lives

You do not store the card. The gateway does, and it gives you a token — a reference that lets you charge that customer again without ever holding their card number.

Three consequences follow from that, and they are the ones that matter.

The token belongs to the gateway. It is not portable. Change provider and the tokens are worthless, so every subscriber has to re-enter their details, and a proportion of them simply will not — see switching payment gateway without losing your history.

Cards expire and get replaced. A token attached to a card that has been reissued stops working, silently, on a date you did not choose. Some networks and providers update tokens automatically when a card is reissued; many do not, and whether yours does is a specific question worth asking.

Not every method can be tokenised. Cards generally can. Bank transfer through FPX is a one-time authorisation by design, so a recurring charge on it needs a separate mandate arrangement rather than a stored token. If your customers overwhelmingly pay by FPX, this shapes what you can offer — see FPX settlement and what it does to your cash.

Failed renewals and the dunning cycle

A one-off sale that fails is a lost sale. A renewal that fails is a customer you already have, mid-relationship, whose payment did not go through for a reason that is usually temporary.

Handling that badly loses customers you had already won, which is the most expensive kind of churn.

The pattern that works is a retry schedule rather than a single attempt: retry after a short gap, then a longer one, with a customer notification alongside so they can fix an expired card. Stop after a defined number of attempts, and know what happens next — is the subscription paused, cancelled, or does the order ship anyway on trust?

That last decision needs making explicitly, because the default in most setups is that nothing happens at all. The renewal fails, nobody is told, and the customer discovers it when their box does not arrive.

For the books, a failed renewal is not a sale. It should not create revenue, and if your system generated an invoice on schedule before attempting the charge, that invoice now needs handling — see failed payments and the orders they leave behind.

The revenue question a one-off sale never raises

For physical goods on a recurring plan, the answer is usually simpler than people fear.

If you ship a box each month and charge for that month, each charge is a sale. Revenue on despatch, cost of goods against it, no complexity. This covers the majority of Malaysian subscription commerce.

If you take payment upfront for several months, you have collected money for goods not yet delivered. That is a liability until you ship, not revenue on the day the money arrived. Recognising it all upfront overstates revenue in one month and understates it in the following ones, and it also overstates margin because the cost of goods lands later.

The distinction is delivery, not payment. Whichever applies to you, apply it consistently, and be able to say at any month end how much of your cash relates to goods you still owe people.

What the gateway data has to give you

Recurring charges create a reconciliation requirement that a normal checkout does not.

The link between a charge and its subscription. Not just an order reference but which plan and which billing period it belongs to. Without it, a customer query about a duplicate charge is unanswerable.

Retry attempts identified as retries. Three attempts on one renewal is one sale, not three, and the failed two must not appear as anything else.

A clear record of the final outcome per billing period. Charged, failed and abandoned, or charged after retries. A period with an ambiguous outcome is a period somebody has to investigate by hand.

Most gateways provide this. It is worth verifying against a real settlement file before you launch rather than after — see gateway API or settlement file.

Changes mid-cycle, and the mess they make

Subscriptions get modified, and every modification is an accounting event.

Upgrades and downgrades part-way through a paid period create a pro-rated amount. Whether you charge the difference immediately, credit it, or apply it at the next renewal is a policy decision, and all three are defensible. What is not defensible is having no policy, which produces inconsistent handling and customer disputes.

Pauses are common in Malaysian subscription commerce, particularly around festive periods. A paused plan is not a cancelled plan, and it needs to be distinguishable in your reporting or your active subscriber count is wrong.

Cancellations mid-period raise the refund question. If you have collected for a period you will not now fulfil, the unfulfilled portion is money you owe — and refunding it has the same fee consequences as any other refund, which may not come back to you. See what happens to the fee when you refund.

Write the policy for all three down before you launch. Every one of them will happen in the first month.

Common questions

Can recurring payments be taken on any payment method?

Not reliably. Cards can generally be tokenised so a stored reference is charged again later, while bank transfer through FPX is a one-time authorisation by design and needs a separate mandate arrangement rather than a stored token. If most of your customers pay by bank transfer, that constrains what you can realistically offer on a recurring basis.

What happens to subscriptions if you change payment gateway?

The stored tokens do not transfer, because they belong to the provider holding the card details. Every subscriber has to re-enter their payment details with the new provider, and some proportion will not, so the credential question should be settled before a gateway migration is planned rather than discovered during one.

Is money collected upfront for several months revenue immediately?

No, not for the portion covering goods not yet delivered. Payment taken in advance for future shipments is a liability until you ship, and recognising it all in the month the money arrived overstates that month's revenue and margin while understating the months that follow, because the cost of goods lands later.

How should failed renewals be handled?

With a defined retry schedule rather than a single attempt, paired with a customer notification so an expired card can be fixed, and an explicit rule for what happens once retries are exhausted. A failed renewal creates no revenue, and if an invoice was raised on schedule before the charge was attempted, that invoice needs clearing rather than being left outstanding.

Related: managing recurring billing · failed payments and the orders they leave behind · card payments in Malaysia and what they cost