Swedish WordPress hosting where BankID logins come back.
In Sweden identity is verified by an app, not a password. The user leaves your site, authenticates elsewhere, and returns - and the return is where it breaks.
Authentication happens somewhere else.
Everything here follows from login being a round trip out of your site and back, rather than a form submission.
A session that still exists on return
BankID sends the user to an app and returns them by callback. If the session has been rotated or cached away in between, they arrive authenticated and logged out at the same time.
Callbacks that are never cached
The return URL carries a one-time result. Cached or rate limited, it produces a login that succeeded for the provider and failed for the user.
Waiting without timing out
Someone opening an app on their phone takes longer than a form post. The pending window is sized for a person reaching for a device, not for a network round trip.
An EU origin near the Nordics
Swedish visitors are served close and storage stays in the EU, so latency and residency have the same short answer.
Very high mobile share
Swedish traffic is overwhelmingly mobile and the authentication step is on a phone by definition, so the whole flow is designed for one.
The failure is on the way back.
Sending a user to BankID is easy. Having them arrive back at a site that still remembers who they were mid-flow is the part that quietly does not work.
- Session preserved across the identity round trip
- Callback URLs excluded from caching and throttling
- Pending window sized for a human with a phone
- EU origin and EU storage
Logins that finish.
Page speed is not the number here. The number is what share of BankID attempts end with a signed-in user rather than a confused one.
What we change for Swedish sites
Login leaving the site and coming back is the property everything else is arranged around.
| Setting | What we do | Why |
|---|---|---|
| Session continuity | Preserved across an external identity round trip | BankID returns the user by callback, and a session rotated or dropped in the interim leaves them authenticated at the provider and anonymous on your site. |
| Callback handling | Excluded from caching and from rate limiting | The return URL carries a single-use result, so a cached or throttled response turns a successful authentication into a failed login. |
| Pending timeout | Sized for somebody picking up a phone | The wait includes a human unlocking a device and opening an app, which is far longer than any timeout written for a network call. |
| Origin placement | EU, positioned for Nordic reach | Keeping delivery close and storage inside the EU makes the latency and residency questions one answer instead of two. |
| Mobile assumption | Treated as the primary case, not the fallback | The authentication step happens on a phone by definition, so a flow designed for desktop first is designed for the wrong device. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Why do BankID logins sometimes fail on my site?
Can the login callback be cached?
Why do logins time out?
Where is a Swedish site hosted?
Let the login complete.
Move the site to an EU origin - migration is free, login flow tested.