FIELD NOTES
A personal record of travel, networks and small failures
TRAVEL NOTE

PayPal Knew My Password—Then the VPN Made Every Login Look New

The duplicate payment appeared while I was waiting to board a flight from Madrid to New York. A client had paid the same invoice twice and wanted the second charge returned before her accounting team closed for the day. I opened PayPal on the airport lounge Wi-Fi, entered the correct password and reached a screen saying it could not confirm the login was mine. I blamed the app, closed it and tried again. The password worked. The security check did not.

My client sent another message:

“Can you refund it before your flight?”

I looked at the boarding time.

“Working on it.”

The duplicate payment was visible in the notification email. I knew which transaction needed to be returned. The problem was getting far enough into the account to do it.

I had connected my usual VPN before opening PayPal because the lounge network was shared with hundreds of travelers.

That precaution was now preventing me from completing the refund.

The short answer

PayPal could see more than the password. The apparent location, IP address, device information and timing of repeated attempts could all affect whether a login looked normal. ( Nist )

PayPal’s security advice left me in the middle

PayPal advises travelers to avoid public Wi-Fi for financial activity and recommends a VPN as an added layer of protection when making online payments abroad. (Paypal)

That was exactly what I had done.

PayPal also performs additional identity checks when activity looks unusual, including logins from a new device or location. Repeated unsuccessful attempts can lead to a temporary waiting period before another login is allowed. (Paypal)

Both measures made sense.

Together, they created a practical contradiction.

The lounge Wi-Fi was the strongest connection available. The VPN protected my traffic on that shared network. Yet every VPN server could make the same phone appear to be arriving from somewhere new.

PayPal was not checking only whether I knew the password.

It was deciding whether the entire login looked consistent enough to trust.

The familiar provider made me unfamiliar four times

The VPN already installed on my phone was a large, established service with years of public history, polished applications and servers across the United States.

For PayPal, I chose New York.

The login page accepted my email and password.

PayPal sent a code to my phone.

I entered it.

The page returned to the beginning.

I tried a second New York server, assuming the first address had been overused.

This time, PayPal accepted the code and asked me to confirm a card number. I entered the card attached to the account.

The screen still could not confirm it was me.

I changed to Boston.

Then Washington.

Then Chicago.

Each route reached a slightly different stage.

One displayed the account avatar before signing me out.

Another sent a fresh code.

A third asked me to approve the login inside the same PayPal app already trapped in the verification loop.

The long server list made every failure look temporary. Surely the next American city would seem more familiar.

Instead, I was turning one legitimate traveler into a sequence of logins arriving from different parts of the country.

My retries had become part of the problem

PayPal could see more than the password. The apparent location, IP address, device information and timing of repeated attempts could all affect whether a login looked normal. (Nist)

My phone had not changed.

My email had not changed.

My card had not changed.

Only the network identity kept jumping.

A brief public account described the same consequence: repeated PayPal logins through a VPN ended in a verification lockout and forced the user to stop trying. (Reddit)

That was enough warning for me.

Every server change was not a clean retry. It was another unusual login added to the same short period.

I stopped switching cities.

The boarding screen showed twenty-seven minutes.

The next test had to reduce variables rather than create new ones.

Turning the VPN off solved only the first screen

I disconnected the VPN and reopened PayPal on the lounge Wi-Fi.

The login went farther immediately.

PayPal accepted the password, sent another verification code and opened the account dashboard.

For several seconds, I thought the problem was over.

Then the lounge network redirected the browser to its access page. The Wi-Fi session had expired and wanted me to accept the terms again.

When I returned to PayPal, the dashboard had disappeared.

I rejoined the network and logged in once more. The account opened, but the refund page stalled after I selected the duplicate transaction.

The Wi-Fi was strong enough for ordinary browsing. It was not keeping the financial session steady.

I could continue without a VPN and hope the network stayed connected long enough. That would solve the login by discarding the reason I had enabled protection in the first place.

So I tried the other obvious escape: mobile data.

Roaming data reached the refund and dropped it

Near the lounge windows, my phone found a roaming signal.

PayPal opened without the VPN.

I passed the login check and reached the duplicate payment.

I tapped Issue refund.

The page loaded the amount and asked for confirmation.

Then the signal dropped from 5G to weak LTE.

The confirmation button stopped responding.

A few seconds later, PayPal returned an error and asked me to log in again.

Roaming data removed the shared Wi-Fi from the equation, but it could not hold the session inside the terminal.

I now had two incomplete choices:

a strong airport network I did not want to use unprotected;

a private mobile connection too unstable to complete the refund.

The larger VPN should have combined the security of the first with the access of the second. Its changing routes had done the opposite.

By then, the requirement was clear.

I needed one protected connection that would remain consistent from the password screen to the refund confirmation.

The smaller app began with the account, not the map

I returned to the lounge Wi-Fi and closed the established provider.

Then I opened the smaller backup installed before the trip.

It did not show me a map.

The first screen asked what I needed to do.

I selected the preset for a sensitive account on shared Wi-Fi.

The app established one route without asking me to choose New York, Boston or Chicago.

I opened PayPal.

The password worked.

The verification code arrived.

The dashboard loaded.

I selected the duplicate payment.

The refund page opened with the correct amount.

I tapped Issue refund.

The confirmation completed.

PayPal marked the transaction as refunded and displayed the reference number.

I copied it into the client conversation.

“Done. You should have the confirmation now.”

Three dots appeared beneath her name.

Then:

“Got it. Thank you.”

The duplicate payment had been returned.

The protected connection was still active.

Most importantly, I had stopped presenting PayPal with a new apparent location every two minutes.


One steady route completed what four cities could not

The preset had selected a stable, obfuscated route instead of sending me through a manual sequence of familiar commercial VPN exits.

I could not observe PayPal’s internal fraud model or identify the exact signal that separated the accepted connection from the rejected attempts.

The result was clear:

the established provider reached parts of PayPal but never completed the login and refund;

the unprotected lounge connection reached the account but lost the session;

roaming data reached the confirmation page but failed before the refund;

the smaller app kept one protected path open until PayPal returned the money.

That changed the comparison.

For PayPal, opening the homepage was not success.

Accepting the password was not success.

Receiving a verification code was not success.

The same connection had to remain acceptable through login, transaction review and final confirmation.

The receipt arrived after the Wi-Fi disappeared

I still needed a copy of the refund receipt for my records.

While the PDF downloaded, boarding began and I left the lounge.

The phone lost the lounge Wi-Fi near the gate and switched to roaming data.

The smaller app showed a brief recovery message.

The PayPal page remained open.

The receipt finished downloading.

Its HTTP/3-based connection carried the session across the network change instead of rebuilding everything from the beginning.

On the screen, the result looked ordinary:

the Wi-Fi disappeared;

mobile data took over;

the receipt reached my downloads folder.

I did not sign in again.

I did not request another code.

I did not reopen the transaction.

The refund was already complete, and the network change did not create another security loop.

Excluding PayPal from the VPN missed the point

The established provider included an option to exclude selected apps from the protected connection.

I could have placed PayPal on that list.

That might have restored access by sending the app directly through the airport Wi-Fi or mobile network.

It also would have made the financial app the exception.

In a familiar home network, that compromise might be acceptable. In an airport lounge, PayPal was the app I least wanted to remove from the protected route.

The smaller app did not require an exception.

It completed the login and refund while the connection remained active.

That was more useful than technically restoring PayPal by switching protection off for the service handling my money.

More servers had encouraged the wrong behavior

The smaller service has fewer locations, fewer independent reviews and a shorter public history than the established provider. That is its clearest limitation.

Before the trip, those facts would have made the larger company feel safer for a financial account.

At the airport, its scale encouraged exactly the wrong response.

New York failed, so I tried another New York server.

That failed, so I moved to Boston.

Then Washington.

Then Chicago.

Each new location gave PayPal another network identity to evaluate.

The smaller app reduced the decision to the task in front of me. It selected one route, kept it stable and remained connected until the refund was complete.

The established provider gave me more places from which to knock on PayPal’s door.

The smaller app let the same person remain there until it opened.

For PayPal, the useful VPN was the one that allowed one login to remain one login.

Questions this experience may leave you with

What was actually causing the problem?

PayPal could see more than the password. The apparent location, IP address, device information and timing of repeated attempts could all affect whether a login looked normal. ( Nist ) (Nist)

Why did the obvious fixes fail?

A brief public account described the same consequence: repeated PayPal logins through a VPN ended in a verification lockout and forced the user to stop trying. ( Reddit ) (Reddit)

What should you check first?

PayPal also performs additional identity checks when activity looks unusual, including logins from a new device or location. Repeated unsuccessful attempts can lead to a temporary waiting period before another login is allowed. ( Paypal ) (Paypal)

What finally changed the result?

The duplicate payment appeared while I was waiting to board a flight from Madrid to New York. A client had paid the same invoice twice and wanted the second charge returned before her accounting team closed for the day. I opened PayPal on the airport lounge Wi-Fi, entered the correct password and reached a screen saying it could not confirm the login was mine. I blamed the app, closed it and tried again. The password worked.

What is worth remembering?

Most importantly, I had stopped presenting PayPal with a new apparent location every two minutes.