Platforma Actions Center obsługuje różne konfiguracje przyjmowania płatności. Przewodnik po włączaniu płatności zawiera informacje o aspektach integracji, które są wspólne dla wszystkich integracji płatności, w tym:
- Konfigurowanie plików danych pod kątem uwzględniania informacji
tokenization_parameter - Aktualizowanie serwera rezerwacji w celu akceptowania obiektów
payment_method_token - Omówienie informacji wymienianych między użytkownikiem, Centrum działań, partnerem / sprzedawcą i procesorem płatności.
W tym przewodniku szczegółowo opisujemy, jak skonfigurować pliki danych, aby określić, który z różnych typów konfiguracji płatności jest odpowiedni dla Twoich sprzedawców i usług.
- Brak płatności / Płatność po przyjeździe
- Pełna przedpłata
- Opłata za niestawienie się / opłata za anulowanie
- Wpłata
Wszystkie przypadki użycia płatności są rozszerzeniami przypadku użycia bez płatności lub płatności przy odbiorze (które nie wymagają konfiguracji płatności), więc ten samouczek zacznie się od opisu tej konfiguracji, a inne konfiguracje będą traktowane jako rozszerzenia.
Każda sekcja będzie zawierać informacje o polach, które należy śledzić na serwerze rezerwacji, aby zaakceptować daną konfigurację płatności.
Brak płatności / Płatność po przyjeździe
W przypadku usług, które nie wymagają płatności w momencie rezerwacji, nie trzeba konfigurować płatności na poziomie sprzedawcy lub usługi. Nadal jednak wymagane są ceny.
Jest to konfiguracja podstawowa usługi, która zawiera nazwę, opis i cenę. To będzie jedna wiadomość usługi w ramach
ServiceFeed:
{ "merchant_id": "merchant-1", "service_id": "service-1-a", "name": "Men's haircut", "description": "One of our stylists will cut your hair", "price": { "price_micros": 15000000, "currency_code": "USD" } }
Aby umożliwić płatność przy zakwaterowaniu, nie trzeba nic konfigurować na serwerze rezerwacji poza standardową implementacją.
Przedpłata
Ta konfiguracja służy do określenia, że kwota za usługę musi zostać w całości zapłacona w momencie rezerwacji.
Płatność z góry jest określana na poziomie usługi za pomocą pola prepayment_type w Service. Aby wymagać płatności za usługę, ustaw tę wartość na REQUIRED, jak w przykładzie poniżej. Pamiętaj, że cena jest określana w taki sam sposób jak w przykładzie płatności przy odbiorze. Tutaj,
ponieważ ustawiamy typ przedpłaty na wymagany, będziemy prosić o podanie danych karty kredytowej, a cena zostanie naliczona w momencie płatności.
{ "merchant_id": "merchant-1", "service_id": "service-2-b", "name": "Spa Treatment", "description": "A full spa treatment", "price": { "price_micros": "200000000", "currency_code": "USD" } "prepayment_type": "REQUIRED" }
Serwer rezerwacji
Podczas akceptowania przedpłat token płatności jest przekazywany do serwera rezerwacji w wywołaniu do CreateBooking za pomocą pola payment_processing_parameters.unparsed_payment_method_token.
Musisz pobierać dokładnie taką kwotę, jaka została określona w polu ceny w plikach danych, oraz używać waluty określonej w plikach danych. Te opłaty powinny być naliczane zgodnie z procedurą opisaną w przewodniku dotyczącym włączania płatności.
W przypadku zwrotu
CreateBookingResponse
pole booking.payment_information musi być prawidłowo ustawione, aby odzwierciedlać, że wpłata została przesłana i przetworzona.
Specyfikacja PaymentInformation zawiera pełną dokumentację wszystkich opcji informacji o płatnościach. Poniżej znajdziesz minimalny przykład przetwarzania przedpłaty. Ważne jest, aby cena zwrócona w polu „price” była dokładnie taka sama jak podana w żądaniu. Jeśli w plikach danych lub żądaniu podany jest współczynnik podatkowy, musi on być również uwzględniony w dokładnej postaci.
Pamiętaj też, że musisz podać identyfikator transakcji. Identyfikator transakcji musi być co najmniej unikalny wśród transakcji z tym sprzedawcą. Dobrym kandydatem na identyfikator transakcji jest identyfikator transakcji dostarczony przez firmę obsługującą płatności.
{ "prepayment_status": "PREPAYMENT_PROVIDED", "payment_processed_by": "PROCESSED_BY_PARTNER", "payment_transaction_id": "[this-transaction-id]", "price": { "price_micros": "200000000", "currency_code": "USD" } }
Opłata za niestawienie się
Użytkownik może zostać obciążony opłatą za niestawienie się, jeśli nie stawił się na rezerwację lub anulował ją po upływie okresu anulowania. Jeśli nie podasz przedziału czasu anulowania, zostanie on domyślnie ustawiony na czas rozpoczęcia danego przedziału.
Aby określić opłatę za brak reakcji, w pliku danych usługi dodaj pole no_show_fee, jak pokazano w przykładzie poniżej:
{ "merchant_id": "merchant-1", "service_id": "service-2-b", "name": "Spa Treatment", "description": "A full spa treatment", "price": { "price_micros": 200000000, "currency_code": "USD" } "scheduling_rules": { "min_advance_online_canceling": 14400, } "no_show_fee": { "fee": { "price_micros": 25000000, "currency_code": "USD" } "fee_type": "FIXED_RATE_DEFAULT" } }
W przykładzie powyżej partner lub sprzedawca może naliczać opłatę w stałej wysokości 25 USD, jak określono w polu no_show_fee.fee.price_micros, jeśli właściciel spotkania nie stawi się na spotkanie. Ta opłata może zostać pobrana również wtedy, gdy użytkownik anuluje rezerwację w ciągu 4 godzin (14 400 sekund) przed jej rozpoczęciem, zgodnie z tym, co zostało określone w polu scheduling_rules.min_advance_online_canceling.
Aby dowiedzieć się, jak zdefiniować opłaty za brak wyświetleń na poziomie dostępności, zapoznaj się z tą sekcją.
Serwer rezerwacji
Podczas przetwarzania żądania, które obejmuje opłatę za brak rezerwacji, token płatności jest przekazywany do serwera rezerwacji w wywołaniu CreateBooking za pomocą pola payment_processing_parameters.unparsed_payment_method_token.
Ten token jest przekazywany w taki sam sposób jak w przypadku przedpłaty. Ponieważ jednak token jest autoryzowany tylko przez krótki czas, musisz wywołać odpowiedni interfejs API swojego procesora płatności, aby uaktualnić ten token do wersji, którą możesz zachować do późniejszego użycia. Informacje na ten temat znajdziesz w sekcji dotyczącej włączania płatności w przewodniku Proces tworzenia tokenów opłat za brak pokazu.
W przypadku zwracania obiektu CreateBookingResponse pole booking.payment_information musi być ustawione w taki sposób, aby prawidłowo odzwierciedlał stan opłaty za niestawienie się, jak w przykładzie poniżej.
{ "prepayment_status": "PREPAYMENT_PROVIDED", "payment_processed_by": "PROCESSED_BY_PARTNER", "payment_transaction_id": "[this-transaction-id]", "price": { "price_micros": "200000000", "currency_code": "USD" } "no_show_fee": { "fee": { "price_micros": 25000000, "currency_code": "USD" } "fee_type": "FIXED_RATE_DEFAULT" } }
Pamiętaj, że element no_show_fee jest ustawiony tak, aby odzwierciedlał cenę i strukturę opłaty, która może zostać naliczona. Pamiętaj też, że podobnie jak w przypadku płatności z góry w tym komunikacie wymagany jest parametr transaction_id.
Pamiętaj też, że booking_id ustawione w CreateBookingResponse jest wymagane w przypadku aktualizacji w czasie rzeczywistym, które muszą być wysyłane podczas pobierania opłaty za niestawienie się. Ten identyfikator powinien być przechowywany razem z informacjami dotyczącymi rezerwacji.
Aktualizacje w czasie rzeczywistym
Jeśli użytkownik nie pojawi się na zaplanowanej rezerwacji lub anuluje rezerwację po upływie terminu anulowania (np. kontaktując się bezpośrednio z Tobą), możesz opcjonalnie obciążyć go określoną opłatą za niestawienie się, korzystając z informacji o płatności zapisanych w momencie rezerwacji. Jeśli pobierasz opłatę za niestawienie się, musisz wysłać aktualizację w czasie rzeczywistym, w której określasz, że została naliczona opłata za niestawienie się.
W przypadku rezerwacji utworzonych przez CreateBooking należy wysłać aktualizację na adres notification.partners.bookings.patch. W treści prośby należy podać zaktualizowaną rezerwację ze stanem NO_SHOW_PENALIZED. Ten stan informuje Google, że obciążenie zostało dokonane.
Prośbę można wysłać na przykład do:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
W treści żądania:
{ "name": "partners/12345678/bookings/123123123" "merchantId": "merchant-1" "serviceId": "service-2-b" "status": "NO_SHOW_PENALIZED" }
Wpłata
Depozyty są używane do pobierania początkowej opłaty jako wymagania dotyczące rezerwacji. Depozyty mogą być pobierane w momencie rezerwacji lub później. Może być konieczne określenie warunków zwrotu depozytu, a także kiedy rezerwacja może zostać anulowana online.
Aby określić depozyt, w pliku danych o usłudze należy uwzględnić pole deposit, jak pokazano w przykładzie poniżej:
{ "merchant_id": "merchant-1", "service_id": "service-2-b", "name": "Spa Treatment", "description": "A full spa treatment", "price": { "price_micros": 200000000, "currency_code": "USD" } "scheduling_rules": { "min_advance_online_canceling": 86400, } "deposit": { "deposit": { "price_micros": 25000000, "currency_code": USD, "min_advance_cancellation_sec": 14400, } "deposit_type": "FIXED_RATE_DEFAULT" } }
W tym przykładzie parametr min_advance_online_canceling określa okres, w którym można anulować rezerwację, a parametr deposit.min_advance_cancellation_sec określa, kiedy można zwrócić depozyt. Pamiętaj, że w przykładzie powyżej depozyt może określać czas na anulowanie niezależnie od warunków zwrotu środków. W takim przypadku użytkownik będzie mógł anulować usługę online do 24 godzin (86 400 sekund) przed terminem. Dzięki temu sprzedawca będzie bezpośrednio informowany o wszelkich późnych anulowaniach. Użytkownik może jednak nadal otrzymać zwrot depozytu do 4 godzin (14 400 sekund) przed rezerwacją (poprzez skontaktowanie się z Tobą lub sprzedawcą w celu anulowania rezerwacji). Informacje te będą widoczne w warunkach podczas płatności i w e-mailu z potwierdzeniem.
Informacje o tym, jak można definiować depozyty na poziomie dostępności, znajdziesz w tej sekcji.
Serwer rezerwacji
Podczas przetwarzania żądania, które obejmuje wpłatę zaliczki, token płatności jest przekazywany do Twojego serwera rezerwacji w wywołaniu do CreateBooking za pomocą pola payment_processing_parameters.unparsed_payment_method_token.
Ten token jest przekazywany w taki sam sposób jak w przypadku przedpłaty. Jeśli chcesz obciążyć depozytem lub anulować blokadę w momencie rezerwacji, możesz to zrobić podczas składania prośby.
Jeśli zamierzasz obciążyć depozyt w późniejszym terminie, ponieważ token jest autoryzowany tylko przez krótki czas, musisz wywołać odpowiedni interfejs API swojego procesora płatności, aby zaktualizować ten token do wersji, którą możesz zachować do użycia w późniejszym terminie. Opis tej procedury znajdziesz w sekcji przewodnika Włączanie płatności poświęconej przepływowi tokena depozytu.
W przypadku zwracania CreateBookingResponse pole booking.payment_information musi prawidłowo odzwierciedlać stan depozytu, jak w przykładzie poniżej.
{ "prepayment_status": "PREPAYMENT_PROVIDED", "payment_processed_by": "PROCESSED_BY_PARTNER", "payment_transaction_id": "[this-transaction-id]", "price": { "price_micros": "200000000", "currency_code": "USD" } "deposit": { "deposit": { "price_micros": 25000000, "currency_code": USD, "min_advance_cancellation_sec": 28800, } "deposit_type": "FIXED_RATE_DEFAULT" } }
Pamiętaj, że depozyt jest ustawiany zgodnie z ceną i strukturą depozytu, która zostanie pobrana lub wstrzymana. Pamiętaj też, że podobnie jak w przypadku płatności z góry w tym komunikacie wymagany jest parametr transaction_id.
Aktualizacje w czasie rzeczywistym
Jeśli użytkownik anuluje rezerwację przed upływem terminu anulowania zaliczki, musisz zwrócić zaliczkę pobrana z karty użytkownika. W przypadku zwrotu depozytu musisz wysłać aktualizację w czasie rzeczywistym, w której określisz, że depozyt został zwrócony.
W przypadku rezerwacji utworzonych przez CreateBooking należy wysłać aktualizację na adres notification.partners.bookings.patch. W treści tego żądania powinna znajdować się zaktualizowana rezerwacja ze stanem CANCELED i polem paymentInformation.prepaymentStatus ustawionym na PREPAYMENT_REFUNDED. Informuje Google, że depozyt został zwrócony.
Prośbę można wysłać na przykład do:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
W treści żądania:
{ "name": "partners/12345678/bookings/123123123" "merchantId": "merchant-1" "serviceId": "service-2-b" "status": "CANCELED" "paymentInformation": { "prepaymentStatus": "PREPAYMENT_REFUNDED" } }
Wymaganie karty kredytowej
Usługa może wymagać karty kredytowej jako dodatkowego potwierdzenia tożsamości użytkownika. Nie należy ich jednak używać do przedpłat, wpłat zaliczkowych ani opłat za brak stawienia się. Jeśli te przypadki użycia są wymagane, należy je skonfigurować, wykonując czynności opisane powyżej. Pamiętaj też, że wymaganie karty kredytowej często prowadzi do znacznego spadku liczby rezerwacji tej usługi.
Aby wymagać podania danych karty kredytowej podczas płatności, musisz ustawić pole require_credit_card na REQUIRE_CREDIT_CARD_ALWAYS.
{ "merchant_id": "merchant-1", "service_id": "service-1-a", "name": "Men's haircut", "description": "One of our stylists will cut your hair", "price": { "price_micros": 15000000, "currency_code": "USD" }, "require_credit_card": "REQUIRE_CREDIT_CARD_ALWAYS" }
Serwer rezerwacji
Podczas przetwarzania żądania, które obejmuje wymóg podania danych karty kredytowej, token płatności jest przekazywany do serwera rezerwacji w wywołaniu CreateBooking za pomocą pola payment_processing_parameters.unparsed_payment_method_token.
Ten token jest przekazywany w taki sam sposób jak w przypadku przedpłaty. Ponieważ jednak token jest autoryzowany tylko przez krótki czas, musisz wywołać odpowiedni interfejs API swojego procesora płatności, aby uaktualnić ten token do wersji, którą możesz zachować do późniejszego użycia.
W odpowiedzi serwera rezerwacji nie są wymagane żadne dodatkowe informacje poza tymi, które są wymagane w przypadku płatności po przyjeździe.
Zastępowanie cen na poziomie dostępności
We wszystkich powyższych przykładach struktura cen / opłat jest określona na poziomie usługi. W większości przypadków należy stosować te ceny na poziomie usługi. W niektórych przypadkach warto jednak zmienić strukturę płatności w przypadku niektórych slotów dostępności. Za pomocą zastąpienia cen / opłat na poziomie dostępności można na przykład rozwiązać takie sytuacje:
- We wtorki ceny są niższe, a w soboty wyższe.
- W okresie od 17:00 do 19:00 nie pobieramy opłat za występ.
Tabela poniżej zawiera listę pól, których należy użyć w pliku danych o dostępności, aby zastąpić definicję poziomu usługi w przypadku każdej metody płatności lub opłaty.
| Typ płatności | Definicja opłaty / ceny | Czy można zastąpić? |
|---|---|---|
| Płatność po przyjeździe | Service.price
|
Cena może zostać zastąpiona za pomocą atrybutu Availability.payment_option_id odwołującego się do atrybutu Merchant.payment_option.
|
| Przedpłata | Service.price
|
Cena może zostać zastąpiona przez wartość Availability.payment_option_id odwołującą się do Merchant.payment_option.
|
| Opłata za niestawienie się | Service.no_show_fee
|
Availability.no_show_fee
|
| Wpłata | Service.deposit
|
Availability.deposit
|
| Wymagaj podania danych karty kredytowej | Service.require_credit_card
|
Availability.require_credit_card
|
Aby zastąpić cenę na poziomie dostępności, musisz najpierw zdefiniować opcję płatności na poziomie sprzedawcy. Dodatkowe wskazówki dotyczące dodawania okien anulowania na poziomie dostępności znajdziesz w przewodniku Jak dodawać okna anulowania.