Aperçu

Dans le cadre de l'intégration de bout en bout des réservations du Centre d'actions, vous pouvez permettre à vos marchands de recevoir des paiements de la part des utilisateurs lorsqu'ils effectuent une réservation ou prennent 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 nécessitant un paiement sécurisé, nous affichons un module Informations de paiement lors du processus de règlement. Cela permet à l'utilisateur de saisir les données de sa carte de crédit.

Le système est compatible avec 3DS1 et 3DS2. Pour plus de détails, consultez ce tutoriel.

É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 que nous acceptons est disponible sur le site Web 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'entreprise décrite sur cette page.
  4. Le paiement ne peut pas être activé 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 le paiement pour tout marchand qui doit recevoir un paiement pour l'un ou l'autre de ses services. Pour activer les paiements, vous devez apporter des modifications aux flux et au serveur de réservation.

Flux

  • Flux 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 sélectionnée. Il s'agit du même ensemble de paramètres paymentMethodTokenizationParameters.parameters qui seraient transmis à Google Pay si vous décidiez d'intégrer ce mode de paiement.
  • Flux services/disponibilité:spécifiez les conditions de paiement en fonction de votre cas d'utilisation spécifique. Pour en savoir plus, consultez la section Cas d'utilisation de paiements.

Serveur de réservation

Cas d'utilisation de paiements

Lorsque vous envisagez d'accepter ou non des paiements pour chacun de ces cas d'utilisation, veuillez consulter nos Règles applicables aux paiements et vous assurer que vous pouvez les respecter.

Voici les cas d'utilisation des paiements:

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.

Figure 1: Diagramme de séquence des réservations prépayées
Figure 1: Diagramme représentant le processus applicable aux réservations prépayées
  • Un paiement doit correspondre à 100 % du coût du service. Autrement dit, les services doivent être payés intégralement au moment de la réservation.
Modifications apportées aux flux services

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.

Figure 2: Diagramme représentant le processus applicable aux acomptes et frais de non-présentation
Figure 2 : Diagramme représentant le processus applicable aux acomptes et frais de non-présentation

Les acomptes et frais de non-présentation vous permettent de vous assurer qu'un utilisateur se présente à sa réservation.

  • Un acompte peut être débité sur la carte de crédit de l'utilisateur soit à l'avance, soit ultérieurement.
  • Des frais de non-présentation peuvent être facturés à l'utilisateur s'il ne se présente pas à sa réservation.
  • Si nécessaire, vous pouvez appliquer en même temps des acomptes et des frais de non-présentation à une 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 champ PaymentInformation contenant un identifiant payment_transaction_id qui doit être unique. La société de traitement des paiements n'a pas besoin de fournir l'identifiant payment_transaction_id. Il peut être généré plutôt par le serveur de réservation.
Modifications apportées aux flux services ou disponibilité

Les acomptes et les frais de non-présentation peuvent être spécifiés 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é, ils remplacent les définitions incluses 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é pour un marchand donné.

Annulations et remboursements

Les annulations et les remboursements sont lancés par le partenaire (vous) ou par l'utilisateur via le Centre d'actions. Dans les deux cas, vous devez respecter le CancellationPolicy défini au niveau du niveau de service et communiqué à l'utilisateur lors du paiement de la réservation.

Si vous ne fournissez pas CancellationPolicy, toute résiliation effectuée dans la période de résiliation définie par min_advance_online_canceling, qui a été définie au niveau du niveau de service, est remboursable. Si min_advance_online_canceling n'est pas défini, sa valeur est 0 (ce qui signifie qu'il peut être annulé à tout moment).

Si vous devez désactiver l'annulation du côté du Centre d'actions, veuillez en discuter avec votre contact Google.

Modifications apportées aux RTU
  • Une fois le remboursement effectué, vous devez envoyer un RTU de mise à jour de la réservation pour modifier l'état du paiement de la réservation. Définissez update_mask sur status,payment_information.prepayment_status, puis définissez 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 les modèles gRPC et de l'API Maps Booking.
Change to Booking Server
  • Lorsque le Centre d'actions envoie un UpdateBookingRequest et que cela déclenche un remboursement pour l'utilisateur, définissez booking.payment_information.prepayment_status = PREPAYMENT_REFUNDED dans UpdateBookingResponse.