Recurring Billing and Subscriptions in the Philippines: Payment Methods, Tokens and Dunning (2026)

I lead engineering for a software company headquartered outside the Philippines that sells monthly and annual plans to Philippine customers. Our first subscription launch there was built on the assumptions we had carried over from card-first markets: store a card, charge it on the renewal date, retry if it fails. Within the first billing cycle we learned that most of our Philippine sign-ups did not want to use a card at all, that the wallet they preferred could not simply be charged in the background the way a card token can, and that a renewal that silently fails looks to the customer like a service that silently stopped working. This article is the setup guide I wish we had read before that launch. It covers which payment methods can realistically be charged on a schedule, how to choose a billing model, what the subscription system itself has to look like, how to handle failed renewals, and what records and consents you need to keep. The narrower question of converting a free trial into the first paid charge is handled in depth in Free Trial to Paid Subscription Billing, so I will only reference it here.

Why Subscriptions Are Harder in the Philippines Than in Card-First Markets

Three things make recurring billing different in this market. The first is payment-method mix. A large share of online consumers here pay with an e-wallet or through a bank transfer rail rather than a credit card. A subscription system designed around card-on-file therefore excludes many of the people who would otherwise sign up, or forces them into a card they rarely use and may not keep funded.

The second is the consent model. A card network token lets you charge the customer while they are absent, under rules the networks have standardised for decades. Wallet and bank-rail payments were designed as customer-initiated pushes: the customer opens the app, approves a specific amount, and the money moves. Some providers can wrap a wallet account into a linked-account arrangement that supports merchant-initiated charges, but that capability depends on the wallet, the provider, and the merchant category, and it does not exist everywhere. You cannot assume it.

The third is customer expectation. In markets where auto-renewal is the norm, a renewal charge rarely surprises anyone. Here, many customers still expect to be asked before money leaves their wallet. A well-designed subscription product in the Philippines therefore treats a renewal as a communication event, not only as a charge, with a reminder before the attempt and a clear receipt after it. Get this wrong and you will see the result as disputes and support tickets rather than as churn metrics.

Which Payment Methods Can Actually Be Charged on a Schedule

Before writing any code, map each payment method your provider offers to one of four recurring-charge patterns. The pattern determines what your system can do automatically and what has to go through the customer each cycle.

Pattern	Payment methods it applies to	How consent is captured	Can you charge while the customer is absent?	Typical failure modes	Best fit
Card tokenization	Credit and debit cards issued locally or abroad	Card entered once at checkout, provider returns a reusable token	Yes, subject to issuer approval on each attempt	Expired card, insufficient funds, issuer declines merchant-initiated transactions, card reissued after fraud	Business customers, annual plans, customers who already pay for other subscriptions by card
Wallet account linking	E-wallets, only where the wallet and your provider expose a linked-account or autopay capability	Customer authorises the link inside the wallet app, with a cap per charge or per period	Yes, within the authorised cap, until the customer revokes the link	Wallet balance too low on the renewal date, link revoked without notice, cap lower than the new plan price after an upgrade	Consumer monthly plans where wallets are the dominant method
Bank standing instruction	Bank accounts, where the bank or your provider supports recurring debit arrangements	Customer sets up the instruction with the bank or through the provider's flow	Yes, on the schedule defined in the instruction	Account closed, instruction cancelled, amount changes not reflected in the instruction	Business customers with fixed monthly amounts
Customer-initiated renewal	Any wallet, bank transfer or over-the-counter channel	Each cycle: you send a payment link or invoice, the customer approves it in their app	No, the customer must act every cycle	Customer forgets, link expires, payment arrives after the grace period	Fallback for every method above; primary path where no linked-account capability exists

The practical consequence is that a Philippine subscription system needs two engines rather than one: an automatic engine for tokenised methods, and a request-and-wait engine for customer-initiated renewals. The second engine uses the same primitives as one-time collection, namely payment links and invoices, but with scheduling, reminders and expiry built around the billing period. Treat the request-and-wait path as a first-class feature, not as an edge case, because it is the only path available to a meaningful part of your customer base.

Billing Models and Proration

Choose the billing model before the architecture, because the model decides what the scheduler has to compute.

Fixed-interval plans (monthly or annual at a known price) are the simplest. The scheduler needs an anchor date per subscription, the plan price, and a rule for months of different lengths. Decide early whether renewals anchor to the signup day or to the first of the month; anchoring to the first simplifies reconciliation and reporting but creates a partial first period that must be prorated or waived.

Usage-based plans charge in arrears for what was consumed. The billing run must close a usage window, rate it, generate an invoice and only then attempt the charge. Usage billing combines badly with wallet caps and with customer-initiated renewals, because the amount is unknown until the period closes and may exceed what the customer authorised. If you must bill on usage for wallet users, cap the invoice at the authorised amount and bill the remainder separately.

Hybrid plans (a base fee plus overage) are the most common for software sold to small businesses. The base fee can run on the automatic engine while overage is invoiced for customer-initiated payment, which keeps the predictable part of revenue automatic and the variable part transparent.

Proration on plan changes deserves its own decision. When a customer upgrades mid-cycle, you can charge the difference immediately for the remaining days, or apply the new price from the next renewal. When they downgrade, you can credit the unused portion to a balance or simply switch at the next renewal. For wallet-linked customers, an immediate prorated charge may exceed the per-charge cap they authorised; the safer rule is to apply upgrades at the next renewal unless the customer explicitly approves an immediate prorated payment through a link. Whatever you choose, write the rule into the terms the customer sees at checkout, because proration disputes are among the hardest to resolve after the fact.

The Subscription Architecture: State Machine, Scheduler, Token Vault and Webhooks

A subscription system has four parts, and the mistakes I have seen almost always come from collapsing two of them into one.

The state machine. Each subscription is in exactly one state: trialing, active, past_due, unpaid, paused, cancelled. Transitions are triggered by events (a renewal succeeded, a charge failed, the customer cancelled, the dunning window expired) and every transition is logged with the event that caused it. Service entitlement reads the state; nothing else does. This separation is what lets you keep a customer's access alive during a grace period without touching the billing logic.

The scheduler. A periodic job selects subscriptions whose next billing date has arrived, creates an invoice for each, and either attempts a charge against the stored token (automatic engine) or issues a payment request and sets an expiry (request-and-wait engine). The scheduler must be safe to run more than once for the same date, which means the invoice creation itself is keyed on subscription plus period, not on the time the job ran.

The token vault. Your systems should never hold raw card numbers or wallet credentials. The provider stores the instrument and gives you a token; you store the token, the method type, a display hint and the consent record. Treat a token as a reference that can be revoked at any time by the customer, the issuer or the wallet, and design every charge attempt to handle a revoked token as a normal outcome rather than as an exception.

Webhook handling. Charge outcomes arrive asynchronously. The handler must record the event before acting on it, acknowledge quickly, and process off the request thread, following the pattern described in Webhook Retry Design. Every charge attempt carries an idempotency key built from the subscription and the billing period, so a retried request can never produce a second charge for the same period; the reasoning is covered in Idempotency Keys: Preventing Duplicate Payments.

Creating a subscription against a stored token looks like this with a typical gateway API. The amount is a placeholder; the important fields are the token, the idempotency key and the consent record.

curl -X POST https://api.example-gateway.com/v1/subscriptions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Idempotency-Key: sub-create-cust_8812-pro_monthly" \
  -d '{
    "customer_id": "cust_8812",
    "payment_token": "tok_3f9a7c",
    "plan": {
      "code": "pro_monthly",
      "interval": "month",
      "currency": "PHP",
      "amount": "100.00"
    },
    "billing_anchor": "signup_day",
    "consent": {
      "method": "checkout_checkbox",
      "captured_at": "ISO_TIMESTAMP",
      "ip": "203.0.113.7",
      "terms_version": "subs-v3"
    },
    "notify_url": "https://billing.example.com/webhooks/gateway"
  }'

On the receiving side, the webhook handler advances the state machine. Note the order: verify the signature, record the event id, acknowledge, then process. A duplicate delivery stops at the second step.

// Express handler: advance subscription state idempotently
app.post('/webhooks/gateway', express.raw({ type: 'application/json' }), async (req, res) => {
  if (!verifySignature(req.body, req.get('X-Signature'))) return res.status(401).end();
  const event = JSON.parse(req.body);

  // 1. Record the event id first; a duplicate delivery stops here
  const inserted = await db.insertEventIfNew(event.id, event);
  if (!inserted) return res.status(200).end();

  // 2. Acknowledge quickly, then process off the request thread
  res.status(200).end();

  const sub = await db.getSubscription(event.data.subscription_id);
  switch (event.type) {
    case 'invoice.paid':
      await db.transitionSubscription(sub.id, {
        from: ['active', 'past_due', 'trialing'],
        to: 'active',
        period_end: event.data.period_end,
        last_invoice: event.data.invoice_id
      });
      await mailer.sendReceipt(sub.customer_id, event.data.invoice_id);
      break;
    case 'invoice.payment_failed':
      await db.transitionSubscription(sub.id, { from: ['active'], to: 'past_due' });
      await dunning.schedule(sub.id, event.data.decline_class); // soft or hard
      break;
    case 'payment_method.revoked':
      await db.transitionSubscription(sub.id, { from: ['active', 'past_due'], to: 'unpaid' });
      await mailer.askForNewPaymentMethod(sub.customer_id);
      break;
    default:
      // Unknown event types are stored and ignored, never rejected
  }
});

Dunning and Retry Policy for Failed Renewals

Dunning is the process that runs between a failed renewal and either a recovered payment or a cancelled subscription. A good policy starts by classifying the failure, because retrying a hard decline wastes attempts and annoys the issuer, while giving up on a soft decline throws away revenue that would have come in a few days later.

Decline class	Examples	Automatic retry?	What to tell the customer	Next step if unresolved
Soft, likely temporary	Insufficient balance, issuer timeout, wallet temporarily unavailable	Yes, a short series of retries spread over about a week	Renewal did not go through; we will try again on a stated date; top up or update your method	Move to unpaid at the end of the grace period
Hard, instrument invalid	Card expired, account closed, token revoked, link removed in the wallet app	No	Your payment method no longer works; add a new one to keep your plan	Move to unpaid once the grace period ends without a new method
Hard, policy	Issuer blocks merchant-initiated charges, amount above the authorised cap	No, unless the amount or method changes	Approve this renewal in your app, or switch to a method that supports automatic renewal	Fall back to a customer-initiated payment link for this period
Fraud or risk flag	Provider risk rules, suspected account takeover	No	Contact support; do not state the risk reason	Manual review before any further attempt

Three design rules make dunning work. First, every retry is a new attempt with the same idempotency scope, so a late success from an earlier attempt and a new attempt can never both settle for the same period. Second, the grace period is a property of the plan, not of the customer: service continues in past_due for a defined number of days, and the customer is told the exact date it will stop. Third, every dunning message includes a one-tap path to pay now through a payment link, even for customers on automatic methods, because the fastest recovery is often a manual payment while the stored method is being fixed.

Send a reminder before the renewal attempt, not only after a failure. For customer-initiated methods the reminder is the renewal: it carries the link, states the amount and the date the current period ends, and is followed by one or two further reminders before expiry. For automatic methods a pre-renewal notice reduces disputes, because a customer who was told the charge was coming rarely reports it as unauthorised.

Cancellation, Pause and Downgrade Flows

Cancellation must be at least as easy as signup. Put it inside the account page, confirm it with one click, and send a confirmation that states the date access ends and that no further charges will be attempted. When a customer cancels, you also have to decide what happens to the stored token: the conservative rule is to stop using it for charges immediately but keep the token reference until the final period closes, in case the customer reactivates, then delete it according to your retention policy.

Pause is worth offering for consumer plans. A paused subscription keeps the customer record and token but skips renewals for a defined number of periods, then resumes automatically with a reminder beforehand. Pause removes a large share of cancellations that are really temporary cash-flow decisions, which matters in a market where wallet balances are topped up around pay dates.

Downgrades apply at the next renewal unless you have a credit mechanism. If the customer is on a wallet link with a per-charge cap, a downgrade needs no change to the link; an upgrade may need the customer to raise the cap in the wallet app before the next renewal, and your system should check the authorised cap against the new price and prompt the customer in advance rather than discovering the mismatch at charge time.

Refund rules for subscriptions should be written down and applied by the system, not decided case by case. A common policy is no refund for a completed period, prorated refund for an annual plan cancelled early, and full refund of a renewal charged within a short window after the customer attempted to cancel. The mechanics of issuing a refund through the original method are covered in the general refund process; the subscription-specific part is that a refund must also move the state machine, so that a refunded renewal does not leave the customer with paid access.

Records and Compliance: Invoices, Consent, Privacy and Licensing

Each billing cycle should produce an invoice before the charge and a receipt after it, both stored with the subscription, the period, the amount, the method used and the provider's transaction reference. Philippine business customers will ask for official receipts and may need your tax registration details on the document; consumer customers mostly need a clear statement of what was charged, for which period, and how to cancel. Build the documents from the invoice record, not from the payment event, so that a failed charge still has an invoice and a reconciled trail.

Consent is the record that protects you when a customer disputes a renewal. Capture, with each subscription, the method of consent (a checkbox, a wallet-link authorisation, a signed instruction), the timestamp, the terms version shown, and the customer's network address or device identifier. Show the recurring nature of the charge, the interval, the price and the cancellation method on the same screen where the customer confirms, not in a separate document.

Personal data collected for billing (names, addresses, contact details, payment hints, usage records) falls under the Philippine Data Privacy Act. Keep only what billing needs, state the purpose in your privacy notice, restrict access inside your organisation, and define a retention period for cancelled accounts. Card data never belongs in your systems; let the provider's vault hold it.

The provider that stores your customers' payment instruments and runs the recurring charges should be a BSP-registered Operator of Payment Systems (OPS) and, where it holds customer funds in wallets or stored value, a BSP-licensed Electronic Money Issuer (EMI). The BSP OPS/EMI status is what makes the token vault, the charge execution and the settlement to your account part of a supervised payment system rather than a private arrangement. Verify the registration before you build on the provider; the verification steps are in BSP Licensing Requirements for Payment Service Providers.

Frequently Asked Questions

Can I charge a Philippine e-wallet automatically every month?

Only where the wallet and your provider support a linked-account or autopay arrangement that the customer has authorised in the wallet app, and only up to the cap the customer set. Where that capability is not available, the renewal has to be customer-initiated through a payment link or invoice each cycle.

Should I require a card for subscriptions to keep things simple?

You can, but you will lose the customers who do not use cards online, which in this market is a large group. The better design is to support automatic renewal where the method allows it and a request-and-wait renewal everywhere else, with the same plans, invoices and state machine behind both.

How many times should I retry a failed renewal?

Retry only soft declines, and only a small number of times spread over the grace period. Hard declines such as an expired card or a revoked link should not be retried at all; they need a new payment method from the customer.

What happens if a customer revokes the wallet link without telling me?

Your next charge attempt fails with a revoked-token outcome, or you receive a revocation event from the provider if it sends one. Treat either as a hard decline: move the subscription to unpaid, keep access through the grace period, and ask the customer for a new method or a manual payment.

Do I need to send a reminder before every automatic renewal?

It is not a legal requirement in every case, but it is the single most effective way to reduce disputes and support tickets in this market. Customers who were told the charge was coming rarely report it as unauthorised.

How should proration work for wallet-linked customers?

Apply upgrades at the next renewal by default, or ask the customer to approve an immediate prorated payment through a link. An immediate automatic charge may exceed the per-charge cap the customer authorised and fail.

Where does the free-trial conversion fit into this?

The trial is simply the first state in the machine: trialing, then active once the first charge succeeds. The specific pattern of authorising the method at signup and charging at trial end, with reminders before conversion, is covered in the dedicated article on trial-to-paid billing.

Where to Go From Here

Recurring billing in the Philippines is less about clever retry logic and more about respecting how customers here actually pay: map each method to the right renewal pattern, run two engines behind one state machine, tell customers before you charge them, and keep the consent and invoice trail that lets you answer any dispute. If you are planning a subscription launch for Philippine customers and want to check which of your target payment methods can be charged automatically through a licensed gateway, reach out on Telegram at @LouisSMARTPAY or by email at [email protected].