Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not default to a payment method #159

Closed
cmb69 opened this issue Aug 2, 2017 · 10 comments
Closed

Do not default to a payment method #159

cmb69 opened this issue Aug 2, 2017 · 10 comments
Labels
Milestone

Comments

@cmb69
Copy link
Member

@cmb69 cmb69 commented Aug 2, 2017

Dem Kunden soll keine Zahlungsmethode aufgedrängt werden, sondern er soll selbst wählen.

@cmb69 cmb69 added the enhancement label Aug 2, 2017
@cmb69 cmb69 added this to the 1.0rc1 milestone Aug 2, 2017
@cmb69 cmb69 closed this in 2a8a2ee Aug 2, 2017
@XHalbert

This comment has been minimized.

Copy link
Collaborator

@XHalbert XHalbert commented Aug 2, 2017

Ich finde das soll der Shopbetreiber entscheiden dürfen. Vllt. hat er eine bevorzugte Zahlmethode?

Also wäre es sinnvoll, im Wiki zu erklären, wie man eine Zahlart vorauswählen kann.

@frase-git

This comment has been minimized.

Copy link
Collaborator

@frase-git frase-git commented Aug 2, 2017

Ich glaube nicht, dass das gut wäre.
Sonst könnten wir auch gleich einen Haken bei "Mail für Paketdienst" machen, die Telefonnummer required und alles andere.
Der Kunde sollte nichts vorgeschrieben bekommen.

@XHalbert

This comment has been minimized.

Copy link
Collaborator

@XHalbert XHalbert commented Aug 2, 2017

einen Haken bei "Mail für Paketdienst" machen

das ist doch was ganz anderes - hier will ich nun wirklich keinen Haken.
Aber wieso eigentlich soll der Kunde nichts "vorgeschrieben" bekommen?
Wie gesagt, das sollte der Shopbetreiber entscheiden dürfen!
Tel. required (meinetwegen mir dem Hinweis "für Rückfragen") hab ich ja schon früher bevorzugt, und wie ich meine auch vernünftig begründet, aber da wurde ich überstimmt.

@cmb69

This comment has been minimized.

Copy link
Member Author

@cmb69 cmb69 commented Aug 2, 2017

Ich finde das soll der Shopbetreiber entscheiden dürfen. Vllt. hat er eine bevorzugte Zahlmethode?

Darüber habe ich auch nachgedacht. Aber bei der bisherigen Variante, hätte der Shopbetreiber die Reihenfolge der Zahlungsmethoden manuell in config.php ändern müssen. Da erschien mir Franks Vorschlag schon sinnvoller. Und der Shopbetreiber kann eine bevorzugte Zahlungsmethode noch immer "unterstützen", indem er einen Nachlass für diese Methode gewährt. Ich gehe schon davon aus, dass viele Käufer 1-2 € Nachlass nicht einfach ignorieren.

Tel. required (meinetwegen mir dem Hinweis "für Rückfragen") hab ich ja schon früher bevorzugt, und wie ich meine auch vernünftig begründet, aber da wurde ich überstimmt.

Ich würde das im Wiki zwar eher nicht dokumentieren, aber man kann requiredCustomerData einfach anpassen (in diesem Fall einfach noch 'phone' hinzufügen).

@XHalbert

This comment has been minimized.

Copy link
Collaborator

@XHalbert XHalbert commented Aug 2, 2017

hätte der Shopbetreiber die Reihenfolge der Zahlungsmethoden manuell in config.php ändern müssen

ja stimmt, daran hatte ich nicht gedacht. Frank dein Vorschlag ist besser.
Bei mir war bisher halt eher zufällig die erste Zahlart auch meine bevorzugte.

man kann requiredCustomerData einfach anpassen

danke für den Hinweis, ja das werde ich für meinen Teil sowieso wieder so machen - ich spreche also nicht in erster Linie für mich, sondern wollte andere Shopbetreiber an meiner Erfahrung profitieren lassen, da sich "Tel.Nr. optional" nicht bewährt hat.

@cmb69

This comment has been minimized.

Copy link
Member Author

@cmb69 cmb69 commented Aug 2, 2017

ich spreche also nicht in erster Linie für mich, sondern wollte andere Shopbetreiber an meiner Erfahrung profitieren lassen, da sich "Tel.Nr. optional" nicht bewährt hat.

Vielleicht sollte das dann doch unter Tipps dokumentiert werden; es muss halt nur klar gestellt werden, dass man wirklich relevante Felder dort nicht entfernen darf.

@frase-git

This comment has been minimized.

Copy link
Collaborator

@frase-git frase-git commented Aug 2, 2017

Eine Checkbox oder einen Radiobutton vorzubelegen, ist wohl auch ein datenschutzrechtliches Problem.
Auf jeden Fall dürfte sowas Verbraucherschützer auf den Plan rufen.
Das ist viel zu leicht zu übersehen.
(wie Kleingedrucktes in hellgrau auf grauem Papier)
opt-in / opt-out

@cmb69

This comment has been minimized.

Copy link
Member Author

@cmb69 cmb69 commented Aug 2, 2017

Auf jeden Fall dürfte sowas Verbraucherschützer auf den Plan rufen.

Die Verbraucherschützer schützen die Verbraucher noch so lange, bis diese nichts mehr zum Verbrauchen kaufen können. Ich kann als Verbraucher da schon lange nur noch den Kopf schütteln.

@frase-git

This comment has been minimized.

Copy link
Collaborator

@frase-git frase-git commented Aug 3, 2017

Leider leben wir in einer ziemlich eigenartigen Welt, der wir uns nicht vollständig verschließen können.
(Ich bin zwar weit raus aufs Land gezogen - das hilft aber auch nicht wirklich.)
Hier ein kurzer Artikel zu "vorangehakte Checkboxen".

@cmb69

This comment has been minimized.

Copy link
Member Author

@cmb69 cmb69 commented Aug 3, 2017

Hier ein kurzer Artikel zu "vorangehakte Checkboxen".

Interessant. Und klar, das "ich habe die AGB gelesen" darf auf keinen Fall angehakt ausgeliefert werden. Aber was, wenn es nur eine Zahlungsmethode gibt? – Letztlich aber egal, da ich denke, dass das in der Praxis eher die Ausnahme sein dürfte, und wohl jeder damit leben kann, dass der Kunde die gewünschte Zahlweise selbst auswählen muss. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.