Buy Now, Pay Later (BNPL) in the Philippines: What Merchants Need to Know

I run the payments side of an e-commerce operation that sells into the Philippines from a China-based team. Most of what I write about internally is plumbing — webhook retries, settlement timing, reconciliation reports. BNPL is different. It's a merchandising decision that happens to come with plumbing attached. It's come up often enough in product review cycles that I finally sat down and mapped out how it works, what it costs, and where it fits next to the e-wallet and card rails we already run. This is that write-up.

Why BNPL Keeps Coming Up at Checkout Reviews

Every quarter we pull cart-abandonment data by price band. The pattern is consistent: abandonment climbs sharply once a cart crosses into higher-ticket territory — appliances, furniture, electronics, anything where the buyer hesitates because paying the full amount in one shot feels like a bigger commitment than it actually is. Our customer support team hears versions of the same question: "can I pay this in parts?" For a while our answer was no, or "only if you have a credit card that supports installments," which excludes a large share of Philippine shoppers who don't carry one.

BNPL showed up in our checkout discussions as a way to answer that question without us becoming a lender. That distinction matters more than it sounds — it's the entire reason BNPL exists as a separate product category instead of just being "store credit."

How BNPL Actually Works Behind the Checkout Button

From the customer's side, BNPL looks simple: pick "pay in installments" at checkout, pass a quick approval check, and walk away having paid nothing or a small first installment. From the merchant's side, the mechanics are closer to a factoring arrangement than to a payment method in the narrow sense.

Here's the flow as I understand it after going through a few partner conversations:

1. The customer selects BNPL at checkout instead of an e-wallet, card, or bank transfer.
2. The BNPL provider runs its own approval check on the customer — this is the provider's underwriting, not ours, and we don't see the criteria it uses.
3. If approved, the BNPL provider pays the merchant the order value upfront, minus a fee the provider keeps for taking on the risk.
4. The customer then owes the installments to the BNPL provider, not to us. We are out of that relationship entirely once the order is funded.
5. If the customer misses a payment, falls behind, or defaults, that is the BNPL provider's collection problem. It does not come back to the merchant as a chargeback or a clawback on the order.

That last point is the one I had to double-check before I believed it, because it's the opposite of a merchant-run installment plan. If I let a customer pay in parts directly to me, I'm carrying the receivable and the collection risk myself. With BNPL, I get paid as if the sale is final the moment the provider funds it, and the provider carries the receivable. I'm trading a slice of margin for an exit from collections risk on that order.

Why BNPL Can Lift Average Order Value and Conversion

The economic case for BNPL isn't about making every transaction cheaper — it's about recovering sales that would otherwise not happen at all. A shopper looking at a higher-ticket item who doesn't want to commit the full amount today has three options without BNPL: pay anyway, put it off, or abandon the cart. BNPL gives a fourth option that keeps the sale on our books today.

What I've seen discussed across our product and growth team isn't a claim that BNPL beats e-wallets or cards on cost — it doesn't, and I'll get to that — but that it widens the top of the funnel for a specific slice of inventory: items priced high enough that "pay it all now" is the actual objection, not price itself. For low-ticket, impulse-driven items, BNPL adds friction (an approval step) without solving a real problem, since the customer wasn't hesitating over the full amount anyway.

If you're trying to quantify this before committing engineering time, the honest approach is to segment your own abandonment data by order value first, the same way we did, rather than assume BNPL will move every category. There's a broader set of tactics for practical ways to cut checkout drop-off that are worth working through before concluding BNPL is the missing piece.

Where BNPL Fits in the Checkout Stack — Not a Replacement

This is the point I most want other merchants to internalize before they build anything: BNPL is one tile among several, not a new front door. Nobody opens your store specifically to use BNPL the way they might open it to use GCash. It sits in the payment method list next to e-wallets, cards, and bank transfer, and it should only be offered to shoppers for whom it's actually relevant — meaning the order value and product category make sense for it.

We thought carefully about how Philippine checkout pages are typically laid out before deciding where BNPL belongs in that list. E-wallets stay first because that's where the volume is. BNPL shows up conditionally — only when the cart value clears a merchant-set floor and the product category isn't excluded — rather than appearing as a permanent fixture that gets offered on a small accessory purchase where it makes no sense.

The practical consequence is that BNPL eligibility has to be computed per-order, not configured once and forgotten. Your checkout needs to know the order total, the product mix, and whatever rules the BNPL provider enforces on its end before it decides whether to show the option at all.

Integration Considerations: What Actually Changes in Your Checkout Code

If your checkout already calls a payment-methods endpoint to decide what to render — which most of ours do, since we support multiple e-wallets and cards already — adding BNPL is mostly a matter of treating it as another entry in that list, with its own eligibility flags and its own session flow. Here's a simplified version of what that looks like in practice, stripped down from our actual integration:

// GET /v1/checkout/payment-methods?order_id=ORD-2026-00917
{
  "order_id": "ORD-2026-00917",
  "payment_methods": [
    {
      "type": "ewallet",
      "provider": "gcash",
      "label": "GCash",
      "eligible": true
    },
    {
      "type": "card",
      "provider": "card_network",
      "label": "Credit / Debit Card",
      "eligible": true
    },
    {
      "type": "bnpl",
      "provider": "bnpl_partner_a",
      "label": "Pay in Installments",
      "eligible": true,
      "eligibility_reason": "order_value_within_bnpl_range",
      "merchant_settlement": "upfront_minus_fee",
      "customer_collection": "provider_managed"
    }
  ]
}

// POST /v1/checkout/sessions
// { "order_id": "ORD-2026-00917", "method": "bnpl", "provider": "bnpl_partner_a" }

{
  "session_id": "sess_8f2e1c",
  "status": "pending_provider_approval",
  "redirect_url": "https://bnplpartner.example/approve/sess_8f2e1c",
  "webhook_events": ["bnpl.approved", "bnpl.declined", "bnpl.funded"]
}

Two things stood out to us when we mapped this against our existing integration. First, the approval step is asynchronous and happens on the provider's side — your order sits in a pending state until a webhook tells you whether the customer was approved, which is a different pattern from an e-wallet payment that resolves in a single round trip. Second, the "funded" event is the one that actually matters to your accounting: that's when the provider has committed to paying you, separate from whether the customer has started paying the provider back. Your reconciliation logic needs to treat BNPL settlement as its own category rather than lumping it in with e-wallet or card settlement, since the timing and the payout party are different.

The Real Cost of BNPL: Fees, Risk, and Who Absorbs What

The trade merchants make with BNPL is straightforward once you say it plainly: you give up more margin per transaction than you would on a standard e-wallet or card payment, in exchange for the provider absorbing the credit and collections risk entirely. Fees on BNPL arrangements are typically higher than standard payment method rates — that's structurally necessary, since the provider is underwriting a customer it may never have seen before and will chase repayment over weeks or months. I'd treat any pitch suggesting BNPL costs about the same as a card transaction with suspicion; the economics don't support that.

Here's how I'd lay the three options side by side, since this is the comparison our internal deck ended up needing:

Dimension	BNPL (third-party provider)	Full Upfront Payment (e-wallet / single-shot card)	Installment via Credit Card
Who pays the merchant	BNPL provider, upfront, minus its fee	Payment processor, per standard settlement cycle	Issuing bank, per standard settlement cycle
Who bears collection risk	BNPL provider	Not applicable — payment is final at checkout	Card-issuing bank, not the merchant
Merchant fee level	Typically higher than standard rates	Standard processing rate	Standard processing rate, sometimes a modest installment surcharge
Customer eligibility requirement	Provider-run approval check at checkout	Needs a funded wallet, bank account, or valid card	Needs an existing credit card that supports installments
Addressable share of shoppers	Broader — doesn't require owning a credit card	Broadest — works for any funded account	Narrower — limited to credit card holders
Best suited for	Higher-ticket items where "pay it all now" is the real objection	Most transactions, especially lower-ticket and routine purchases	Shoppers who already prefer card-based installment habits

What this table doesn't fully capture is the opportunity cost of not offering it. If a meaningful share of your abandoned high-ticket carts are abandoned specifically over the full-payment objection, the fee premium on BNPL can still be worth it, because the alternative isn't "the same sale at a lower fee" — it's often no sale at all.

Which Product Categories Actually Suit BNPL

Not every catalog benefits equally. From what I've seen across our own categories and from comparing notes with other merchants, BNPL tends to perform where the item is durable, mid-to-high ticket, and the purchase decision is considered rather than impulsive — electronics, appliances, furniture, and some categories of fashion or beauty bundles sold at higher basket sizes. It tends to add friction without benefit on low-ticket, replenishment-style purchases, subscriptions, or anything bought on impulse, because the approval step slows down a purchase that didn't need financing in the first place.

There's also a practical floor and ceiling to think about. BNPL providers typically won't approve very small orders — the fee they'd earn wouldn't justify the underwriting cost — and they may cap how large an order they're willing to fund without additional verification. That means you can't treat BNPL as a universal toggle; it needs order-value gating the way we described in the checkout section above, not a blanket "on" for the whole store.

Compliance Context: Why the License Behind Your Partner Matters

Payments in the Philippines sit under Bangko Sentral ng Pilipinas oversight, and the licensing picture is more layered than a single checkbox. Our own checkout runs through payment infrastructure that holds both an Operator of Payment Systems designation and an Electronic Money Issuer license.

My own checkout runs on a payment gateway licensed as both a BSP Operator of Payment Systems (OPS) and an Electronic Money Issuer (EMI). That license covers how money moves through e-wallets and cards — it does not automatically extend to how a separate BNPL provider decides to extend credit to a customer. Those are two different regulatory questions, and I don't let a BNPL partner's marketing collateral blur them together.

Before we'd plug a BNPL provider into checkout, we'd want the same basic diligence we apply to any payment partner: what entity is actually funding the order, what oversight it operates under, and how it custodies the money between "provider approves the customer" and "merchant gets paid." If you haven't gone through that exercise for your existing rails yet, it's worth understanding what an EMI license actually covers and separately what a BSP OPS-type license covers, because they answer different questions about who is allowed to do what with customer funds.

When a BNPL partner can't point to a clear registration, a banking relationship, or a licensed financial partner behind its funding, that's a flag — the same way I'd treat a payment gateway that couldn't show its BSP OPS or EMI license on request.

This isn't about assuming every BNPL provider is unlicensed — plenty operate as registered financing or lending companies with their own regulatory track. It's about not skipping the question just because BNPL feels like "just another checkout button." The money moves through a different kind of institution than your e-wallet or card rail, and it's worth knowing which one before putting it in front of customers.

Frequently Asked Questions

Does the merchant carry any credit risk when offering BNPL?

No, not under the standard arrangement. The BNPL provider approves the customer, funds the merchant upfront minus its fee, and then owns the collection relationship with the customer. If the customer defaults, that's the provider's loss, not a chargeback against the merchant.

How is this different from a merchant running its own installment plan?

If you let customers pay you directly in installments, you're the one carrying the receivable and doing the collecting — effectively extending credit yourself. BNPL moves that entire function to a third party that specializes in underwriting and collections, in exchange for a fee that's higher than a standard payment rate.

Does adding BNPL require rebuilding my checkout integration?

Not if your checkout already treats payment methods as a dynamic list rather than hardcoding a fixed set. BNPL adds one more entry to that list, with its own eligibility logic and an asynchronous approval step via webhook rather than a same-request response.

What happens if a customer misses an installment to the BNPL provider?

That's between the customer and the provider. The merchant has already been paid for the order and isn't notified of, or responsible for, the customer's repayment status unless the provider's terms say otherwise.

Can I offer BNPL on only some products instead of store-wide?

Yes, and in most cases you should. BNPL eligibility is typically computed per order based on value and category, not switched on globally. Low-ticket or impulse categories usually don't benefit from the added approval friction.

How does BNPL settlement timing compare to e-wallet or card settlement?

The structure differs, not just the speed. With BNPL, you're paid once the provider funds the order — a single event tied to approval. With e-wallets and cards, you're on your processor's regular settlement cycle. Reconcile them as separate categories rather than assuming the same accounting pattern.

Do BNPL fees come out of my settlement automatically?

Typically yes — the provider nets its fee before paying the merchant, similar in structure to how a processor nets its own fee, though the fee level itself is usually higher given the underwriting risk involved.

Should a small merchant bother with BNPL at all?

Only if there's evidence it solves a real problem — meaningful abandonment on higher-ticket items specifically over the full-payment objection. If your catalog is mostly low-ticket, the added integration and approval friction likely isn't worth it yet.

If you're weighing whether BNPL belongs in your checkout stack, or want a second opinion on how it should sit alongside the e-wallet and card rails you're already running, reach out to @LouisSMARTPAY or [email protected].