View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011072 | Taler | merchant backoffice SPA | public | 2026-02-14 15:52 | 2026-03-06 15:58 |
| Reporter | how | Assigned To | vlada.svirsh | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Product Version | git (master) | ||||
| Target Version | 1.8 | ||||
| Summary | 0011072: Issues with Merchant back office onboarding process | ||||
| Description | There 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 Reproduce | To 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 Information | The 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. | ||||
| Tags | design-required, ux | ||||
| Attached Files | |||||
|
|
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. |
|
|
> 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. |
|
|
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. |
|
|
> 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. |
| 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 |