Ja, haben wir leider auch gehabt. Die Kreditkarten Firmen geben zu 99% Ihrem Kunden recht. Mews und Stripe helfen dabei NICHT obwohl Tokenfee und Transactionfee verlangt werden. Habe Mews wegen MewsTerminal gefragt ob wir als Hotel dann besser geschütz wären, kriegte aber keine klare Antwort.

Um ganz sicher zu gehen, ist die einzige Möglichkeit bei Check-in eine physische KK zu verlangen und als Buchung und/oder Reservation auf KK zu arbeiten. Viel admin Arbeit aber für bestimmte Kundengruppen/Herkunftsländer leider nicht anders zu empfehlen.

Es wird als Debitorenverlust verbucht.

Hallo! Bin jetzt nicht der Fachmann dafür, aber vielleicht ist mein Wissenstand hilfreich:

Es ist generell zu empfehlen möglichst viele Transaktionen entweder am Terminal vor Ort abzuwickeln, auch wenn der Gast bereits eine Karte in Mews autorisiert hat (zB beim Online CI). Meines Wissens nach sind Chip+PIN, NFC+PIN oder biometrisch (ApplePay) authentifizerte Transaktionen (auch am MEWS Terminal) von den Kreditkartenunternehmen NICHT wieder rückbuchbar. Gleiches gilt für 3DS (strong customer authentication) online durchgeführte Zahlungen.

Nicht nur sind Chip+Pin / 3DS sicher, sondern meist auch günstiger im Transaktionsentgelt.

Man kann sich 3DS als verpflichtend einstellen lassen (wobei, ich denke eigentlich sollte das in Europa bereits der Fall sein, oder): https://help.mews.com/s/article/how-to-make-3ds-authentication-default

Dann sollte wohl immer 3DS bei Online-Transaktionen verlangt, sodass dafür Rückbuchungen eigentlich ausgeschlossen sein sollten. Aber auch dann dürfte gelten, dass aus MEWS heraus einseitig (ohne Kundenmitwirkung) ausgelöste Zahlungen (“Zahlungen → Kartenzahlung”) als MoTo Transaktion gelten dürften und damit rückabwickelbar sind. Also, am besten wann immer es geht die Karte vom Gast verlangen für eine Terminal Zahlung oder 3DS Online Zahlung.

Ich denke es wäre hilfreich, wenn MEWS hier was die Zahlungswege angeht mehr Klarheit und Transparenz darstellen würden, sodass auf einen Blick klar ist welcher Zahlungsweg als gesichert angesehen werden kann (MEWS Terminal, 3DS authentifizierte Online Zahlung), und welche nicht (reine Gatewayzahlung, auch bereits tokenisierter Karten ?).

Wäre toll wenn Mews Mitarbeitern das obige bestätigen könnten bzw. auf eine allgemeine Klarstellung verweisen könnten.

So toll die schnelle und einfache Zahlungsintegration auch ist (hilft auch viele Fehler zu vermeiden, sodass man durchaus auch sagen kann, dadurch dass es so einfach und schnell geht eine Zahlung durchzuführen hat man am Ende des Tages weniger Ärger und Verluste als wenn mal eine Zahlung schief geht...), so toll wäre auch mehr Transparenz welcher Klick welchen Zahlungsweg mit welchen Risiken und Kosten auslöst…

LG,

Jean-Philipp.

Hallo,

Wir haben kürzlich auch einen Fall von "Friendly Fraud" erlebt. Normalerweise überprüfen unsere Rezeptionisten die Originalkarte, wenn sie eine Zahlung über Mews am front desk verarbeiten, um sicherzustellen, dass der Name auf der Karte mit dem Namen in der Reservierung übereinstimmt. In einem speziellen Fall erinnert sich der Mitarbeiter, der beim Check-out anwesend war, dass der Kunde ihn gebeten hatte, die bei der Reservierung angegebene Karte zu belasten, aber er ist sich nicht sicher, ob die Namensüberprüfung korrekt durchgeführt wurde.

Wir haben einen Einspruch gegen die Rückbuchung eingelegt, indem wir die Reservierung des Kunden über booking.com, eine Kopie der Rechnung und das vom Kunden unterschriebene Ankunftsformular (mit Passport Nummer) eingereicht haben.

Leider haben wir den Einspruch verloren, ohne Gründe für diese Entscheidung zu erhalten, und es bleibt uns sogar unklar, ob die Rückbuchung abgelehnt wurde, weil die Karte nicht auf den Namen des Gastes ausgestellt war...

Es wird auch als Debitorenverlust verbucht.

Thomas

Hallo @ChrisHo 

Ich denke es ist hier wichtig zu verstehen, wie die Kreditkarten Acquirer die Situation beurteilen.

Bei folgenden Transaktionen sehen sie die Nachweispflicht / Haftung beim Hotel:
- Ecommerce ohne 2-Faktor-Authentifizierung
- MoTo (Mail Order / Telefon Order)

=> hier ist es sehr schwer, den lückenlosen Nachweis zu erbringen, dass ein Gast wirklich gebucht hat, Chancen zur Verteidigung sind klein

Bei folgenden Transaktionen ist die Nachweispflicht / Haftung beim Gast:
- Ecommerce mit 2-Faktor-Authentifizierung
- Card Present über Terminal

=> hier muss der Gast beweisen, dass er die Transaktion nicht getätigt hat, was sehr schwer ist.


Man sollte daher darauf achten, dass man aus Kreditkartensicherheitsgründen
- bei Hinterlegung und Zahlung einer Kreditkarte immer eine 2FA durchführt
- Zahlungen vor Ort über das Terminal abwickelt

Ob dies mit dem operativen Konzept und technischen Möglichkeiten immer möglich ist, ist eine andere Frage. Hier ist sicherlich wichtig den richtigen Mix aus Guest Experience und administrativen Vorgängen zu finden. Bsp. könnte man den OTA Gästen, welche eine Kreditkarte bei Buchung angegeben haben, einen Bezahllink zusenden, damit sie die Karte nochmals mit 2FA eingeben müssen, und diese nicht einfach ohne 2FA zur automatischen Abbuchung vorgesehen wird.

Viele Grüsse, Marc

 

Hallo @marc agilotel  und @ChrisHo ! Ich wollte / habe schon was ähnliches geschrieben, und bin auf den folgenden Artikel gestoßen: https://help.mews.com/s/article/how-to-make-3ds-authentication-default
 

Wisst Ihr ob 3DS aktuell (zumindest in Europa?) für Zahlungsaufforderungen / Payment Requests aus MEWS heraus automatisch verpflichtend ist, oder von der Bankanforderung abhängig ist? D.h. ist der Artikel noch aktuell und man muss sich ggf. an den Support wenden, oder ist das eh schon wegen PSD2 Standard ?

Ich finde es ist in MEWS aktuell für den Endanwender nicht so klar welche Transaktionen sicher sind (Payment Request / Terminal) und welche nicht (“Charge and Close”, Kartenzahlung mit hinterlegter tokenisierter Karte). Es ist zwar super bequem wenn man Karten einfach so belasten kann, aber man sieht auch nicht ob eine tokenisierte Zahlungskarte halbweges sicher ist (zB beim OnlineCI vom Gast authentifiziert wurde) oder einfach nur die Kartendaten tokenisiert gespeichert sind so wie sie von OTA kommen ohne Verifizierung - das könnte noch ausgebaut werden wenn technisch möglich.

Eine allgemeine Einstellung wonach tokenisierte Karten nur belastet werden können wenn es entweder virutelle Karten sind, oder die zugehörige Reservierung gerade nicht eingecheckt ist, wäre vielleicht denkbar. Denn soweit mir bekannt, darf man nach den MoTo Regeln auch wenn der Gast Kreditkartendaten bekannt gegeben hat via OTA oder sonst wie, diese nicht im MoTo/card_not_present-Verfahren belasten, wenn der Gast schon oder noch vor Ort ist.

Das sollte ja eigentlich nur ein “Notfallverfahren” sein, wenn man etwas nachbelasten muss, oder man (bewusst mit dem Risiko eines Charge-Backs) eine Vorauszahlung abwickelt.

LG, Jean-Philipp.

Hallo @j.spiess 

Man muss bei 3DS unterscheiden zwischen was der Merchant / Integrator anfordert, und was die ausgebende Bank dann damit macht:
- der Integrator (Mews) kann wählen, ob er die Zahlungsanforderung immer mit 3DS anfordert oder nicht
- die ausgebende Bank kann wählen, ob sie (unabhängig von der Anforderung) 3DS erzwingt oder nicht

Sprich es gibt keine Sicherheit, dass auch wenn Mews sie anfordert, dann tatsächlich auch eine durchgeführt wird, aber die Chancen steigen stark. Ebenso gibt es keine Garantie, dass wenn Mews keine anfordert, auch keine durchgeführt wird, die Bank könnte sie trotzdem abfordern.

Ich vermute, dass der Link, den Du geteilt hast, noch aktuell ist.

Pflicht für eine 3DS Anforderung ist natürlich, dass sie durchgeführt wird, wenn der Gast präsent ist (entweder on screen oder in Person), da nur so er seine Identität mit Passwort (Terminal) oder 3DS  Verifizierung (Online) nachweisen kann.

Von daher glaube ich auch nicht, dass man Mews einen Vorwurf machen kann, wenn der OTA eine Karte einfach ohne 3DS annimmt und so durchschickt - wenn die Karte zu Mews kommt, ist der Gast weg vom Screen. Hier müssten meines Erachtens die OTAs eher tätig werden, aber denen ist das eher egal und die Conversion wichtig - und 3DS wirkt Conversion hemmend. Oder man baut einen weiteren Schritt in der Guest Journey ein, und fordert über Payment Link eine Authorisierung der Karte an.

Der Hinweis auf die MoTo Transaktionen ist meines Erachtens richtig, obwohl ich nicht sicher bin, ob es eine harte Regel ist oder einfach nur Best Practice. So oder so ist aber eine MoTo Transaktion immer in Haftung des Hotels - sprich wenn der Gast sie bestreitet, sieht es schlecht aus. Beim Terminal ist es umgekehrt, von daher immer zu bevorzugen, wenn der Gast vor einem steht.

VG, Marc