Merchant Dashboard Management: What Functional Modules a Good Payment Back Office Needs

Why a usable dashboard matters more than you'd think

When companies evaluate a payment provider, most of the attention goes to which channels it supports, what the fee structure looks like, and whether settlement is D0 or T1. Those things matter, but the tool your team actually opens every single day is the merchant dashboard. Once you're live, finance uses it to reconcile, support uses it to look up transactions, and management uses it to check overall volume — how usable that dashboard is directly decides how much time those routine tasks take, and how many mistakes slip through.

Inside the broader process covered in Philippines payment gateway integration, technical onboarding and go-live review are one-time efforts. The dashboard is the part you live with every day after that. This article isn't about how to integrate — it breaks down the functional modules a decent merchant dashboard should have.

Transaction query: can you filter by the dimensions you actually need

Transaction query is the module opened most often, and it's also the easiest place to spot whether a provider actually thought about day-to-day use. At minimum, filtering should cover:

• Date range (by day, by week, or a custom range)
• Transaction status (successful, failed, pending, refunded)
• Payment channel — GCash, aggregated QRPH, and Maya disbursement shown separately, not lumped together
• Order number or your own merchant reference, so it's easy to match against your own order system

A step further is whether you can drill into a single transaction and see the full detail — the raw status code returned by the channel, the timestamp, the channel's own reference number — rather than just a word like “success.” When a reconciliation mismatch shows up, those details are the first thing you'll need, especially for high-frequency, small-ticket scenarios like GCash transfers and cash-in/cash-out, where a single day can produce dozens or hundreds of transactions that no one can reasonably check one by one by hand.

It's also worth checking whether the data in the dashboard syncs in real time or with a delay. Some dashboards lag slightly behind the actual status on the channel's side, and if finance doesn't know about that lag, it's easy to mistakenly flag a transaction as “missing.”

Refund operations: one-click refund, or an approval workflow

Refunds are where things most often go wrong, for the obvious reason that money is leaving the merchant's account. A reasonable refund module needs to handle at least three things:

1. Partial refunds — being able to refund part of an amount rather than always having to refund in full, which comes up constantly in after-sales disputes.
2. Whether a refund goes back through the original channel or is issued as a separate transfer — the two can arrive on different timelines, and it's worth clarifying this during sandbox integration rather than discovering it after go-live.
3. Whether refunds require approval — once a team grows past a handful of people, can support staff click “refund” directly, or does it need sign-off from finance or an administrator first? That's a real internal risk-control question.

Refund records should also be their own searchable, exportable list rather than something buried inside the general transaction list. Who initiated the refund, when, who approved it, and what stage it's currently at — all of that should be logged. That's useful for reconciliation, and it's also what you'll want on hand if a dispute ever needs to be sorted out.

Reconciliation export: are the format and fields actually usable

Month-end reconciliation is one of the most tedious parts of a finance team's job, and the dashboard's export function is what decides whether it takes half a day or an entire week. A few things worth paying attention to:

• Whether the export comes in a usable format (Excel/CSV) that can be imported straight into your own accounting system, rather than a PDF screenshot.
• Whether the fields are complete — order number, channel reference number, transaction time, settlement date, status, and fee. Missing even one of these means manual patching during reconciliation.
• Whether you can export by settlement batch rather than only transaction by transaction — this matters especially for funds moving through clearing rails like InstaPay and PESONet interbank transfers, where settlement is processed in batches and finance needs to match “this batch corresponds to these transactions.”
• Whether there's an API or webhook push available, so your own system can pull transaction data automatically instead of someone logging in and clicking export every day. This is worth raising during sandbox testing: is payment confirmation delivered by polling or by a pushed webhook, could a duplicate notification for the same payment cause double-counting, and does the integration handle idempotency correctly? Skipping these questions tends to surface as numbers that don't add up once you're reconciling in production.

If your company also handles tax filing, it's worth checking early whether transaction data can be matched against records from BIR tax payment channels, so you're not reassembling everything by hand at filing time.

Staff permissions: who can view, who can refund, who can change settings

Once a team grows, everyone sharing one login and password becomes an internal control risk. A good merchant dashboard should support role-based permissions. A common split looks like this:

Beyond role assignment, an operation log is another piece that's easy to overlook but matters — who changed what setting and when, who initiated a refund, all of it should be traceable. As a team grows and you bring on dedicated finance or support staff, opening a corporate bank account and managing dashboard permissions are really the same kind of problem: anything involving money needs a clear scope of authorization.

If your company entity isn't set up yet, sub-accounts, KYC documentation, and ownership structure are all things worth thinking through during the company setup stage, so you're not scrambling to supply documents later and delaying go-live.

The less convenient side of this

A polished-looking dashboard doesn't automatically mean a provider is the right fit. A few things worth keeping in mind:

• Fee structures, settlement cycles, and the number of channels supported all vary by provider. A “same-day D0 settlement” referenced somewhere isn't necessarily the default setting — it's worth comparing a few providers rather than taking the first one.
• A higher refund or chargeback rate in the early stage of operation is common for new merchants, and it can trigger extra review or a reserve hold — that's standard risk control across the industry, not something specific to one merchant, so don't be surprised if flagged refund records show up in the dashboard.
• Not every company claiming to offer “payment integration” actually holds an OPS or EMI license issued by the central bank. Reselling or subcontracting arrangements are not uncommon, so a polished dashboard interface is no substitute for verifying the license is real.

One licensed provider we're aware of is SmartPay (paysmartph.com), which handles native GCash integration, aggregated QRPH collection, and Maya disbursement, and holds OPS and EMI licenses issued by the central bank. It's worth checking out and comparing against other options yourself — they're also reachable directly on Telegram.

Official sources

Don't take a provider's word for its license status. The central bank publishes a public list of registered electronic money issuers and operators of payment systems, which you can check against the company's registered name and license number. Ownership and registration details can also be looked up through the Securities and Exchange Commission.

Bangko Sentral ng Pilipinas (BSP) | Securities and Exchange Commission (SEC) (Last verified: September 2026)

About this guide and Yixing

Want someone to check your documents against the current requirements? → Yixing can review your case with you

Yixing is a private consulting company registered in the Philippines (SEC Reg. No. CS202009551; BI Accreditation No. CA-202624381-1). This guide does not name or rate other providers and does not promise any outcome; approval rests with the competent authority, and the rules in force are those it currently publishes. For legal disputes or case-specific judgments, consult a practising lawyer — this is not legal advice.