Why We Built PointsPulse Without Storing Your Passwords

Last updated: May 5, 2026. Loyalty programs change rules frequently. Verify with the program before relying on this for a redemption.

I want to explain the design decision that shaped this product more than anything else: we don’t store your loyalty program passwords. We can’t see them. We never will.

This is unusual for a points tracker, and it’s worth explaining why we made the choice and what the tradeoff is.

The thing that bothered me about every existing tracker

I’ve been in the points and miles hobby for years. I’ve used most of the major trackers. AwardWallet, the incumbent since 2004, asks for your username and password for each loyalty account, then logs in on your behalf to pull your balance. MaxRewards and Kudos take a similar approach for credit card accounts, using bank-level credential connections through aggregators. These tools work. They’ve worked for two decades.

But the underlying model is the same: a third party holds the keys to your accounts.

From a security standpoint, that’s hard to look at and feel comfortable. You’re handing over passwords to between five and twenty accounts to a third party, trusting that:

1. Their database doesn’t get breached.
2. Their employees can’t access your credentials.
3. Their automated logins don’t get flagged as suspicious by the loyalty programs.
4. Their credentials don’t get phished or otherwise leaked through any of the dozens of services they integrate with.

For most users, in most years, the model holds up. AwardWallet has been around for two decades, and while there was a 2015 incident where roughly 250 accounts with weak or reused passwords were compromised through brute force (which AwardWallet disclosed publicly), there has been no mass database breach in their history. That’s real credit to their security work. They use 1024-bit RSA for loyalty passwords and bcrypt for account passwords. That’s not amateur. But the underlying design is brittle. The list of major data breaches over the last decade is long, and many of them happened to companies with serious security teams.

The risk is also asymmetric. If your tracker leaks, your loyalty accounts are at risk. If your loyalty accounts get drained, your points are usually gone. Loyalty programs are notorious for slow response, sometimes refusing reinstatement entirely if the breach happened on the user’s side (which they’ll argue your tracker is). And if your tracker also has access to your credit card login (Chase, Amex, Citi), the exposure is no longer just loyalty points. It’s the financial account behind them.

I wanted a different model.

The DOM-reading approach

The insight that made PointsPulse possible is simple: when you visit your loyalty program’s website, you’re already logged in. You’re already looking at your balance. The page already contains the information.

A Chrome extension that reads the page when you’re on it doesn’t need your password. It needs your permission to read content on the loyalty program’s domain, which Chrome enforces through the standard extension permissions model. The extension waits until you visit Marriott, sees that you’re logged in, reads your balance from the page, and sends just the balance and expiration date to your dashboard.

Your password never touches our servers. We don’t have it. Even if we wanted to log into your account, we couldn’t.

This isn’t a wholly new pattern. Plaid uses tokenized OAuth where banks support it. Browser-based receipt parsers work the same way. Travel Freely (the credit card and 5/24 tracker) takes a different but philosophically similar approach: they don’t ask for any credit card numbers or bank logins at all, just the names and dates of cards you’ve opened. The common thread across all of these is doing useful work without holding the user’s credentials. The difference is that we apply that pattern specifically to loyalty programs, which historically haven’t had OAuth APIs available to consumer trackers.

The tradeoffs

This isn’t free. The DOM-reading approach has real limitations and we should be honest about them.

You have to be logged in. PointsPulse can only read your balance when you’re on the loyalty site and logged in. We don’t initiate logins on your behalf. This means the dashboard updates when you visit each site, not on a fixed schedule. For most users this is fine, you log into Marriott or Chase often enough that the data stays current. For users who have accounts they rarely visit, the data goes stale.

Loyalty sites change their HTML. Every tracker that reads loyalty program data is fighting an entropy battle. AwardWallet faces the same issue, just on a different layer (form fields and login flows instead of balance text). When a program redesigns their dashboard, our extension needs an update. We push these updates regularly, but there are sometimes a few days of lag.

Smaller program list. AwardWallet supports 600+ programs because they’ve been at it for two decades. We support 10 of the biggest US programs because that’s what we’ve validated and continue to maintain. We expect this list to grow, but it will never match AwardWallet’s breadth.

Two-factor authentication can interrupt scans. When a program prompts for 2FA, the extension can’t read the page until you complete it. AwardWallet has the same problem from the other side: increasingly, they can’t auto-update accounts with 2FA at all, which is part of why American AAdvantage was removed entirely from AwardWallet in 2023, and Delta, United, and Southwest now require email forwarding workarounds. Both models adapt the same way, by waiting for the user. The DOM-reading model deals with this more gracefully because you’re already at the site doing the 2FA naturally.

What this changes for the user

The practical difference shows up in three places.

If our service ever got breached, your loyalty accounts wouldn’t be at risk. There’s nothing in our database that an attacker could use to log into your Marriott account. They could see your point balances if our database leaked, which is a minor privacy concern but not a financial one. Compare to a credentials-storing tracker where a breach exposes everything.

You can use this for accounts you’d never trust to a tracker. A surprising number of points hobbyists have credit card portals (Chase Ultimate Rewards, Amex Membership Rewards) they refuse to put into AwardWallet because the credentials open up financial accounts, not just loyalty accounts. With PointsPulse, the same logic doesn’t apply. We can read your Chase Ultimate Rewards balance without ever seeing your Chase login.

You don’t have to manage credentials in two places. Every time you change your Marriott password, you don’t have to remember to update it in your tracker. There’s no tracker copy of the password to update.

Why this isn’t more common

A reasonable question. If this approach has real security advantages, why has nobody else done it?

The honest answer is mostly distribution and product complexity. Browser extensions are harder to distribute than web apps. They require a Chrome Web Store listing, ongoing review, and a smaller addressable user base (Chrome users on desktop). Many people in the points hobby are mobile-first, which extensions don’t serve well. AwardWallet, MaxRewards, and others can ship a clean iOS app. We can’t, at least not yet.

It’s also harder to build. The DOM scraping has to handle hundreds of edge cases per program, gracefully fail when sites are down or redesigning, and avoid breaking when 2FA flows interrupt the page. It’s significantly more engineering than a server-side scraper that just runs every 24 hours.

And finally, the business model is harder. Trackers that store credentials can offer mobile apps, server-side scheduled updates, and richer features that are harder to build in an extension. We chose to give that up to keep the security model simple.

Who this is right for

Not everyone needs this. If you’ve been using AwardWallet for years, you’re comfortable with the model, and you want broad program support, AwardWallet remains a good choice.

PointsPulse is right for you if:

• You have a meaningful loyalty balance you don’t want to lose to a credential breach.
• You track the major US loyalty programs and don’t need the long tail.
• You’re willing to use a Chrome extension and visit your loyalty sites occasionally.
• The security model matters to you more than the breadth of program support.

If those line up, give us a try. We have a free tier that covers up to 3 programs, no credit card required.

The broader argument

Beyond just our product, I think the password-storing tracker model is going to age out over the next decade. Two-factor authentication is becoming universal. Loyalty programs are getting more aggressive about flagging suspicious logins (which is partly why AwardWallet has progressively lost auto-tracking for the big four US carriers). Browser-based tools and OAuth-style integrations are eating the use case from both sides.

The tools that will be left standing are the ones that don’t need credentials in the first place. We built PointsPulse to be one of them. Whatever tracker you end up using, the question worth asking is: when this product’s database gets breached, what happens to my accounts? If the answer is nothing, you’re in a better place than most.