The standard advice — clear all cookies — logs you out of your entire internet to fix one bank. This is the surgical version: one domain's data out, gateway hops allowed, everything else untouched.
Most bank access errors that survive a page refresh live in one place: the stored session data for the bank's own domain. It ages, it corrupts, and the bank — correctly — refuses to continue a payment on a session it cannot trust. The fix is not a browser-wide wipe. It is removing one site's data, then deliberately allowing the two things a payment genuinely needs: the redirect to the gateway and back, and the cookies that carry you across it.
👆 One site's data, surgically removed. Everything unrelated to the bank stays exactly as it was.
Cookies are how the bank's website remembers, between one click and the next, that the person paying is the person who logged in. A payment is not one page — it is a chain: login, account, payee, gateway, confirmation. If the stored session data for the bank's domain is old, half-updated or corrupted, the chain snaps somewhere in the middle and presents as an access error, a login loop, or a blank page at the final step.
Shopping sites survive this because their chains are short and forgiving. Banks are not forgiving — by design. That is why the same browser opens everything else and still fails only here.
This removes the corrupted session for one domain and leaves the rest of your browser life untouched:
The deep-clean alternative lives at chrome://settings/content/all — search for the bank's domain there and delete just its entry. Same effect, same restraint: one domain, not the whole browser.
When you press Pay, the bank sends you to a payment gateway on a different domain, and the gateway sends you back with the result. Browsers increasingly block exactly that behaviour. Inside the same site settings page:
These allowances are per-site. You are opening one door for one bank — not lowering the walls everywhere.
Not ready to clear data? Test the theory in thirty seconds: open an Incognito / InPrivate window and log in to the bank there. Incognito starts with no cookies and (by default) no extensions — so if the payment works there, your diagnosis is already done: it was the site data or an extension, and Steps 2–3 are the permanent fix in your normal window.
If it fails identically in Incognito, stop clearing things — the cause sits elsewhere (network, VPN, or the bank itself), and the split test in this set will place it.
Watch the video for these site settings shown on a real screen — the lock icon route and the one-domain clear.
▶️ Watch Full VideoNo. Saved payees, statements and your account live at the bank, not in your browser. Clearing site data removes the local session files on this device — you simply log in again and everything is there. What does disappear is convenience: any 'remember this device' trust on this browser may need to be set up again.
For this class of problem, site data (cookies and stored session data) is the active ingredient. The Delete data option in site settings clears the site's stored data together, which is what you want. A separate full cache clear for every website is rarely necessary and mostly costs you time while sites reload.
Test once in an Incognito window. If it works there but not in your normal window, an extension is interfering — pause blockers for the bank site. If it fails in Incognito too, the cause is not your site data: check the VPN and clock steps in this set, and run the app-versus-browser split test to see whether it is your network or the bank.