Vue d'ensemble

Dans le cadre de l'intégration de bout en bout des réservations 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:

1. 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.
2. Accepter les paiements tokenisés en fonction de votre accord avec la société de traitement des paiements
3. Suivez la procédure de validation de l'identité et de l'activité décrite sur cette page.
4. 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 champ tokenization_config. L'ensemble dépend de la société de traitement des paiements choisie. Il s'agit du même ensemble de paymentMethodTokenizationParameters.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 du CreateBookingRequest. Il s'agit du même paymentData 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 sur PROCESSED_BY_PARTNER dans CreateBookingResponse.

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.

Modifications apportées aux flux de services

• Définissez le champ prepayment_type sur REQUIRED pour ce service.
• Définissez le champ require_credit_card sur REQUIRE_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ément payment_transaction_id, qui doit être unique. Le payment_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.

Modifications apportées aux flux de services ou de disponibilité

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 sur REQUIRE_CREDIT_CARD_CONDITIONAL au niveau du service ou du créneau de disponibilité.
• (Facultatif) Définissez prepayment_type sur REQUIRED ou OPTIONAL.

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 sur REQUIRE_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 sur status,payment_information.prepayment_status, puis payment_information.prepayment_status = PREPAYMENT_REFUNDED et status = CANCELED.
  • Utilisez les nouvelles valeurs BookingStatus = CANCELED et PrepaymentStatus = PREPAYMENT_REFUNDED. La valeur d'énumération CANCELED_AUTOMATIC_REFUND est obsolète pour l'API Maps Booking et les modèles gRPC.

Passer au serveur de réservation

• Lorsque le Centre d'actions envoie une notification UpdateBookingRequest et que cela déclenche un remboursement pour l'utilisateur, définissez booking.payment_information.prepayment_status = PREPAYMENT_REFUNDED dans le UpdateBookingResponse.