Logging in as a customer to support them without asking for their password

«The payment method doesn't show up.» «I'm seeing a different price.» «I can't find my invoice.» To solve these calls you need to see what the customer sees: their cart, their addresses, their price group, their country. From the back office you can see the data, but not the shop as they receive it. And that is where the shortcuts begin.

The usual shortcuts and what is wrong with them

Asking for their password

It is the quickest option and the worst. The customer learns that giving out their password over the phone is normal, and that same habit is exactly what scams posing as support exploit. Besides, many people reuse their password: the one they read out to you may also be their email password. And once said, it ends up written in a note, a chat or a ticket.

Changing their password from the back office

You log in with a password you set yourself and then ask them to change it. The customer is locked out until they do, does not know why their password no longer works, and there is nothing in the shop's log saying it was you.

Creating a similar test account

It works for general bugs, but it does not reproduce what matters: the customer group, the cart rules that apply to them, their address, their history. Many issues depend precisely on that.

Screen sharing

It works with customers who know how to do it, and it is slow. Nor does it let you review the account calmly after you hang up.

What you really need

Access that meets four conditions:

1. Without knowing the customer's password, or changing it.
2. Limited to whoever should use it: not everyone with back-office access should be able to log into customer accounts.
3. Not reusable: a link that works once and expires right away, so it does not get passed around.
4. Logged: which employee logged into which account, when and from where.

What the GDPR says about this

Logging into a customer's account means processing their personal data: you see their name, their addresses, their orders and what they have left in the cart. The regulation does not forbid it, but it requires you to do it for a reason and under control. Some guidelines that fit the GDPR principles of purpose limitation and accountability:

• Only for legitimate support: solving an issue the customer has raised or investigating a problem with the shop. Not for snooping or for marketing.
• Inform your team that access is logged and what it may be used for. Put it in your internal instructions.
• Keep the log in line with your data protection policy, neither forever nor deleting it the next day.
• Mention it in your privacy policy if you routinely provide support this way: the customer should know that, to handle their queries, the team may look at their account.
• Do not change anything without telling them. If, once inside, you correct an address or empty the cart, let them know.

How to do it properly, step by step

1. The customer raises the issue by phone, email or chat. Note it on their record or in your ticketing system.
2. An authorised employee logs into their account from the back office, in a separate tab, without losing their own administrator session.
3. They reproduce the problem: the cart with what it contained, the checkout step where it gets stuck, the payment method that does not show up.
4. They fix the cause in the back office (a badly configured cart rule, a carrier with no zone, a group without a payment method) or explain to the customer what to do.
5. They close the customer's session and leave a note of what they saw and what they did.

Which issues can be solved this way

• Payment methods or carriers that do not appear, usually because of the combination of country, customer group and cart amount.
• Prices different from what was expected, because of group-specific prices or cart rules that do or do not apply.
• Vouchers that do not work for that particular customer.
• Invoices or downloads that do not appear in their account.
• Errors at a checkout step that only occur with their data: a postcode, a province, a tax ID (NIF).
• B2B customers who need you to prepare an order and leave it in their cart.

What you must not do once inside

• Place an order in their name without them asking you to.
• Change their email, their password or their communication preferences.
• Log in «to have a look» at accounts that have no open issue.
• Share the access link with a colleague by chat.

Who should be able to do it

Not the whole team needs to log into customer accounts. It is usually enough for whoever handles order issues and whoever maintains the shop. Logistics, catalogue or marketing rarely need it, and the fewer people who can do it, the easier it is to review the log and the clearer it is who was responsible for each access. If your team is large, review that log from time to time: an employee who logs into many accounts without open issues is something worth asking about, even if the explanation turns out to be innocent.

And if you hire external support, they should have their own employee account with a limited profile, not someone else's. That way their access appears under their name in the log and you can remove it the day the contract ends.

Access like this also depends on keeping the shop up to date

A feature that lets you log into customer accounts is sensitive by definition. If a module handles it, it should be maintained, work with your version of PrestaShop and be updated when you update the shop. A home-made system built years ago, with a master password written in the code, is exactly what you do not want.

How to solve it in PrestaShop

RKR Acceso maestro adds an «Access as…» button on the customer record and on the order page, and a «Log in as» option in the customer and address lists. The shop opens in a new tab and your administrator session stays intact. There is no master password: each access uses a link with a random single-use token that expires within seconds (configurable between 30 and 3,600 seconds; 5 minutes by default). Only the employee profiles you choose can use it, SuperAdmin only by default, and every access is logged with employee, customer, date and IP. On entry, the customer's last real cart is loaded, the one that never became an order, so you see exactly what they see. It works from PrestaShop 1.7.8 up to 9.x.