The user story map organizes the requirements per user, activities, tasks and more detailed user-stories, that break down the user task level into smaller implementable pieces. The pieces are intended to serve as input for the backlog.
In your example, for the buyer the things are crystal clear : the role determines the platform. For the seller its less obvious because of the two platforms. Several approaches could be envisaged:
Platform independent story: this means that the implementation of each story piece will be always be done in parallel, within the same release. This works best if you have subteams each responsible for its own platform.
Platform dependent stories at the most detailed level: mention the platform in the what-I-want
part of the story or as part of the user role. Personally, I would go for the less conventional way of adding an [on <platform>]
clause to highlight that 's a different concern. In any case, these options are ideal if you might need to advance at different speed for each environment, or if you'd need to have different variants on each platform (e.g. to make best use of native features)
Lead platform stories and port stories: it's a mix of the previous approaches. User stories are detailed in a platform independent manner for a main target platform. Summarization stories select several stories to be ported on the second platform. This approach works best if the application is developped with a multi-platform technology (e.g. Xamarin, Qt, ...) on one OS platform, but with a design that facilitates the port to the other platform.
As you see, the fact that the stories are the backlog and are used to determine sprints, the best approach will heavily depend on how you intend to organize the multi-platform development and on your team structure.