OTC Payment Channels in the Philippines: 7-Eleven, Cebuana, and Bank Deposit
When I first set up collection for our business in the Philippines, I did what most foreign merchants do: I looked at GCash, Maya, and QRPH, assumed that covered the market, and moved on. It took a few months of looking at failed checkout sessions and support tickets from customers asking "paano ko babayaran ito sa 7-Eleven?" (how do I pay this at 7-Eleven) before I understood I was missing an entire payment category. A meaningful share of Philippine customers simply do not have a funded e-wallet or a bank card tied to their name, and for them, over-the-counter (OTC) payment is not a backup option — it is the only option that works.
This article is written from that same position: a China-based merchant or technical lead who has already read the GCash and QRPH material and now needs to understand the cash side of the market. OTC payment channels — 7-Eleven, Cebuana Lhuillier, and bank over-the-counter deposit being the three most common — are everyday infrastructure for a large part of the population. Ignoring them means quietly turning away orders you never even see in your analytics, because the customer never reached your checkout page once they realized there was no cash option.
What Over-the-Counter (OTC) Payment Actually Means in the Philippines
OTC payment is a collection method where the customer does not move money electronically at all. The merchant's payment system generates a reference number (sometimes a barcode, sometimes a short alphanumeric code) tied to a specific order and amount. The customer takes that reference to a physical counter — a 7-Eleven cashier, a Cebuana Lhuillier pawnshop branch, or a bank teller — hands over cash, and the staff keys in or scans the reference to post the payment into that network's own collection system. The money has left the customer's hand, but it has not yet reached the merchant: it sits with the collection network until that network settles with the aggregator or the merchant's bank account, usually in a batch.
This is fundamentally different from an e-wallet or QRPH transaction, where the customer authorizes a transfer from an account they already control. With OTC, there is no account on the customer's side — just cash and a reference number. That single difference explains almost everything else about how OTC behaves differently on settlement, reconciliation, and risk.
Why a Meaningful Share of Filipino Customers Still Pay in Cash
It is easy to assume that because GCash and Maya have grown quickly, cash-based collection is a shrinking, low-priority channel. I made that assumption myself and it cost us real orders. The reality is more layered: many customers in provincial areas, older customers, OFW family members receiving remittances on someone else's behalf, and people who simply prefer not to keep money sitting in an app still rely on cash by default. A wallet account also requires an ID that passes verification, a smartphone with stable data, and comfort with digital self-service — none of which can be assumed uniformly across the country.
7-Eleven's outlet density reaches neighborhoods where the nearest bank branch might be a jeepney ride away, and Cebuana Lhuillier's pawnshop network reaches further still into smaller towns. For these customers, handing cash to a person they can see at a familiar storefront is simply a more trusted transaction than typing numbers into an app. If your checkout page only offers e-wallets and cards, you are not failing to convert these customers — you never see them in the funnel at all.
Any provider collecting funds on behalf of merchants in the Philippines should be operating under a proper BSP license — typically an Operator of Payment Systems (OPS) registration, or an Electronic Money Issuer (EMI) license if wallet balances are involved. That licensing line matters just as much for OTC collection as it does for e-wallet collection, because the money is still passing through a regulated custody chain before it reaches the merchant.
How the OTC Payment Flow Works, Step by Step
From a merchant's side, the flow generally looks like this:
- The customer selects "pay at 7-Eleven / Cebuana Lhuillier / bank counter" at checkout instead of an e-wallet option.
- The merchant's system (directly, or through an aggregator) calls an API to create an OTC payment request, specifying the order amount and a reference number.
- The customer receives the reference number and/or barcode, by screen, SMS, or email, along with an expiry window.
- The customer travels to a branch of the selected network and pays cash against that reference.
- The outlet's point-of-sale posts the payment into the network's own backend, separate from the merchant's and the aggregator's systems.
- The network reports the paid status back via webhook or a status-check API call the merchant polls.
- Funds settle from the collection network into the aggregator's or merchant's account on that network's own batch schedule — where reconciliation actually happens.
Those last three steps are where OTC diverges sharply from what a team used to e-wallet integration expects, and that divergence deserves a design decision, not an afterthought.
OTC vs E-Wallet vs Bank Transfer: What Changes for a Merchant
It helped our team to lay these three collection methods side by side once, rather than relearning the differences every time a new payment issue came up.
| Dimension | OTC (7-Eleven / Cebuana Lhuillier / Bank Counter) | E-Wallet (GCash / Maya) | Bank Transfer (InstaPay / PESONet) |
|---|---|---|---|
| What the customer needs | Cash only, no account required | A funded, verified wallet account | A bank account with online or mobile banking |
| Confirmation behavior | Posted after the customer physically pays at a counter; status updates after the outlet reports it | Confirms shortly after the customer authorizes the transfer in-app | Depends on rail: InstaPay settles quickly between participants, PESONet runs on batch cycles |
| Typical customer profile | Unbanked or underbanked, cash-preferring, provincial reach | Smartphone users with a verified digital identity | Customers who already maintain a bank relationship |
| Reconciliation method | Reference-number matching against a reported paid file, often with timing gaps | Direct transaction ID matching via API callback | Matching against bank statement lines or transfer references |
| Common failure point | Expired reference, underpayment/overpayment at the counter, delayed outlet reporting | Insufficient balance, failed KYC, session timeout | Wrong account details, cut-off time misses on batch rails |
The practical lesson for a merchant building a checkout page is that OTC cannot be treated as "just another payment method" in the same code path as a wallet callback. It needs its own state machine: pending, awaiting counter payment, reported paid, and expired, each with its own customer messaging.
Settlement and Reconciliation: The Part Everyone Underestimates
This is where most of our early OTC headaches actually lived, and it had nothing to do with the customer-facing side. With an e-wallet transaction, the merchant's system typically receives a near-real-time callback and can mark an order as paid almost immediately. With OTC, the sequence is longer: the outlet posts the payment into its own system, that system reports a batch of paid references to the aggregator, and only then does the merchant's order status update.
In practice that means a customer who paid at a 7-Eleven counter at midday might not show up as "paid" in our dashboard until later that day, or in some cases the following business day, depending on how that outlet's own batch upload is scheduled. We trained our support team to expect this gap rather than treating every unconfirmed OTC payment as a failed transaction, and we built reconciliation around reference-number matching instead of assuming a same-session callback the way our GCash integration worked.
Because OTC settlement passes through a separate custody chain — outlet, network, aggregator, merchant — we treat BSP OPS/EMI licensing of our aggregator as a baseline requirement, not a nice-to-have. If a provider cannot show how funds are held and reported between the counter payment and the merchant payout, the reconciliation gap becomes a trust gap.
If you are evaluating what a BSP OPS license actually covers, it is worth reading before you sign with any aggregator that touches cash collection, precisely because the holding period between "customer paid cash" and "merchant received funds" is longer and less visible than it is for e-wallet rails.
Comparing OTC Networks: 7-Eleven, Cebuana Lhuillier, and Bank Over-the-Counter
Not all OTC channels behave the same way, and which ones to offer depends on your customer base.
| Network | Outlet type | Typical customer reach | Reporting behavior | Best suited for |
|---|---|---|---|---|
| 7-Eleven | Convenience store, extended operating hours | Urban and suburban, younger and working-age customers, dense footprint in Metro Manila and major cities | Point-of-sale posts the payment, batch reporting to the aggregator follows | E-commerce, gaming top-ups, subscription renewals for customers without a card |
| Cebuana Lhuillier | Pawnshop and remittance branch network | Provincial and rural reach beyond where convenience stores cluster, customers already used to cash-based financial services | Branch staff posts manually, reporting cadence can lag outlet volume | Remittance-adjacent payments, customers outside major cities, OFW family transactions |
| Bank Over-the-Counter | Bank branch teller deposit against a reference or account number | Customers who already bank but prefer not to use online banking, or who are depositing on behalf of someone else | Teller-entered deposit slip, bank's own clearing schedule applies | Higher-value payments, B2B-adjacent collections, customers uneasy with digital-only confirmation |
In our experience, 7-Eleven tends to carry the highest transaction count thanks to outlet density, while Cebuana Lhuillier and bank OTC pick up customers that 7-Eleven's urban footprint does not reach. None of the three should be treated as interchangeable under a single "OTC" checkbox — reporting cadence and typical ticket size differ enough that your support and reconciliation playbook needs to account for each.
Integrating OTC Payment: Direct Connection vs Aggregator
Here is the part that surprised me most when I first scoped this. With GCash or Maya, direct integration is realistic for a mid-sized merchant — one counterparty, one API, one commercial agreement. OTC is different because 7-Eleven, Cebuana Lhuillier, and each participating bank are separate operators with their own onboarding requirements, technical specifications, and commercial terms. Building and maintaining direct connections to each individually only makes sense for a handful of very large merchants with dedicated integration teams and enough volume to justify the overhead.
For almost everyone else, going through an aggregator that already holds commercial and technical connections to multiple OTC networks is the practical choice. The aggregator exposes a single API; the merchant generates one reference number and lets the aggregator route it to whichever network the customer selected. This is also where choosing an aggregator API correctly matters, since the aggregator's own reconciliation and callback design decides how much of the reporting-lag problem above reaches your team as noise versus being absorbed upstream.
Below is a simplified version of how we generate an OTC reference and poll for its paid status.
curl -X POST https://api.smartpay-gateway.com/v1/otc/create \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{
"merchant_id": "MCH10234",
"order_no": "ORDER-20261003-0098",
"channel": "7ELEVEN",
"amount": "850.00",
"expire_minutes": "1440",
"customer_name": "Juan Dela Cruz",
"notify_url": "https://yourshop.com/callback/otc"
}'
A successful call returns a reference number and a barcode asset the checkout page can render for the customer:
{
"status": "success",
"reference_no": "9123456789012",
"channel": "7ELEVEN",
"barcode_url": "https://cdn.smartpay-gateway.com/barcode/9123456789012.png",
"order_no": "ORDER-20261003-0098",
"expire_at": "2026-10-04T23:59:00+08:00"
}
We also poll a status endpoint for any OTC reference still marked pending after a few hours, rather than relying solely on the webhook callback:
curl -X GET "https://api.smartpay-gateway.com/v1/otc/status?reference_no=9123456789012" \
-H "Authorization: Bearer YOUR_API_KEY"
{
"reference_no": "9123456789012",
"order_no": "ORDER-20261003-0098",
"status": "PAID",
"paid_channel": "7ELEVEN",
"amount_paid": "850.00",
"paid_at": "2026-10-03T16:42:11+08:00"
}
Treat "pending" as a normal, expected state for OTC rather than a sign of a broken integration. The order should not time out or cancel on the same short clock you might use for an e-wallet session; it needs its own, longer expiry window that matches how long a customer realistically has to get to a physical outlet.
Frequently Asked Questions
Is OTC payment still relevant now that GCash and Maya are growing fast?
Yes. E-wallet growth has mostly converted customers who were already close to having a bank or wallet relationship. The customers who still rely on OTC tend to be the ones furthest from that conversion, and dropping OTC usually means losing orders you never see reflected in your checkout analytics.
How long does an OTC payment take to confirm?
There is no fixed answer, and any provider promising a fixed, guaranteed window should be treated with some skepticism. Confirmation depends on when the customer visits the outlet relative to when the reference was generated, and how frequently that outlet batches its reporting back to the aggregator. Design for a same-day to next-business-day confirmation window rather than near-real-time status like an e-wallet callback.
What happens if the reference number expires before the customer pays?
The reference becomes invalid and the outlet will reject it at the counter. The merchant typically needs to generate a new reference tied to the same order, which is why checkout messaging should state the expiry window clearly and make it easy to regenerate a reference rather than leaving the customer stuck with a dead barcode.
Can one checkout flow support OTC alongside e-wallets and QRPH?
Yes, and it generally should. Most merchants present OTC as one option among several, letting the customer pick based on what they have available. The complexity sits on the backend, where OTC needs its own status-tracking logic distinct from the near-real-time path used for wallet and QR-based rails.
Do I need to integrate separately with 7-Eleven and Cebuana Lhuillier?
Not if you go through an aggregator that already has commercial agreements with both. Direct integration with each network individually is realistic only for merchants with very high volume and dedicated technical resources; for most merchants, routing OTC reference creation through one aggregator API is faster to launch and easier to maintain.
Is bank over-the-counter deposit handled the same way as retail OTC?
Conceptually yes — cash against a reference at a counter, confirmed after the institution reports it. In practice, bank OTC often involves a teller-entered deposit slip rather than a barcode scan, and the clearing schedule follows that bank's own internal process, which can behave differently from a convenience store's reporting cadence.
Should a new merchant launch with OTC or wait until later?
If your customer base includes any meaningful share of provincial, older, or cash-preferring customers, include OTC from the first launch rather than treating it as a phase-two addition. Retrofitting a longer-expiry, batch-confirmed payment state into a flow built only around near-real-time callbacks is more work than designing for both from the start.
OTC is not a legacy channel waiting to be phased out — it is structural infrastructure for reaching customers who are otherwise invisible to a digital-only checkout. If you are weighing which combination of local payment methods merchants should offer, or want a developer's guide to collection and disbursement covering both cash and digital rails, treat OTC as a first-class part of that planning.
If you are scoping an OTC integration for your own business and want a second opinion on aggregator selection, reconciliation design, or licensing checks, reach out directly: @LouisSMARTPAY or [email protected].