Royal77 Payments: FPX, DuitNow and TnG eWallet Checks

Why the shape of a payment step matters

This portal does not process payments and does not publish which methods a platform such as Royal77 offers, what any limit is, or how long anything takes. Those details belong to the platform and change without notice. What does not change much is how the underlying rails behave: FPX, DuitNow and Touch 'n Go eWallet each follow a fairly fixed sequence of screens, regardless of which merchant sits in front of them.

That fixed sequence is useful. A fraudulent payment page can copy a logo and a colour scheme easily, but it cannot easily reproduce the behaviour of a bank's own login or an e-wallet's in-app approval. If you know the expected sequence, you do not have to judge whether a page looks right. You only have to notice when a step is missing, out of order, or asking for something the real rail never asks for.

Everything below describes the rails in general terms. If a platform offers one of these methods, the steps you see should typically match what is described here. If they do not, stop before entering anything.

FPX: the redirect always lands on your own bank

FPX is an interbank online payment rail. When you pick it at a checkout, the merchant page typically hands you over to a bank selection screen, and from there you are redirected to your own bank's internet banking login. The login happens on the bank's own domain, in the bank's own interface, with the bank's own security image or phrase if it uses one. The merchant never sees your banking username or password, because you never type them on the merchant's page.

This is the single most useful property of FPX. A page that asks for your bank username and password while the address bar still shows the merchant, a payment gateway you do not recognise, or anything that is not your bank, is not an FPX payment. It is a credential-harvesting form dressed as one. The same applies to any chat message or pop-up that asks you to "confirm" your banking login outside the bank's site.

Once you are inside your bank's session, you normally see the merchant name, the amount and a reference, approve the payment with your bank's usual second factor, and are then sent back to the merchant with a status page. If you are asked for a TAC or OTP, it should be requested by your bank's interface, and the SMS or app notification carrying it should describe the same amount and merchant you are looking at.

1. 1Select FPX and your bank on the merchant checkout.
2. 2Check that the address bar changes to your bank's own domain before you type anything.
3. 3Log in as you normally would, then read the merchant name, amount and reference shown by the bank.
4. 4Approve with the bank's own second factor; confirm the TAC or OTP message describes the same transaction.
5. 5Wait to be returned to the merchant and note the FPX transaction ID shown on the status page.

DuitNow QR and DuitNow transfer: read the recipient name

DuitNow works differently. There is no redirect to a login page because you are already inside your own banking or e-wallet app. You either scan a DuitNow QR code or enter a DuitNow ID or account number, and the app looks up the recipient and displays the registered name before you confirm. That preview screen is the control. The name shown comes from the recipient's bank or e-wallet registration, not from whoever sent you the QR code or account details.

So the check is simple: the name on the preview should match what you were told to expect through the platform's official support channel. If a business or registered merchant name was expected and the preview shows an individual's personal name, treat that as a stop sign, not a quirk. If the name is slightly different from what support stated, or the account number differs from the one shown inside your logged-in session on the platform, do not confirm.

A DuitNow transfer is typically immediate and difficult to reverse. There is no later step where a mismatch can be caught, which is why the preview screen deserves a slow read rather than a tap. After confirming, your app shows a reference number and the transfer appears in your transaction history with the recipient name attached.

Touch 'n Go eWallet: approval stays inside the app

When a merchant accepts Touch 'n Go eWallet, the payment is typically completed inside the eWallet app itself, either by scanning a QR code or by being handed from the merchant page into the app. The app shows the merchant name and amount, asks for your six-digit PIN or biometrics, and then displays a success screen with a transaction ID. The merchant does not receive your PIN, and no genuine flow asks you to type your eWallet PIN on a web page or send it in a chat.

Two things should make you pause. The first is any request to enter eWallet credentials, a PIN or a verification code anywhere other than the app's own screens. The second is a flow that never opens the app at all, yet claims the eWallet payment is complete. If the app did not ask you to approve, nothing was paid from your wallet, whatever a web page or a chat message says.

After a genuine payment, the transaction appears in the app's history with the merchant name, amount, date and the same transaction ID shown on the success screen. That ID is what support would normally ask for if something needs to be traced.

What a genuine confirmation screen normally shows

The exact layout varies by bank and app version, but the elements below are consistent enough to serve as a checklist. A fake step usually omits one or more of them, or shows them in a place where they cannot be verified, such as a screenshot pasted into a chat.

Screenshots, OTPs and accounts sent in chat

Three patterns account for most payment fraud around platforms of this kind, and none of them involves breaking a payment rail. They work by getting you to step outside it.

A screenshot described as "proof of payment" is an image, not a record. It can be edited, reused, or taken from an unrelated transaction. The only proof that money moved is an entry in the payer's bank or e-wallet history, which the recipient can see on their own side without any screenshot at all. If someone sends you a screenshot and asks you to act on it, the correct response is to check your own records and nothing else.

An OTP or TAC is a one-time authorisation for a specific action. Nobody who genuinely works for a bank, an e-wallet or a platform needs it from you, because the systems they operate generate it. Any request to read one out, type it into a chat, or forward the SMS is a request to authorise something on your behalf. Decline, every time, including when the person seems to know your account details already.

Finally, an account number or QR code that arrives in an unsolicited message is not a payment instruction from the platform, regardless of the sender's display name or profile picture. Payment details for a platform are shown inside your logged-in session on the official destination. If a message tells you to pay somewhere else, or says that the usual method is "under maintenance" and offers an alternative account, go back to the logged-in session and check there. If it is not shown there, do not pay.

How to read your transaction history afterwards

Whatever rail you used, the record that matters is the one in your own bank or e-wallet, not the one in a chat and not even the one on the merchant's page. Open the history entry for the payment and read it in full rather than glancing at the amount.

Check that the recipient or merchant name matches what you expected, that the date and time match when you paid, and that the reference or transaction ID matches the success screen you saw. Keep that ID. If a payment does not appear where it should on the platform side, contact support through the official destination and quote the ID from your own records. A support team can trace a transaction from an ID; it cannot do much with a screenshot.

If you find an entry you do not recognise, or a recipient name that is not the one you were shown at confirmation, contact your bank or e-wallet provider first using the number on your card or inside the app, then the platform. Do not respond to anyone who contacts you afterwards offering to recover the money, because unsolicited recovery help after a payment problem is itself a common second stage.