Stripe's Southeast Asia Payment Methods Fix the Checkout. They Don't Fix the Renewal.

On August 25, Stripe marked ten years in Singapore by turning on six new payment methods for cross-border sellers in one shot: GCash, Touch 'n Go, PromptPay, TrueMoney, MoMo, and Samsung Pay. The framing in the coverage was straightforward — these are the payment rails that hundreds of millions of Southeast Asian consumers actually use, and a checkout that only took Visa and Mastercard was invisible to most of them. That part is true and worth taking seriously. What got far less attention is that "accept this payment method at checkout" and "bill this payment method again next month" are two different product capabilities at Stripe, and this announcement only shipped the first one.

If your subscription business sells into the Philippines, Thailand, Vietnam, or Malaysia and you've only ever taken cards, that 85% figure is your problem, not a rounding error. But the fix that solves your trial-conversion rate on day one and the fix that solves your renewal rate on day 30 aren't the same fix, and Stripe hasn't shipped the second one yet for most of this batch.

What actually shipped on August 25

Mechanically, this was a Payment Element expansion. Stripe's Payment Element already handles showing customers only the payment methods relevant to their location and context — integrate it once, and it surfaces GCash to a Filipino customer or PromptPay to a Thai one without you writing per-method logic. What changed on the 25th is which methods are in that pool for cross-border sellers: GCash in the Philippines, Touch 'n Go in Malaysia, PromptPay and TrueMoney in Thailand, MoMo in Vietnam, and Samsung Pay in South Korea (the one market in the batch that isn't ASEAN). ShopeePay and Sea Group's SPayLater are slated for Q4 2026.

Every one of those six is built around the same basic transaction shape: the customer is redirected to their wallet app or shown a QR code, they authenticate in that app with a PIN, fingerprint, or one-time password, and the authorization comes back over a webhook. That's an excellent flow for a checkout page. It's a fundamentally different architecture from a card, where the card network issues Stripe a token it can store and charge again later without the customer doing anything.

Compiled from Stripe Support documentation on PromptPay, public reporting on Stripe's August 25, 2026 Southeast Asia expansion, and Stripe's Billing supported-payment-methods documentation.

PromptPay is the cleanest proof point here precisely because it's in this exact batch. Stripe's own support article states it without hedging: PromptPay is for non-recurring payments only, it won't show up on a subscription's registration page, it doesn't support delayed capture, and it's unavailable for any plan with a free or paid trial attached. That's not a limitation Stripe is quietly working around — it's documented, current behavior for a method Stripe just spent a press cycle promoting.

Why card penetration is this low in the first place

The other half of why this announcement matters is that "just ask for a card instead" isn't a real fallback in these markets. Card issuance in Southeast Asia never scaled the way it did in North America and Europe — mobile wallets and bank-linked QR schemes became the default way to pay digitally before card infrastructure caught up, and for a large share of the population, it never will. Visa-cited penetration data puts the picture in stark relief:

In the Philippines, requiring a card at signup filters out 97 subscribers in 100 before they ever see your product. That's the honest case for turning these methods on — it's not a nice-to-have conversion optimization, it's the difference between reaching the market and not reaching it. We've made a version of this point before about currency mismatch quietly failing international subscribers: a checkout that technically works everywhere still fails everywhere it doesn't match how people in that market actually pay.

The renewal gap this creates

Here's the mechanism that matters for your churn numbers. A SaaS subscription's second charge is fundamentally different from its first. The first charge happens with the customer present, actively completing a purchase flow, willing to scan a QR code or approve an OTP. The second charge — the renewal — is supposed to happen automatically, thirty days later, with no customer involved at all. That's the entire premise of recurring billing: you store a credential once and reuse it without asking again.

Cards support that because the token Stripe stores is designed for exactly this — an off-session charge the customer never sees coming. PromptPay, and most of this batch, don't have an equivalent today. There's no token to store and rebill, because the method was built around a customer being present and authenticating a specific transaction, not a merchant reusing a stored credential in the background. If you let a Thai subscriber pay their first invoice with PromptPay because it converted where a card wouldn't, you now have an active subscriber with no payment method capable of paying invoice number two.

This is a different failure shape from the ones we've covered in Apple Pay and Google Pay's device-bound token declines or SEPA Direct Debit's delayed reversals. Those are cases where a recurring payment method exists and then breaks. This is a case where the payment method was never wired into recurring billing in the first place — invoice two doesn't fail with a decline code your dunning stack can catch and retry. It just has nothing to charge.

What to actually do about it

The fix isn't to avoid these payment methods — the conversion math is too lopsided for that, especially in the Philippines and Vietnam. The fix is treating the first charge and the ongoing subscription as two separate problems:

• Check the specific method against Billing's supported list before you assume it renews. Don't extrapolate from "Stripe added it to Payment Element" to "Stripe added it to Billing" — the August 25 launch demonstrates those are different product surfaces with different timelines, and Stripe has made exactly this kind of recurring-specific addition before, calling out Twint and Scalapay by name when it added them to recurring billing in May 2026 rather than bundling it into a checkout-coverage release.
• Capture a backup payment method at signup where you can. A card requested as a secondary method, even from a small share of your GCash or PromptPay signups, gives you something to fall back on at renewal instead of a silent non-payment.
• Route non-recurring-capable methods into a manual renewal flow, not Smart Retries. Smart Retries is built for a charge that failed and might succeed on a second attempt against the same credential. A missing recurring capability isn't a retryable failure — it needs a payment link sent ahead of the renewal date, not a scheduled retry against nothing.
• Segment your involuntary churn reporting by payment method, not just by country. Two subscribers in Bangkok, one who paid by card and one who paid by PromptPay, have completely different renewal risk profiles even though your dashboard probably groups them as "Thailand."

None of this shows up as a cancellation in the ordinary sense — nobody read a save offer or weighed staying against leaving, the way we cover in why customers actually cancel. It shows up as an account that goes quiet a month after a real, willing signup, for a reason your support team will spend a week ruling out card fraud and expired-card theories before finding. That's worth building into how you think about the involuntary side of your involuntary churn tracking, especially if Southeast Asia is a growth market for you rather than a rounding error. If you want to see what a payment-method-driven renewal gap is doing to your numbers before it shows up as a trend, our churn calculator will turn a specific segment's failure rate into an MRR figure in under a minute. CancelFlow doesn't fix a missing payment credential either — but it does mean that when one of these subscribers does eventually reach a cancel screen, whatever reason they give gets captured and routed to an actual save attempt, instead of being one more silent account you find out about from a support ticket.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.