La plate-forme Actions Center est compatible avec différentes configurations pour accepter les paiements. Le guide d'activation des paiements couvre les aspects de l'intégration communs à toutes les intégrations de paiements, y compris les suivants:
- Configurer des flux pour inclure des informations
tokenization_parameter - Mettre à jour le serveur de réservation pour qu'il accepte les objets
payment_method_token - Présentation des informations échangées entre un utilisateur, le Centre d'actions, le partenaire / marchand et le prestataire de traitement des paiements.
Dans ce guide, nous allons vous expliquer plus en détail comment configurer vos flux pour spécifier les différents types de configurations de paiement applicables à vos marchands et services.
- Aucun paiement / Paiement sur place
- Prépaiement total
- Frais de non-présentation / d'annulation
- Deposit
Tous les cas d'utilisation des paiements sont des extensions du cas d'utilisation "Pas de paiement" ou "Paiement à l'arrivée" (qui ne nécessite aucune configuration de paiement). Ce tutoriel commencera donc par décrire cette configuration et traitera les autres configurations comme des extensions.
Chaque section aborde également les champs à suivre dans le serveur de réservation afin d'accepter la configuration de paiement spécifique.
Aucun paiement / Paiement sur place
Pour les services qui ne nécessitent aucun paiement au moment de la réservation, aucune configuration de paiement n'est requise au niveau du marchand ou du service. Toutefois, les prix sont toujours obligatoires.
Il s'agit de la configuration de référence d'un service, qui contient un nom, une description et un prix. Il s'agit d'un seul message de service dans un 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" } }
Aucune configuration supplémentaire au-delà de l'implémentation standard n'est requise dans le serveur de réservation pour prendre en charge le paiement à l'arrivée.
Paiement d'avance
Cette configuration permet de spécifier que le montant du service doit être payé intégralement au moment de la réservation.
Le prépaiement est spécifié au niveau du service via le champ prepayment_type de Service. Pour exiger des paiements pour un service, cette valeur doit être définie sur REQUIRED, comme dans l'exemple ci-dessous. Notez que le prix est spécifié de la même manière que dans l'exemple de paiement à l'arrivée. Ici, comme nous définissons le type de prépaiement sur "obligatoire", une carte de crédit sera collectée et ce prix pourra être facturé au moment du règlement.
{ "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" }
Serveur de réservation
Lorsque vous acceptez les prépaiements, un jeton de paiement est transmis à votre serveur de réservation dans l'appel à CreateBooking via le champ payment_processing_parameters.unparsed_payment_method_token.
Vous devez facturer exactement le montant spécifié dans le champ de prix des flux et utiliser la devise spécifiée dans les flux. Ces frais doivent suivre la procédure décrite dans le guide d'activation des paiements.
Lorsque vous renvoyez un CreateBookingResponse, le champ booking.payment_information doit être défini pour indiquer correctement que le prépaiement a été fourni et traité.
La spécification PaymentInformation contient une documentation complète pour toutes les options d'informations de paiement. Vous trouverez ci-dessous un exemple minimal de traitement du prépaiement. Il est important que le prix renvoyé dans le champ de prix corresponde exactement à celui spécifié dans la requête. De plus, si un taux de taxe est spécifié dans les flux/requêtes, il doit également être inclus exactement.
Notez également que vous devez fournir un ID de transaction. Cet ID de transaction doit être au moins unique parmi les transactions effectuées auprès de ce marchand. L'ID de transaction fourni par le processeur de paiement est un bon candidat pour un ID de transaction.
{ "prepayment_status": "PREPAYMENT_PROVIDED", "payment_processed_by": "PROCESSED_BY_PARTNER", "payment_transaction_id": "[this-transaction-id]", "price": { "price_micros": "200000000", "currency_code": "USD" } }
Frais de non-présentation
Des frais de non-présentation peuvent être facturés à un utilisateur s'il ne se présente pas à sa réservation ou s'il annule après la période d'annulation. Si aucune période d'annulation n'est spécifiée, elle est définie par défaut sur l'heure de début du créneau.
Pour spécifier des frais de non-présentation, dans le flux de services, vous devez inclure le champ no_show_fee, comme indiqué dans l'exemple ci-dessous:
{ "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" } }
Dans l'exemple ci-dessus, le partenaire ou le marchand est autorisé à facturer un tarif fixe de 25 $, comme indiqué dans le champ no_show_fee.fee.price_micros, si le titulaire du rendez-vous ne s'y présente pas. Ces frais peuvent également être facturés si l'utilisateur annule dans les quatre heures (14 400 secondes) avant le rendez-vous, comme indiqué dans le champ scheduling_rules.min_advance_online_canceling.
Pour savoir comment définir des frais de non-présentation au niveau de la disponibilité, consultez cette section.
Serveur de réservation
Lorsque vous traitez une demande qui inclut des frais d'absence, un jeton de paiement est transmis à votre serveur de réservation dans l'appel à CreateBooking via le champ payment_processing_parameters.unparsed_payment_method_token.
Ce jeton est transmis de la même manière que dans le cas du prépaiement. Toutefois, comme le jeton n'est autorisé que pendant une courte période, vous devez appeler l'API appropriée de votre processeur de paiement pour convertir ce jeton en une version que vous pouvez conserver pour l'utiliser ultérieurement. Pour en savoir plus, consultez la section Flux de jetons de frais d'absence du guide d'activation des paiements.
Lorsque vous renvoyez un CreateBookingResponse, le champ booking.payment_information doit être défini pour renvoyer correctement l'état des frais de non-présentation, comme illustré dans l'exemple ci-dessous.
{ "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" } }
Notez que no_show_fee est défini pour refléter le prix et la structure des frais qui peuvent être facturés. Notez également que, comme dans l'exemple des prépaiements, un transaction_id est requis dans ce message.
Notez également que le booking_id défini dans CreateBookingResponse est un champ obligatoire pour les mises à jour en temps réel qui doivent être envoyées lorsque des frais de non présentation sont facturés. Cet ID doit être stocké avec des informations sur la réservation.
Real-Time Updates (Mises à jour en temps réel)
Si un utilisateur ne se présente pas à la réservation planifiée ou annule après la période d'annulation (par exemple, en vous contactant directement), vous pouvez éventuellement lui facturer les frais de non-présentation spécifiés à l'aide des informations de paiement que vous avez stockées au moment de la réservation. Lorsque vous facturez des frais de non présentation, vous devez envoyer une mise à jour en temps réel indiquant que ces frais ont été facturés.
Pour les réservations créées par CreateBooking, une mise à jour doit être envoyée à notification.partners.bookings.patch. Le corps de cette requête doit contenir la réservation mise à jour, avec l'état défini sur NO_SHOW_PENALIZED. Cet état informe Google qu'un débit a été effectué.
Par exemple, une demande peut être envoyée à:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
Avec un corps de requête:
{ "name": "partners/12345678/bookings/123123123" "merchantId": "merchant-1" "serviceId": "service-2-b" "status": "NO_SHOW_PENALIZED" }
Deposit
Les acomptes permettent de collecter un montant initial, qui est obligatoire pour la réservation. Les acomptes peuvent être débités au moment de la réservation ou ultérieurement. Vous devrez peut-être définir les conditions de remboursement d'un acompte, ainsi que les conditions d'annulation d'une réservation en ligne.
Pour spécifier un dépôt, dans le flux de services, vous devez inclure le champ deposit, comme illustré dans l'exemple ci-dessous:
{ "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" } }
Dans cet exemple, min_advance_online_canceling définit la période d'annulation et deposit.min_advance_cancellation_sec définit le moment où le dépôt est remboursable. Notez que dans l'exemple ci-dessus, un dépôt peut spécifier un délai de résiliation distinct des conditions de remboursement. Dans ce cas, un utilisateur peut résilier le service en ligne jusqu'à 24 heures à l'avance (86 400 secondes). Cela permet au marchand d'être directement informé de toute annulation tardive. Toutefois, l'utilisateur peut toujours être remboursé de son acompte jusqu'à quatre heures à l'avance (14 400 secondes) avant la réservation (en vous contactant ou en contactant le marchand pour annuler la réservation), ce qui sera indiqué dans les conditions de paiement et dans l'e-mail de confirmation.
Pour savoir comment définir des acomptes au niveau de la disponibilité, consultez cette section.
Serveur de réservation
Lorsque vous traitez une requête incluant un dépôt, un jeton de paiement est transmis à votre serveur de réservation dans l'appel à CreateBooking via le champ payment_processing_parameters.unparsed_payment_method_token.
Ce jeton est transmis de la même manière que dans le cas du prépaiement. Si vous facturez le dépôt ou effectuez la retenue au moment de la réservation, vous pouvez le faire lors de cette demande.
Si vous prévoyez de facturer le dépôt ultérieurement, car le jeton n'est autorisé que pour une courte période, vous devez appeler l'API appropriée de votre processeur de paiement pour convertir ce jeton en version que vous pouvez conserver pour l'utiliser ultérieurement. Pour en savoir plus, consultez la section Flux de jetons de dépôt du guide d'activation des paiements.
Lorsque vous renvoyez un CreateBookingResponse, le champ booking.payment_information doit renvoyer correctement l'état du dépôt, comme dans l'exemple ci-dessous.
{ "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" } }
Notez que le montant du dépôt est défini pour refléter le prix et la structure du dépôt qui sera facturé ou retenu. Notez également que, comme dans l'exemple des prépaiements, un transaction_id est requis dans ce message.
Real-Time Updates (Mises à jour en temps réel)
Si un utilisateur annule sa réservation avant la période d'annulation du dépôt, vous devez rembourser tout dépôt que vous avez facturé sur sa carte. Lorsque vous remboursez un acompte, vous devez envoyer une mise à jour en temps réel indiquant que l'acompte a été remboursé.
Pour les réservations créées par CreateBooking, une mise à jour doit être envoyée à notification.partners.bookings.patch. Le corps de cette requête doit contenir la réservation mise à jour, avec l'état défini sur CANCELED et le champ paymentInformation.prepaymentStatus défini sur PREPAYMENT_REFUNDED. Cela informe Google que le dépôt a été remboursé.
Par exemple, vous pouvez envoyer une demande à:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
Avec un corps de requête:
{ "name": "partners/12345678/bookings/123123123" "merchantId": "merchant-1" "serviceId": "service-2-b" "status": "CANCELED" "paymentInformation": { "prepaymentStatus": "PREPAYMENT_REFUNDED" } }
Exiger une carte de crédit
Un service peut exiger une carte de crédit comme validation supplémentaire de l'identité de l'utilisateur. Cependant, il ne doit pas être utilisé pour les prépaiements, les acomptes ni les frais de non-présentation. Si ces cas d'utilisation sont requis, ils doivent être configurés explicitement en suivant les étapes ci-dessus. Notez également que l'exigence d'une carte de crédit entraîne souvent une baisse importante des réservations pour ce service.
Pour exiger qu'une carte de crédit soit fournie lors du règlement, vous devez définir le champ require_credit_card sur 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" }
Serveur de réservation
Lorsque vous traitez une demande qui nécessite une carte de crédit, un jeton de paiement est transmis à votre serveur de réservation dans l'appel à CreateBooking via le champ payment_processing_parameters.unparsed_payment_method_token.
Ce jeton est transmis de la même manière que dans le cas du prépaiement. Toutefois, comme le jeton n'est autorisé que pendant une courte période, vous devez appeler l'API appropriée de votre processeur de paiement pour convertir ce jeton en une version que vous pouvez conserver pour l'utiliser ultérieurement.
Aucune information supplémentaire n'est requise dans la réponse du serveur de réservation au-delà de celle du cas d'utilisation du paiement à l'arrivée.
Remplacer la tarification au niveau de la disponibilité
Dans tous les exemples ci-dessus, la structure des prix / frais est spécifiée au niveau du service. Dans la plupart des cas, vous devez utiliser cette tarification au niveau du service. Toutefois, dans certains cas, il est judicieux de modifier la structure des paiements pour certains créneaux de disponibilité. Par exemple, les situations suivantes peuvent être gérées en remplaçant les prix / frais au niveau de la disponibilité:
- Les prix sont réduits les mardis et augmentés les samedis.
- Aucuns frais de non-présentation ne s'appliquent aux disponibilités entre 17h et 19h.
Le tableau ci-dessous indique, pour chaque méthode de paiement / frais, le champ à utiliser dans le flux de disponibilité pour remplacer la définition du niveau de service.
| Type de paiement | Définition des frais / prix | Peut-il être remplacé ? |
|---|---|---|
| Paiement sur place | Service.price
|
Prix pouvant être remplacé par une référence Availability.payment_option_id à Merchant.payment_option
|
| Paiement d'avance | Service.price
|
Le prix peut être remplacé par une référence Availability.payment_option_id à Merchant.payment_option.
|
| Frais de non-présentation | Service.no_show_fee
|
Availability.no_show_fee
|
| Deposit | Service.deposit
|
Availability.deposit
|
| Exiger une carte de crédit | Service.require_credit_card
|
Availability.require_credit_card
|
Notez que pour remplacer le prix au niveau de la disponibilité, vous devez d'abord définir une option de paiement au niveau du marchand. Pour savoir comment ajouter des périodes d'annulation au niveau de la disponibilité, consultez le guide Ajouter des périodes d'annulation.