A returning customer wants to reorder, download an invoice, or check a shipment. They have forgotten their password. If the reset email never arrives, the link fails on their phone, or support cannot help safely, a routine visit turns into an avoidable interruption.

Customer password resets deserve their own acceptance test—not just a check that the login page loads. The goal is simple: let the right person regain access without exposing account information or making the support team invent a workaround.

Start with a customer account, not an administrator login

This checklist covers shoppers and portal users. It is different from recovering access to your hosting account or proving that an order-confirmation email works. Use a dedicated test customer with a mailbox your team controls and no real customer records. Do not reset a customer’s password to check the process.

For WooCommerce, Adobe Commerce, Shopware, or a custom portal, identify which system actually owns the login. If your store uses passwordless codes or an external identity provider, test that supported recovery path instead of adding a password-reset feature it does not need. Our guide to whether an online store should require customer accounts helps separate necessary access from unnecessary checkout friction.

1. Follow the complete mobile recovery journey

Start signed out on a phone. Find the recovery link, submit the test account’s email, open the message, choose a new password, and sign in through the normal login screen. Then visit the order history or account area the customer originally needed.

• Make the first step obvious. A shopper should not have to search the help center to find “Forgot password?”
• Check the message. The sender, store name, and secure destination should be recognizable. It must not include the customer’s password.
• Check mobile inputs. Password managers, paste, readable validation messages, and accessible field labels should work without needless obstacles.
• Confirm the finish. The new password works, the old password no longer does, and the customer receives a password-change notification.

Record delivery time and the exact point of confusion. A successful mail-service event is not the same as a usable email in a customer’s inbox. If delivery is the failure, use our transactional email testing checklist to trace the sender, template, and delivery path.

2. Test expired and already-used links

A reset link is a temporary credential. It should expire after an appropriate period and stop working after successful use. OWASP’s password-recovery guidance recommends single-use, expiring tokens, consistent responses, and protections against excessive reset requests.

Ask your developer to document the configured expiry and verify it with the test account. Open a previously consumed link and an expired link. Both should refuse another reset while offering a clear route to request a fresh one. Also check what happens when the customer requests more than one email and opens them out of order; the instructions should match the platform’s actual behavior.

For example, a shopper who opens yesterday’s message should see “This link has expired—request a new one,” not an unexplained error or an endless return to the login page. Keep real reset URLs out of screenshots, support tickets, analytics, and shared test reports.

3. Protect account privacy without trapping legitimate users

The public recovery form should not reveal whether an email belongs to a customer. A neutral response such as “If an account matches that address, we’ll send recovery instructions” can guide legitimate users without publishing account membership. Your developer should also review response timing and abuse controls; matching the visible wording alone is not a complete protection.

Rate limits should discourage automated email flooding without turning ordinary mistakes into a dead end. Have the technical team validate these protections in a controlled environment, not by sending a burst of requests through the live store. Simply requesting a reset should not lock the customer out of an otherwise valid account.

Agree on what happens to existing signed-in sessions after a completed reset. OWASP recommends offering session invalidation or doing it automatically. If the account uses multifactor authentication, confirm that changing the password does not silently remove that protection; losing the second factor needs its own verified recovery process.

4. Give support a safe fallback

Some customers no longer control the email address they registered with. Staff need an approved identity-verification and escalation procedure, especially when an account exposes invoices, saved addresses, or business purchasing permissions.

Do not ask customers to email a password, forward a live reset link, or disclose an MFA code. An order number alone is not sufficient proof of identity. Define who may approve recovery, what evidence is appropriate, where that evidence is handled, and how the action is recorded. A support agent should never have to choose between abandoning a customer and bypassing account security.

A small first phase that is easy to maintain

Start with one customer account type, one mobile device, and a short record: test date, platform, scenario, expected result, actual result, owner, and retest date. Fix broken delivery and unsafe access behavior first; then improve wording and convenience. Repeat the checks after authentication, email-provider, theme, or account-plugin changes.

Nexus Box helps businesses make ecommerce maintenance practical: verify the customer journey, fix the specific failure, and leave a repeatable check behind. The outcome is not a more complicated login system. It is a recovery process that works for customers and gives your team fewer preventable emergencies.

Photo: “Dell laptop keyboard” by David Precious (bigpresh), used under CC BY 2.0.