Hi @Fr0zon,
Short version: with ABSA this is almost certainly not a missing walled-garden host, and no host list can fix it. Let me explain why, then answer the trial-session question.
1. ABSA approves card payments with SureCheck — a push to the banking app
ABSA’s 3-D Secure step is SureCheck: the cardholder gets a push notification in the Absa Banking App and taps Approve. SMS OTP is only a fallback after three failed SureCheck attempts.
That splits the payment across two different network paths:
| Path |
What it needs |
Can the walled garden cover it? |
| Browser → 3DS/ACS page |
the ACS hostname + its assets |
Yes, in principle |
| Phone → APNs/FCM push → Absa app |
non-HTTP ports, rotating IPs |
No — structurally |
The MikroTik hotspot walled garden dst-host table handles HTTP and HTTPS only. Apple’s APNs needs a persistent TLS connection on TCP 5223, FCM needs TCP 5228–5230, and both Apple and Google explicitly tell you not to allowlist their IP ranges because they rotate. So if the guest’s phone is on your hotspot while unauthenticated, the approval push may simply never arrive — and there is no line you can add to fix that.
The test that settles it in two minutes, with no config change: have the guest pay with the phone on mobile data (WiFi off on the phone), while the browsing device stays on the hotspot. If the payment then goes through, the push path was the problem.
2. Why “the host is in my list and it still fails” happens
Worth knowing, because it explains a lot of the inconsistency people see:
- The walled garden matches off the router’s DNS cache, not TLS SNI. RouterOS watches the unauthenticated client’s own DNS lookups and permits the resolved IPs. So if the device uses DoH / DoT / Android Private DNS — now the default in Chrome, Firefox and iOS — the router never sees the lookup, never caches the IP, and the host stays blocked no matter what is in your list. That is also why it works on one phone and not the next.
dst-host takes a domain only. A URL path inside dst-host (e.g. 3ds.capitecbank.co.za/acs/) can never match — path is a separate parameter.- Never pin IPs for Azure/AWS/Cloudflare-fronted hosts; use host wildcards.
3. Host-list hygiene — dead lines to drop, lines worth adding
These are dead today (all NXDOMAIN as of this week, or unmatchable syntax), so they can go:
/ip hotspot walled-garden
remove [find dst-host="acsabsa.dnslb.bankserv.co.za"]
remove [find dst-host="3dsbrowser.capitecbank.co.za"]
remove [find dst-host="3dsbrowser.capitecbank.*"]
remove [find dst-host="3dsbrowser.capitecbank.co.za/"]
remove [find dst-host="3ds.capitecbank.co.za/acs/"]
remove [find dst-host="authentication.cardinalcommerce.com/ThreeDSecure/"]
remove [find dst-host="t.clarity.ms/collect"]
remove [find dst-host="connect.facebook.net/en_US/fbevents.js"]
ABSA’s current ACS hostname could not be identified from public DNS — acsabsa.dnslb.bankserv.co.za is gone, while its siblings in the same zone are still live. Don’t guess a replacement; the broad *absa* and *bankserv* entries already cover far more than a single hostname would.
And these are the additions actually worth having:
/ip hotspot walled-garden
add dst-host=*capitec*
add dst-host=authentication.cardinalcommerce.com
add dst-host=acs-challenge.apata.io
add dst-host=acs21.nedsecure.co.za
add dst-host=*.americanexpress.com
Note *capitec* rather than *.capitec.* — the latter does not match 3ds.capitecbank.co.za, which is live. The same logic is why *absa* is the right shape for a bank estate: it even catches the lb-absa.co.za apex.
One more thing while we’re in this topic: you can drop *.digitaloceanspaces.com from your list. It is still in our older posts and docs, but Powerlynx no longer stores splash-page assets there — *.powerlynx.app plus the CDN entries you already have cover it. We’re cleaning that up in the documentation.
To be straight with you: the above is hygiene, not the fix. If SureCheck is the blocker, a tidier list will not change the outcome.
4. Trial sessions — what triggers them, and one important caveat
What triggers a trial session: it fires the moment the guest presses “Pay with <gateway>” on the splash page. Not on association — there is no button for the guest, and they are never told they have free access. It only happens for a paid plan going out to a gateway (a zero-price plan issues a voucher directly), and only if you have added that location under Config → Captive portal → Trial sessions (the location list is empty by default, so nothing happens until you do).
Why it helps: a trial session authorises the device via RADIUS, and an authenticated hotspot user bypasses the walled garden entirely. So arbitrary bank / 3DS / ACS hosts become reachable, DoH or not, without you having to guess a single hostname.
Defaults worth changing before you rely on it:
- Session time: 5 minutes — often too short for a bank 3DS journey. Raise it.
- 2 trial sessions in a row, then blocked for 60 minutes — past that quota the next pay-click silently gets no trial and falls straight back to walled-garden-only. This is the usual cause of “it worked for me twice and then stopped”.
- Speeds default to 2 Mbps / 1 Mbps, no data cap.
Use this as a test, not just as a workaround. Because a trial session removes the walled garden from the equation entirely, it makes a very clean A/B — and the cleanest way to run it is on an iPhone or iPad (see the caveat below for why not Android):
- Enable trial sessions for the location, raise the session time to 15 minutes.
- Have someone attempt the ABSA payment on an iOS device, with the phone receiving the SureCheck push on the hotspot.
- If the payment now completes → the walled garden was the blocker, and we should work out which host was missing.
- If it still fails on iOS with a trial session active → the walled garden is ruled out, and the SureCheck push path is your problem. That is the outcome I would expect.
Either way you learn something definite, and step 4 saves you from chasing hostnames for weeks.
The caveat, and please read it before rolling this out: trial sessions break the checkout on Android 11 and newer. Authorising the device makes Android mark the network as validated, and the system captive-portal window (the CNA WebView) auto-closes the instant that happens — taking the payment page with it, mid-checkout. iOS keeps the window open and is unaffected, which makes the whole thing look intermittent rather than broken. If your guests are mostly Android, this will hurt more than it helps; a workaround there is to get the guest into a normal browser rather than the captive-portal popup.
What would help us dig further
If you can, a short video of one failed attempt would tell us a lot:
- does the ABSA page reach “waiting for approval”?
- does the push ever land on the phone — and is that phone connected to the hotspot at the time?
- what does the browser show at the moment it fails?
Also handy: your RouterOS version, and whether the guest devices have Private DNS / DoH enabled.
Please send that to support@powerlynx.app rather than posting it here — a checkout recording can catch card details or personal data on screen, and a ticket also lets us look at your tenant and NAS configuration directly. Feel free to reference this thread in the email, and we’ll keep the general findings public here so others hitting the same ABSA wall benefit from them.
