View Issue Details

IDProjectCategoryView StatusLast Update
0011072Talermerchant backoffice SPApublic2026-03-06 15:58
Reporterhow Assigned Tovlada.svirsh  
PrioritynormalSeverityfeatureReproducibilityalways
Status confirmedResolutionopen 
Product Versiongit (master) 
Target Version1.8 
Summary0011072: Issues with Merchant back office onboarding process
DescriptionThere are several issues with the backend form. Here is my feedforth using https://stage.my.taler-ops.ch/

1. Firefox fails to recognize the username for saving the password. Instead of capturing the username it captures the business name. This is because of how Firefox tries to catch the username. It first looks for 'login', 'username' or 'email' field above the password field. If those do not exist, it goes for the text field immediately above the password field. Therefore the username field should be called username and not id.

2. But point 1 is not the only issue. UX would be much better with the following process: a three-step wizard with simpler forms. (see attached screenshots)

Step 1: Ask for a phone or email contact (to send a verification token to) and a business name (for public facing UI and for username generation), plus the acceptance of terms.
Step 2: Provide a unique username based on the business name (ASCII-based hyphen-separated version of the given business name -- which should therefore be limited for URL compliance, i.e., in length) + a field for the token sent by phone, or the one sent by email (which would actually be an URL that brings you straight to that wizard step so you only have the password to enter). This allows the user to spend the time waiting for the confirmation token actively entering a password.
Step 3: Confirmation, celebration!
Steps To ReproduceTo reproduce the Firefox password saving issue, go to the merchant onboarding page and enter a business name that is different from the username, then click 'create': if autosave passwords is active in Firefox (which is the default), you should see a popup with the Business name as the username.
Additional InformationThe screenshots show what could a three-step process look like. Note that the second step is doubled, depending on whether the first input was a phone or an email.

Extra fields (an email if a phone was entered, or vice-versa) should belong to the onboarding notifications once the account was created. See for example how Infomaniak keeps notifying the user to ask for more details -- which also teaches about notifications.
Tagsdesign-required, ux
Attached Files

Relationships

related to 0011159 resolvedsebasjm merchant onboarding page does not work well with password managers 

Activities

sebasjm

2026-03-05 12:48

developer   ~0027995

firefox problem was fixed with 0011159

MFA was improved with https://docs.taler.net/design-documents/089-merchant-2fa.html
to be implemented

I don't think splitting the form add any value, just more button to clicks.

This is a "won't fix" for me.
What we could do is create a new design document to define a "onboarding process" that bring the merchant from zero (without an account) to hero (it should see the value of having the taler).
That include:
 * creating an instance
 * setting up the bank account
 * complete the kyb process with one exchange
 * creating an order
 * pay the order

In this design document i would expect to define the screens, ux, text, buttons to very smooth to be completed without help.
Only after the merchant has completed all the steps is presented with the full version.

how

2026-03-06 09:15

developer   ~0028011

> I don't think splitting the form add any value, just more button to clicks.

Studies and experience have *proven* that multiple steps onboarding processes have more success. The less the friction, the better the result. I do not know any other payment system that requires so much details up front. Merchants will be less likely to drop out if they have already given in.

Christian Grothoff

2026-03-06 15:23

manager   ~0028013

Well, we do need both phone AND e-mail contact for 2-factor authentication for password resets, so we can't ask for phone OR e-mail. But that said, I'm not against breaking this up more, and I think some of this already happened. Anyway, full re-design should be with Vlada first.

sebasjm

2026-03-06 15:58

developer   ~0028023

> Studies and experience have *proven* that multiple steps onboarding processes have more success

I'm happy to change it for better but without evidence is always a discussion of preferences and taste which leads to longs discussions and questionable improvements. So, if there are studies, please share them and then discuss if those are relevant for this case.

> UX would be much better

You also don't explain the problem.

Issue History

Date Modified Username Field Change
2026-02-14 15:52 how New Issue
2026-02-14 15:52 how File Added: Screenshot 2026-02-14 at 15-49-30 Taler Backoffice Welcome!.png
2026-02-14 15:52 how File Added: Screenshot 2026-02-14 at 15-42-16 Taler Backoffice Welcome!.png
2026-02-14 15:52 how File Added: Screenshot 2026-02-14 at 15-37-50 Taler Backoffice Welcome!.png
2026-02-14 15:52 how File Added: Screenshot 2026-02-14 at 15-14-41 Taler Backoffice Welcome!.png
2026-02-15 12:04 how Tag Attached: ux
2026-02-15 22:25 Christian Grothoff Severity major => feature
2026-02-15 22:25 Christian Grothoff Status new => confirmed
2026-02-15 22:25 Christian Grothoff Target Version => 1.8
2026-02-25 17:23 Florian Dold Relationship added related to 0011159
2026-02-26 20:04 Christian Grothoff Relationship added related to 0011076
2026-02-26 20:04 Christian Grothoff Relationship deleted related to 0011076
2026-03-05 12:48 sebasjm Note Added: 0027995
2026-03-06 09:15 how Note Added: 0028011
2026-03-06 15:22 Christian Grothoff Tag Attached: design-required
2026-03-06 15:23 Christian Grothoff Note Added: 0028013
2026-03-06 15:23 Christian Grothoff Assigned To => vlada.svirsh
2026-03-06 15:23 Christian Grothoff Status confirmed => assigned
2026-03-06 15:23 Christian Grothoff Status assigned => confirmed
2026-03-06 15:58 sebasjm Note Added: 0028023