What Is a Payment Link? A Philippines Merchant's Guide
I split my time between a small tech team in China and a growing list of merchant clients here in the Philippines — mostly social commerce sellers, a few freelancers, and a handful of small shops that never got around to building a website. The question I get asked most often isn't "how do I build a checkout page." It's "how do I just send my customer something they can tap and pay with, right now, in our chat thread." That something is a payment link, and it's worth a proper explanation because almost none of the sellers I talk to actually know how it works under the hood, or when it stops being the right tool.
What a Payment Link Actually Is
Strip away the marketing language and a payment link is just a URL. You generate it — from a merchant dashboard or through an API call — and it points to a hosted payment page that already knows the amount, a description of what's being sold, and a reference you can match back to an order. You send that URL to a customer however you normally talk to them: Messenger, Viber, SMS, email, a comment reply on a live-selling post. They click it, pick how they want to pay, and the transaction happens on a page you didn't have to design or build.
Before payment links existed for small sellers, the default workaround was a screenshot of a static QR code posted in a group chat, followed by the seller manually scrolling through their wallet app to confirm a transfer actually landed. That works until order volume climbs past a dozen a day, at which point matching screenshots to orders becomes its own part-time job. A payment link doesn't eliminate that reconciliation step entirely, but it gives each transaction a reference and a status, which is the first real upgrade most solo sellers experience.
How a Payment Link Gets Generated
For a non-technical seller, the flow usually looks like this: log into a merchant dashboard, click "create payment link," type in a description and an amount, optionally set an expiry window, and generate. What comes back is a shareable URL — sometimes with a shortened version and a QR code rendered alongside it, for sellers who still want something scannable in person.
That link can then be dropped anywhere text or a tappable URL works: a direct message after a live-selling session, a follow-up SMS after a phone order, an email attached to a freelance invoice, or even pasted into a comment reply under a Facebook Marketplace listing. The customer doesn't need to install anything or create an account — they just need a browser.
For sellers with slightly more order volume, this same action can be triggered programmatically instead of clicked by hand, which I'll walk through later in this piece. But the manual dashboard flow is genuinely enough for a large share of the merchants I work with, and it's worth not over-engineering this if a dashboard click solves the problem.
What a Customer Sees When They Click It
The page a customer lands on shows the amount and description you set, plus a list of ways to pay — typically GCash, Maya, and a card option, sometimes with a bank transfer path included as well. This is the part that actually makes payment links useful rather than just convenient: one link can present multiple channels, so the customer picks whatever they already have funded, instead of you asking in advance "do you have GCash or Maya?" and generating a separate QR for each possible answer.
Once the customer completes payment on whichever channel they chose, the page updates to a confirmation state, and the status change is reflected back on the merchant side — either in the dashboard or pushed to your system if you've connected a callback. The customer doesn't see your backend, your dashboard, or anything about how the money actually gets routed after that point. From their perspective, it behaves like a short, single-purpose checkout page that exists for exactly one transaction.
Where Payment Links Fit in Practice
The merchants who get the most out of payment links tend to share a pattern: they're selling through conversation rather than through a storefront. A live-selling host taking orders in a comment section, a reseller running a small catalog through group chats, a freelancer billing a client for a one-off project, a tutor collecting a session fee — none of these need a cart, a product catalog page, or a checkout flow. They need to turn "please pay me this specific amount for this specific thing" into something a customer can act on without any back-and-forth.
It's also a reasonable stopgap for sellers who do eventually want a proper storefront but haven't built one yet. I've set up payment links for clients who were running their shop entirely through social commerce before touching an independent site, using the link as their only collection mechanism until order volume justified something more structured. That sequencing — link first, storefront later — is honestly how most small sellers should approach this, rather than trying to build checkout infrastructure before they've proven the product sells at all.
Where it gets more interesting is recurring or semi-recurring billing. A payment link itself doesn't automatically rebill a customer, but plenty of service providers I work with just generate a fresh link every billing cycle and send it manually or through a scheduled message. It's not elegant, but for a client base under a certain size it's cheaper than building subscription logic.
Payment Link vs. Full Checkout Integration vs. Invoice
These three get confused constantly because they can all end with a customer successfully paying a merchant, but they solve different problems and belong at different stages of a business.
| Dimension | Payment Link | Full Checkout Integration | Traditional Invoice |
|---|---|---|---|
| Setup effort | Minutes, no developer needed | Requires API integration and testing | Minutes, but no built-in payment step |
| Where it lives | Shared via chat, SMS, email, social | Embedded in your own website or app | PDF or document, sent separately from payment |
| Channel coverage | GCash, Maya, cards on one link | Fully configurable, same channel set as the gateway supports | None — payment handled outside the document |
| Best for | Social sellers, freelancers, one-off orders | Stores with real catalogs, repeat high-volume orders | B2B billing, services with payment terms |
| Automation / order matching | Manual to semi-automated, per link | Fully automated via webhooks and order IDs | Manual reconciliation against bank or wallet records |
| Scales well past daily order volume in the hundreds? | Gets labor-intensive | Built for this | Not designed for transactional volume |
The Technical Side: Generating a Link Through the API
Once a seller's order volume stops fitting comfortably into manual dashboard clicks, the next step isn't necessarily a full checkout rebuild — it's often just moving the exact same "create a payment link" action behind an API call, triggered automatically by whatever system is taking the order. A chat bot handling live-selling orders, a lightweight order form, or a backend job can call this instead of a human clicking a button:
curl -X POST https://api.smartpay-gateway.ph/v1/payment-links \
-H "Authorization: Bearer sk_live_xxxxxxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{
"reference": "ORDER-10432",
"description": "Live-selling order #10432 - 2 items",
"amount": "1250.00",
"channels": ["gcash", "maya", "card"],
"expires_in_minutes": 1440,
"callback_url": "https://yourshop.example.com/webhooks/payment-link"
}'
# Response
{
"id": "plink_8f3a2b1c",
"status": "pending",
"url": "https://pay.smartpay-gateway.ph/l/8f3a2b1c",
"reference": "ORDER-10432",
"created_at": "2026-10-04T06:12:00Z",
"expires_at": "2026-10-05T06:12:00Z"
}The response hands back a hosted URL you forward to the customer, plus a reference you can match against your own order record. When the customer pays, the callback_url receives a status update, which is what lets even a fairly manual operation avoid babysitting the dashboard. This is also the point where it's worth comparing options across an aggregated payment API that covers GCash, QRPH, and Maya under one integration rather than stitching channels together one at a time.
Where Payment Links Stop Being Enough
I try to be upfront with clients about this rather than let them hit the ceiling on their own. A payment link is built around a single transaction with a single reference — it isn't a cart, it doesn't hold multiple line items with independent inventory logic, and it doesn't natively handle partial payments, installments, or automatic recurring billing. Every one of those needs to be bolted on manually or avoided entirely if you're only using links.
The bigger issue shows up at volume. Generating links one at a time, even through an API, still means your system is responsible for tracking which links were sent, which expired unpaid, and which need a reminder follow-up. For a seller doing a handful of orders a day that's trivial. For a shop doing hundreds, it becomes a real operational load, and the better move at that point is a proper checkout flow embedded directly into a website or app, with order state, cart logic, and payment status all managed in one automated pipeline. If that's the direction a merchant is heading, it's worth working from a full API integration guide rather than continuing to scale a link-based workaround.
There's also a branding limitation worth naming honestly: the hosted payment page behind a link looks the same for every merchant using that provider. If checkout experience and brand consistency matter to a business — say, a growing independent store trying to look established — that generic page becomes a visible seam that a fully embedded checkout doesn't have.
Staying Compliant: Who Is Actually Behind the Link
It's easy to treat a payment link as a neutral piece of software, but money is moving through a licensed financial entity on the other end of that URL, and that matters more than most sellers realize until something goes wrong with a payout.
Any payment link worth using should be issued by a provider operating under a BSP-recognized OPS or EMI license — the same licensing categories that govern how customer funds are held, settled, and ultimately paid out to the merchant. A link that looks identical on the surface can sit on top of a completely different, and sometimes unlicensed, backend.
This isn't a technicality. If a provider isn't properly licensed, there's no regulatory backstop for how merchant funds are custodied between the moment a customer pays and the moment that money actually settles into the seller's account. I've walked clients through how to evaluate whether a payment gateway is actually operating on a licensed BSP OPS/EMI entity versus an unlicensed reseller before they commit to using it for live transactions, and it's a five-minute check that's worth doing before the first link ever gets sent, not after a payout goes missing.
BSP OPS and EMI are not interchangeable labels for the same thing — they describe distinct regulatory categories, and understanding which one actually applies to your provider is part of basic due diligence before you put your customers' money through their links.
For sellers who want the fuller regulatory picture rather than just a yes/no check, it's worth reading through what a BSP OPS license actually covers and which entities are required to hold one before assuming every provider offering payment links is equally compliant.
Frequently Asked Questions
Do I need a website or app to use a payment link?
No. That's the entire point of the product. A payment link is self-contained — the hosted page does the work a checkout page would normally do, so you can send it through chat, SMS, or email without owning any web infrastructure at all.
Which payment channels can a single link support?
Typically GCash, Maya, and card payments are presented together on the same link, with the customer choosing at the point of payment. Some providers also fold in bank transfer options. The exact mix depends on which channels your provider supports, so it's worth confirming before you start relying on it for a specific customer base.
Does a payment link expire?
Most providers let you set an expiry window when the link is created — anywhere from a short same-day window to several days out, depending on the use case. An expired, unpaid link typically just stops accepting payment and needs a fresh link generated if the customer still wants to pay.
Can the same link be reused for different customers?
Generally no, and you don't want it to be. Each link is tied to a specific reference and amount, which is what lets you match a payment back to an order. Reusing one link across multiple customers breaks that matching and makes reconciliation far harder than it needs to be.
How do I know when a customer has actually paid?
The link's status updates on the dashboard once payment clears, and if you've connected a callback, your own system gets notified directly rather than requiring you to check manually. For low-volume sellers, checking the dashboard between orders is usually fine. For anyone sending more than a few links a day, setting up the callback is worth the extra setup time.
Is it safe for my customer to enter their payment details on a payment link page?
The hosted page is provided and secured by the licensed payment provider, not by the merchant, so the customer isn't handing sensitive payment details to your own system at any point. That separation is actually one of the quieter advantages of using a link instead of asking customers to transfer funds directly and trust you to confirm receipt.
When should I move from payment links to a full checkout integration?
Once order volume reaches the point where manually tracking sent, paid, and expired links starts eating real time, or once you need cart logic, multiple line items, or automated inventory updates tied to payment, it's time to look at embedding a checkout flow directly instead of continuing to generate links one at a time.
If you're trying to figure out which side of that line your business is actually on — still fine with links, or ready for a real integration — reach out and I'm happy to walk through it with you directly: @LouisSMARTPAY or [email protected].