Wstęp
Metoda płatności stosowana w obsłudze pokoju hotelowego nie przypomina standardowej kasy w sklepie internetowym.
Sklep internetowy prosi klienta o zapłatę za stały koszyk i natychmiast zamyka cykl. W hotelach jest większy bałagan. Opłaty za room service często stają się częścią konta gościa, systemy restauracyjne prowadzą własne rejestry transakcji, napiwki mogą zmieniać ostateczną kwotę, a anulowanie lub korekta zamówienia następuje już po jego złożeniu.
Proces płatności musi być dostosowany zarówno do doświadczeń gości, jak i do sposobu funkcjonowania hotelu.
W Appricotsoft mniej więcej tak myślimy o oprogramowaniu dla branży hotelarskiej: interfejs to tylko jeden element produktu. Prawdziwym testem jest to, czy oprogramowanie upraszcza i ułatwia zespołom zarządzanie podstawowymi procesami, a nie tylko sprawia, że interfejs jest bardziej estetyczny.
Naszym celem jest oprogramowanie, które jest użyteczne i rozwiązuje realny problem. Oto najważniejsze decyzje dotyczące płatności.
Dlaczego obsługa płatności ma znaczenie w aplikacji do obsługi pokoju
Zamówienie obsługi pokoju powinno być proste.
Gość otwiera aplikację hotelową, wybiera kolację, dodaje napój, ustawia napiwek i klika “Zamów”. Z jego strony proces płatności powinien zająć kilka sekund.
Za tym przyciskiem kryje się kilka systemów, które muszą uzgodnić, co się właśnie wydarzyło. Hotel zazwyczaj musi:
- Zweryfikuj gościa i pokój
- Dodaj zakup do folio pokoju
- Przetwarzaj płatność kartą
- Obsługuj autoryzację wstępną
- Dodaj lub dostosuj napiwek
- Podziel rachunek pomiędzy metodami płatności
- Wyślij zamówienie do POS-u lub kuchni
- Rejestruj zwroty i anulowania
- Dopasuj transakcję do rozliczeń procesora płatności
- Uzgodnienie kwoty końcowej z systemem PMS, POS i systemem księgowym
Wiele zależy od jednego kliknięcia. Płatności muszą być traktowane jako podstawowy proces podczas tworzenia aplikacji do zamawiania usług hotelowych w pokojach, a nie dodane jako ekran płatności na końcu.
Jeśli zrobisz to dobrze, zamówienie będzie dla gościa niewidoczne, a dział finansowy, recepcja, gastronomia i dział wsparcia nadal będą mieli wiarygodny zapis każdej transakcji. Jeśli zrobisz źle, dowiesz się o tym w pracowity weekend, od rozgniewanego gościa lub jeszcze bardziej rozgniewanego księgowego.
Jeśli rozważasz zamawianie cyfrowe w szerszym zakresie, nasz przewodnik po integracja zamawiania jedzenia i udogodnień w aplikacji to dobry punkt wyjścia dla całościowego doświadczenia gości. Wskazówki Appricotsoft dotyczące branży hotelarskiej wskazują również zintegrowane płatności, naliczanie opłat za pokoje, karty i programy lojalnościowe jako podstawowe funkcje obsługi pokoju, a nie dodatki.
Podstawowe opcje płatności dla aplikacji do zamawiania usług pokojowych w hotelach
1. Opłata za pokój
W większości hoteli opłata za pokój jest naturalną metodą płatności za room service. Zamiast wpisywać dane karty, gość potwierdza zakup, a kwota trafia na jego konto hotelowe lub do folio.
Na ekranie wygląda to prosto: wybierz produkty, wybierz opcję “Zapłać za pokój”, potwierdź i złóż zamówienie.
Poniżej znajduje się lista rzeczy, które aplikacja musi najpierw sprawdzić:
- Czy gość jest obecnie zameldowany?
- Czy pokój pozwala na zamieszczanie postów?
- Czy ten gość jest uprawniony do pobierania opłat za usługi w tym pokoju?
- Czy istnieje odpowiednia gwarancja zapłaty za pobyt?
- Które folio powinno zostać obciążone?
- Co się stanie, jeśli PMS odrzuci ogłoszenie?
To ostatnie pytanie jest ważniejsze, niż się wydaje. Aplikacja nigdy nie powinna informować gościa o pomyślnym pobraniu zamówienia, jeśli księgowanie w systemie PMS nie powiodło się. W zależności od modelu operacyjnego hotelu, system może wymagać ponownej próby, skierowania transakcji do ręcznej weryfikacji lub poproszenia gościa o inną metodę płatności.
W tym miejscu integracja PMS i logika płatności zaczynają się przenikać. Gość widzi tylko jeden, przejrzysty wynik. Personel hotelu potrzebuje pełnej historii transakcji.
2. Zapłać kartą
Niektórzy goście wolą zapłacić bezpośrednio, niż dodać zamówienie do swojego pokoju. Może to oznaczać zapisaną kartę, nową kartę, Apple Pay lub Google Pay albo inną metodę obsługiwaną przez dostawcę usług hotelowych.
Płatności kartą są najważniejsze w przypadku obiektów przyjmujących zamówienia od gości, którzy nie mają możliwości doliczenia opłaty za pokój lub chcą, aby wydatki na posiłki i napoje były rozliczane oddzielnie od rachunku za pobyt.
Proces płatności nadal musi być krótki. Proszenie kogoś o podanie danych do płatności przy każdym zamówieniu kawy mija się z celem aplikacji.
W zależności od architektury płatności, hotele mogą korzystać z hostowanych komponentów płatności, mobilnych zestawów SDK, kart tokenizowanych lub integracji po stronie serwera. Wybór odpowiedniej opcji zależy od wymagań UX, możliwości dostawcy, zakresu zgodności oraz systemów, z których korzysta obiekt. Więcej informacji na ten temat znajdziesz w naszym poradniku dotyczącym integracji hostowanych, API i bramek płatności w aplikacji.
Jedna zasada obowiązuje niezależnie od wszystkiego: Nie przetwarzaj poufnych danych karty, chyba że jest to absolutnie konieczne. Pozwól bezpiecznym komponentom dostawcy płatności przechowywać dane karty i zadbaj o to, aby Twoja aplikacja hotelowa działała dzięki tokenom i referencjom.
3. Płatności podzielone
Podzielone płatności mogą wydawać się mało przydatnym udogodnieniem, dopóki nie spróbuje się ustalić konkretnych zasad.
Dwóch gości dzieli pokój. Zamówienie wynosi 90 euro. Jeden chce doliczyć 40 euro do rachunku za pokój, drugi chce zapłacić 50 euro kartą. A może wolą podzielić to równo na dwie karty.
Twoja aplikacja potrzebuje jasnych zasad w następujących przypadkach:
- Opłata za pokój plus karta
- Dwie karty
- Karta kredytowa Plus na prezent lub lojalność
- Voucher plus opłata za pokój
- Częściowa płatność, a następnie druga metoda
A potem trudniejsze pytanie: co się stanie, jeśli pierwsza część się powiedzie, a druga nie?
Załóżmy, że €40 zostało pomyślnie wysłane do pokoju, ale transakcja kartą €50 została odrzucona. Aplikacja potrzebuje tutaj zdefiniowanego stanu, a nie tylko “Płatność nieudana”.” Kilka opcji:
- Zachowaj część, która Ci się udała i poproś o inną metodę na wypłatę salda
- Anuluj pierwszą płatność i rozpocznij ponownie realizację zamówienia
- Wstrzymaj zamówienie, aż personel rozwiąże problem
- Pozwól recepcji ręcznie dokończyć płatność
Nie ma uniwersalnej odpowiedzi. To zależy od polityki hotelu i możliwości systemu PMS, POS i dostawcy płatności. Dlatego płatności podzielone muszą być zaprojektowane jako przepływ pracy, a nie tylko jako przełącznik w interfejsie użytkownika.
4. Napiwki i gratyfikacje
Napiwki stanowią kolejny aspekt sprawy, ponieważ ostateczna kwota może zależeć od tego, kiedy gość zdecyduje się dać napiwek.
Aplikacja do obsługi pokoju może oferować sugestie procentowe (10%, 15%, 20%), ustaloną kwotę lub w ogóle nie dawać napiwku – i pozwól gościowi wybrać odpowiednią opcję podczas realizacji transakcji lub po dostarczeniu przesyłki.
Napiwek powinien być zawsze dobrowolny i wyraźnie oddzielony od sumy częściowej, podatków, opłat za obsługę i opłat za dostawę. Proste rozbicie na części działa:
Jedzenie: 42 €
Opłata za dostawę: 4 €
Napiwek: 6 €
Razem: 52 €
Taka przejrzystość pomaga gościom, a także temu, kto później uzgadnia liczby.
Istnieje również istotna różnica techniczna między dodaniem napiwku przed płatnością a dodaniem go później. Jeśli gość wybierze napiwek przed autoryzacją, pełna kwota zazwyczaj mieści się we wniosku o płatność. Jeśli zostanie dodany później, dostawca płatności musi obsługiwać korektę autoryzacji, przekroczenie limitu lub podobny proces naliczania napiwków – Stripe dokumentuje to w swoich procesach naliczania napiwków., Adyen w swoich dokumentach dotyczących wstępnej autoryzacji w branży hotelarskiej, i dostępność zależy od metody płatności, regionu i zasad dostawcy.
Zasady biznesowe są równie ważne:
- Kto otrzymuje napiwek?
- Czy jest on przypisany do osoby czy zespołu?
- Jak to wygląda w POS-ie?
- Jak raportuje to dział finansowy?
- Co się stanie z napiwkiem w przypadku zwrotu zamówienia?
- Czy można to zmienić po porodzie?
Zdecyduj o tym przed rozpoczęciem prac. Mają one wpływ na dane transakcyjne i raportowanie długo po uruchomieniu.
5. Autoryzacja wstępna
Preautoryzacja ma ogromne znaczenie w branży hotelarskiej. Zamiast od razu obciążać kartę, system rezerwuje określoną kwotę i pobiera odpowiednią kwotę później.
Stripe obsługuje ręczne i opóźnione przechwytywanie; Adyen obsługuje preautoryzację, a następnie korektę autoryzacji i przechwytywanie. Oba rozwiązania zostały stworzone właśnie do tego typu zastosowań.
W przypadku obsługi pokoju, przedautoryzacja jest przydatna, gdy zamówienie może ulec zmianie przed jego realizacją, zostaną dodane dodatkowe pozycje, ostateczna kwota napiwku nie jest jeszcze znana lub hotel chce potwierdzić dostępność środków przed rozpoczęciem gotowania w kuchni.
Ale autoryzacja to nie rozliczenie, a to rozróżnienie musi być widoczne w statusach płatności. Proste przełączanie między opcjami “Zapłacono/Niezapłacono” nie wystarczy. Lepszy model wygląda tak:
- Płatność zainicjowana
- Oczekiwanie na autoryzację
- Upoważniony
- Przechwytywanie w toku
- Złapany
- Częściowo schwytany
- Przegrany
- Odwołany
- Zwrot oczekujący
- Zwrócono
Goście nie muszą tego wszystkiego widzieć. Zazwyczaj widzą to pracownicy działu operacyjnego i wsparcia.
Status płatności powinien odpowiadać statusowi zamówienia
Jedno z ważniejszych zadań projektowych: zachować spójność cyklu zamówienia i cyklu płatności, nie udając, że są tym samym.
Wyobraź sobie taką sekwencję: gość składa zamówienie, karta zostaje autoryzowana, kuchnia przyjmuje zamówienie, jedzenie zostaje przygotowane, zamówienie dostarczone, ostateczna kwota pobrana. To tak naprawdę dwa równoległe tory biegnące obok siebie.
Zamówienie: Wysłano → Zaakceptowano → Przygotowywanie → Wysłano do doręczenia → Dostarczono
Zapłata: Zainicjowano → Autoryzowano → Przechwycono → Rozliczono
Jeśli Twój system przechowuje tylko informację “zamówienie zrealizowane”, tracisz dane finansowe. A gdy coś się zepsuje – na przykład jedzenie dotrze, ale ostateczne przechwycenie zamówienia się nie powiedzie – personel musi dokładnie zobaczyć, gdzie transakcja się zatrzymała, a nie zgadywać.
Rozliczenie: kiedy pieniądze faktycznie się przemieszczają
Pomyślna odpowiedź na żądanie płatności nie oznacza, że pieniądze znajdują się już na koncie bankowym hotelu. Transakcje kartowe przechodzą przez proces autoryzacji, przechwytywania, przetwarzania i rozliczenia – każdy z nich to osobny etap z własnymi trybami awaryjnymi.
Platforma obsługi pokoju musi gromadzić odniesienia, aby móc śledzić cały cykl życia, takie jak:
- Wewnętrzny identyfikator zamówienia
- Identyfikator nieruchomości
- Numer pokoju lub odniesienie do folio
- Identyfikator transakcji POS
- Odniesienie do postu PMS
- Identyfikator transakcji dostawcy płatności
- Kwota autoryzacji
- Przechwycona kwota
- Wskazówka
- Kwota zwrotu
- Waluta
- Status płatności
- Numer referencyjny rozliczenia
Nic z tego nie jest efektowne. To właśnie to decyduje o tym, czy produkt pozostanie łatwy w obsłudze, gdy wolumen transakcji wzrośnie, a nie zamieni się w koszmar arkusza kalkulacyjnego po sześciu miesiącach.
Uzgadnianie: kiedy dobra architektura płatności się opłaca
W końcu dział finansów za każdym razem zadaje to samo bezpośrednie pytanie: czy liczby się zgadzają?
Załóżmy, że wczorajsze zapisy pokazują 6200 euro ze sprzedaży room service, 3900 euro doliczone do rachunków za pokoje i 2300 euro zapłacone bezpośrednio kartą. Operator płatności zgłasza przechwycone 2270 euro, ponieważ 30 euro zostało zwrócone. Terminal POS pokazuje 6200 euro. System PMS pokazuje 3900 euro w opłatach folio.
Proces uzgadniania powinien sam wyjaśnić tę lukę, bez konieczności ręcznego porównywania setek paragonów. Oznacza to porównywanie transakcji w aplikacji room service, POS, PMS, u dostawcy płatności i raportowaniu rozliczeń – dokładny łańcuch zależy od obiektu.
Wyjątki powinny pojawiać się w interfejsie administratora lub raporcie, a nie być wykrywane przypadkowo:
- Zamówienie istnieje, ale nie ma płatności
- Płatność istnieje, ale nie ma zamówienia POS
- Karta została autoryzowana, ale nigdy nie została przechwycona
- Nie udało się wysłać PMS
- Zgromadzona kwota nie zgadza się z całkowitą kwotą zamówienia
- Zwroty istnieją w jednym systemie, ale nie w innym
- Wykryto duplikat transakcji
- Waluta rozliczeniowa nie odpowiada oczekiwanej
Te wyjątki to transakcje warte zbadania. Tysiące poprawnie dopasowanych transakcji nie stanowią problemu.
Zwroty i anulowania wymagają własnych zasad
Obsługa pokoju stwarza własne, skrajne przypadki. Gość anuluje zamówienie, zanim kuchnia je przyjmie. Albo po rozpoczęciu przygotowywania. Hotel zwraca pieniądze za spóźnione danie. Kierownik rezygnuje z opłaty w geście dobrej woli.
Każdy z nich ma inny wynik finansowy:
- Przed przygotowaniem: anuluj autoryzację lub cofnij księgowanie pokoju
- Po przygotowaniu: polityka może ograniczyć anulowanie do zatwierdzenia przez menedżera
- Częściowy problem z usługą: zwróć jeden przedmiot, a resztę zamówienia pozostaw opłaconą
- Pełna obsługa odzyskiwania: zwróć zamówienie i ewentualnie napiwek
Aplikacja nie może pozwolić na utratę synchronizacji systemów finansowych tylko dlatego, że zmienił się status zamówienia. Przycisk “Anuluj zamówienie” może wymagać uruchomienia kilku akcji w tle, a wszystkie z nich muszą zostać faktycznie uruchomione.
Narzędzia administracyjne są częścią produktu płatniczego
Dopracowany system płatności dla gości ze słabymi narzędziami back-office'owymi po prostu przenosi problem na personel. Administracyjna strona aplikacji room service powinna umożliwiać upoważnionym pracownikom sprawdzanie transakcji bez angażowania programisty do przeszukiwania bazy danych.
W zależności od obiektu, personel może być zobowiązany do:
- Szukaj według zamówienia, pokoju, daty lub identyfikatora transakcji
- Zobacz pełny harmonogram płatności
- Zidentyfikuj metodę płatności
- Przejrzyj referencje PMS i POS
- Zobacz kwoty autoryzacji i przechwytywania
- Wystawianie lub żądanie zwrotów pieniędzy
- Przejrzyj napiwki
- Wyjątki dotyczące uzgadniania punktowego
- Dodaj notatkę wewnętrzną
- Zobacz, który pracownik dokonał korekty
Dostęp powinien być oparty na rolach. Pracownik kuchni nie potrzebuje uprawnień do zwrotu pieniędzy. Kierownik finansowy nie musi zmieniać statusu przygotowania. Rozdzielenie tych ról jest korzystne dla bezpieczeństwa i ułatwia pracę wszystkim.
Jak Appricotsoft podchodzi do przepływów płatności za obsługę pokoju
Nie zaczęlibyśmy od pytania “Którą bramkę płatności powinniśmy zintegrować?” Najpierw musielibyśmy zbadać, w jaki sposób hotel faktycznie przyjmuje i rozlicza pieniądze. Oznacza to zrozumienie:
- Opcje płatności dla gości – jakie metody powinien zobaczyć gość i na jakich warunkach?
- Istniejące systemy hotelowe – które systemy PMS, punkty sprzedaży, dostawcy płatności, narzędzia księgowe i inne integracje są już wdrożone?
- Własność transakcji – który system jest źródłem prawdy dla zamówienia, płatności, opłaty za pokój, napiwku, zwrotu pieniędzy i rozliczenia?
- Przepływ pracy wyjątku – co się dzieje, gdy publikowanie, autoryzacja, przechwytywanie, zwrot pieniędzy lub synchronizacja się nie powiedzie?
- Pojednanie – w jaki sposób zespoły hotelowe udowodnią, że zrealizowane zamówienia i dokumentacja finansowa faktycznie się zgadzają?
Następnie projektujemy wokół rzeczywistego przepływu pracy, zamiast zmuszać personel hotelu do dostosowywania się do standardowego systemu płatności. Ta sama zasada leży u podstaw naszego modelu dostaw Unison: klient ma priorytety i podejmuje decyzje, nasz zespół odpowiada za myślenie o produkcie i jego realizację, a sztuczna inteligencja pomaga nam działać szybciej, podczas gdy ludzie pozostają odpowiedzialni za wynik. Cotygodniowe demonstracje, współdzielone artefakty projektu, jawne wywołania zakresu, testy i kontrole wersji zapewniają przejrzystość dostaw, zamiast zamieniać je w czarną skrzynkę.
W szczególności w przypadku funkcji płatności ta widoczność ma znaczenie. Pozwala ona interesariuszom hotelu na wczesne testowanie rzeczywistych scenariuszy – obciążanie pokoju zamówieniem testowym, płacenie kartą, dodawanie napiwku, dzielenie płatności, symulowanie odrzucenia, anulowanie autoryzacji, dokonywanie częściowego zwrotu, wywoływanie błędu księgowania w systemie PMS, potwierdzanie rozliczeń i uzgadnianie.
Znalezienie luki w trakcie kontrolowanej wersji demonstracyjnej kosztuje znacznie mniej niż znalezienie jej poprzez skargę gościa po premierze.
Typowe błędy, których należy unikać
Nawet solidne produkty z branży hotelarskiej mogą napotkać problemy, gdy procesy płatności staną się zbyt uproszczone. Zwróć uwagę na:
- Traktowanie “pomyślnej autoryzacji” jako “płatność w pełni uregulowana”
- Budowanie obciążenia pokoju bez obsługi nieudanych księgowań PMS
- Dodawanie podzielonych płatności bez definiowania zachowania częściowej awarii
- Dodawanie napiwków bez decydowania o tym, jak będą one przedstawiane w raportach finansowych i pracowniczych
- Przechowywanie wyłącznie ogólnego statusu “zapłacone”
- Zapomnienie o synchronizacji zwrotu i anulowania
- Nie udostępniając personelowi operacyjnemu narzędzi do wyszukiwania transakcji ani audytu
- Wymaganie ręcznego uzgadniania w przypadku rutynowych transakcji
- Tworzenie procesu wymeldowania gościa przed mapowaniem istniejącego procesu płatności w hotelu
Większość z nich wynika z niekompletnego procesu. Bramka płatności rzadko stanowi faktyczny problem.
Często zadawane pytania
Czy aplikacja do obsługi pokoi powinna obsługiwać zarówno płatności kartą, jak i opłaty za pokój?
W większości hoteli tak. Płatność za pokój naturalnie pasuje do gości zameldowanych, a bezpośrednie płatności kartą zapewniają elastyczność. Wybór metody płatności zależy od modelu operacyjnego obiektu i istniejących systemów.
Czy opłata za pokój oznacza, że karta gościa zostanie obciążona natychmiast?
Niekoniecznie. Opłata jest często dopisywana do rachunku gościa i rozliczana później jako część całego pobytu.
Czy goście powinni mieć możliwość dzielenia płatności za obsługę pokoju?
Może się to opłacić, zwłaszcza w przypadku pobytów współdzielonych i grupowych. Hotel potrzebuje jednak zasad dotyczących częściowych awarii, zwrotów kosztów i uzgadniania przed wprowadzeniem usługi – a nie po jej wprowadzeniu.
Kiedy aplikacja powinna poprosić o napiwek?
Przy kasie lub po obsłudze, w zależności od konfiguracji. Właściwy wybór zależy od doświadczeń gości, norm regionalnych i faktycznej obsługi operatora płatności.
Dlaczego warto korzystać z preautoryzacji?
Potwierdza dostępność środków, umożliwiając przechwycenie ich później. Stripe i Adyen dokumentują schematy autoryzacji i przechwytywania stworzone z myślą o branży hotelarskiej, choć dokładne możliwości różnią się w zależności od dostawcy i metody płatności.
Czy hotele potrzebują automatycznego uzgadniania?
Im więcej transakcji i nieruchomości jest zaangażowanych, tym bardziej się opłaca. Automatyczne dopasowywanie pozwala zespołom skupić się na niezgodnościach, zamiast sprawdzać każdą transakcję ręcznie.
Jakie integracje są zazwyczaj przeprowadzane?
W zależności od obiektu: PMS, POS, bramka płatności, platforma księgowa, system lojalnościowy i narzędzia raportowania. Produkty hotelowe rzadko działają w izolacji – są częścią szerszego systemu.
Wniosek
Najlepsze doświadczenie związane z płatnością za room service to takie, na które gość tak naprawdę nie zwraca uwagi. Wybiera, co chce, wybiera sposób płatności, ewentualnie dodaje napiwek, potwierdza i wraca do swojego wieczoru. Cała złożoność pozostaje za ekranem, tam gdzie jej miejsce.
Solidna aplikacja do obsługi pokoju hotelowego traktuje opłaty za pokój, karty, płatności dzielone, napiwki, preautoryzację, zwroty, rozliczenia i uzgadnianie jako jeden proces, a nie jako dodane na końcu procesu płatności wymeldowanie. Oznacza to decydowanie, gdzie rejestrowana jest każda transakcja, który system odpowiada za każdy stan finansowy, jak obsługiwane są wyjątki i jak zespoły hotelowe potwierdzają, że kwota faktycznie odpowiada zamówieniu.
To właśnie tego typu problemy lubimy rozwiązywać w Appricotsoft. Łączymy tworzenie aplikacji hotelowych, integrację płatności, integrację systemów, UI/UX, zapewnienie jakości i myślenie o produktach hotelarskich, tak aby oprogramowanie działało zarówno dla gościa trzymającego telefon, jak i dla zespołu zarządzającego obiektem.
Ładny przycisk “Zapłać” to nic trudnego. System płatności, któremu goście, dział operacyjny i dział finansowy mogą zaufać, wymaga więcej pracy – ale to właśnie ta część jest naprawdę solidna.
Jeśli planujesz wdrożenie aplikacji do zamawiania usług room service w hotelu, aplikacji do obsługi gości w szerszym zakresie lub platformy hotelarskiej z integracją płatności, możemy pomóc Ci zaplanować przepływ pracy, zanim podejmiesz kosztowne decyzje.
