Dans le cadre de l'intégration de bout en bout des rendez-vous dans le Centre d'actions, vous pouvez autoriser vos marchands à recevoir des paiements des utilisateurs lorsqu'ils effectuent une réservation, ou un rendez-vous. Google collabore avec les sociétés de traitement des paiements pour configurer la tokenisation. Les sociétés de traitement des paiements utilisent ensuite des jetons uniques pour payer les marchands en toute sécurité.
Pour les réservations avec paiement sécurisé, nous affichons un module Informations de paiement dans le processus de paiement. Cela permet à l'utilisateur de saisir ses informations de carte de crédit.
Une assistance est disponible pour 3DS1 et 3DS2. Veuillez consulter ce tutoriel sur la mise en œuvre.
Éligibilité
Pour que vos marchands puissent recevoir des paiements via Actions Center, vous devez remplir les conditions suivantes:
- Utiliser une société de traitement des paiements compatible La liste la plus récente des sociétés de traitement des paiements est disponible sur le site Web de Google Pay.
- Accepter les paiements tokenisés en fonction de votre accord avec la société de traitement des paiements
- Suivez la procédure de validation de l'identité et de l'activité décrite sur cette page.
- Impossible d'activer le paiement pour les réservations nécessitant une confirmation asynchrone .
Modifications à apporter aux flux et au serveur de réservation pour les paiements
Les paiements sont effectués à l'aide d'un processus d'activation au niveau du marchand. Vous devez activer les paiements pour tous les marchands qui doivent recevoir un paiement pour l'un de leurs services. Pour activer les paiements, vous devez modifier les flux et le serveur de réservation.
Flux
- Flux des marchands:spécifiez les informations de paiement via le
tokenization_parameter
défini dans le champtokenization_config
. L'ensemble dépend de la société de traitement des paiements choisie. Il s'agit du même ensemble depaymentMethodTokenizationParameters.parameters
que celui qui serait transmis à Google Pay si vous l'intégriez. - Flux services/disponibilité:spécifiez les exigences de paiement en fonction de votre cas d'utilisation approprié. Pour en savoir plus, consultez Cas d'utilisation des paiements.
Serveur de réservation
- En fonction du type de paiement effectué, implémentez la méthode
CreateBooking
. - Google enverra des jetons de paiement dans le champ
payment_processing_parameters.unparsed_payment_method_token
dans le cadre duCreateBookingRequest
. Il s'agit du mêmepaymentData
que votre rappel recevrait dans une intégration Google Pay. - Dans la
CreateBookingResponse
, incluez un message PaymentInformation qui spécifie le type, l'état, l'ID de transaction et la structure du prix / des frais. - Définissez le champ
payment_information.payment_processed_by
surPROCESSED_BY_PARTNER
dansCreateBookingResponse
.
Cas d'utilisation de paiements
Lorsque vous envisagez d'accepter des paiements pour chacun de ces cas d'utilisation, veuillez consulter nos Règles relatives aux paiements et vous assurer que vous êtes en mesure de respecter toutes les règles applicables.
Voici les cas d'utilisation des paiements:
- Créer des réservations prépayées
- Acompte requis pour la réservation
- Frais de non-présentation si l'utilisateur ne se présente pas à la réservation
- Carte de crédit requise au moment de la réservation
Pour en savoir plus sur la mise en œuvre de chacun de ces cas d'utilisation, consultez le tutoriel sur la configuration des paiements.
Créer des réservations prépayées
La figure 1 illustre le flux d'activités entre les utilisateurs, vous (le partenaire de planification), Google et la société de traitement des paiements.
- Un paiement doit correspondre à 100 % du coût du service. En d'autres termes, les services doivent être payés intégralement au moment de la réservation.
-
Définissez le champ
prepayment_type
surREQUIRED
pour ce service. - Définissez le champ
require_credit_card
surREQUIRE_CREDIT_CARD_CONDITIONAL
pour ce service.
Acomptes et frais de non-présentation
Les acomptes et les frais de non-présentation sont configurés de la même manière. La figure 2 illustre le flux de ces activités entre les utilisateurs, vous (le partenaire de planification), Google et la société de traitement des paiements.
Des acomptes et des frais de non-présentation permettent de s'assurer que l'utilisateur se présente à la réservation.
- Un acompte peut être débité sur la carte de crédit de l'utilisateur, à l'avance ou ultérieurement.
- Des frais de non-présentation peuvent être facturés à l'utilisateur s'il ne se présente pas à la réservation.
- Si nécessaire, vous pouvez appliquer à la fois des acomptes et des frais de non-présentation à la réservation.
- Même si aucun paiement n'est requis à l'avance, le serveur de réservation doit répondre à la requête CreateBooking avec un élément
PaymentInformation
contenant un élémentpayment_transaction_id
, qui doit être unique. Lepayment_transaction_id
n'a pas besoin d'être fourni par la société de traitement des paiements, mais il peut être généré par le serveur de réservation.
Les acomptes et les frais de non-présentation peuvent être définis au niveau du service ou du créneau de disponibilité d'un marchand. Si vous les spécifiez au niveau du créneau de disponibilité, cela remplace les définitions au niveau du service.
- Pour activer les acomptes, définissez le champ
deposit
au niveau du service ou du créneau de disponibilité. - Pour activer des frais de non-présentation, définissez le champ
no_show_fee
au niveau du service ou du créneau de disponibilité. - Définissez le champ
require_credit_card
surREQUIRE_CREDIT_CARD_CONDITIONAL
au niveau du service ou du créneau de disponibilité. - (Facultatif) Définissez
prepayment_type
surREQUIRED
ouOPTIONAL
.
Carte de crédit requise
D'autres cas d'utilisation peuvent nécessiter une carte de crédit au moment de la réservation.
- Définissez le champ
require_credit_card
surREQUIRE_CREDIT_CARD_ALWAYS
au niveau du service ou du créneau de disponibilité d'un marchand.
Annulations et remboursements
Les annulations et les remboursements sont initiés par le partenaire (vous) ou par l'utilisateur via le Centre d'actions. Dans les deux cas, vous devez respecter la valeur CancellationPolicy
définie au niveau du service et communiquée à l'utilisateur lors du règlement de la réservation.
Si vous ne fournissez pas l'attribut CancellationPolicy
, nous partons du principe que toute annulation dans la période d'annulation définie par min_advance_online_canceling
, définie au niveau du service, est remboursable.
Si min_advance_online_canceling
n'est pas défini, sa valeur est de 0 (ce qui signifie qu'elle peut être annulée à tout moment).
Si vous devez désactiver la résiliation dans le Centre d'actions, veuillez vous adresser à votre contact Google.
Modifications apportées aux mises à jour en temps réel- Après avoir remboursé l'utilisateur, vous devez envoyer une mise à jour de la RTU de réservation pour modifier l'état du paiement de la réservation. Définissez
update_mask
surstatus,payment_information.prepayment_status
, puispayment_information.prepayment_status = PREPAYMENT_REFUNDED
etstatus = CANCELED
.- Utilisez les nouvelles valeurs
BookingStatus = CANCELED
etPrepaymentStatus = PREPAYMENT_REFUNDED
. La valeur d'énumérationCANCELED_AUTOMATIC_REFUND
est obsolète pour l'API Maps Booking et les modèles gRPC.
- Utilisez les nouvelles valeurs
- Lorsque le Centre d'actions envoie une notification
UpdateBookingRequest
et que cela déclenche un remboursement pour l'utilisateur, définissezbooking.payment_information.prepayment_status = PREPAYMENT_REFUNDED
dans leUpdateBookingResponse
.