La plate-forme Actions Center accepte diverses configurations pour la réception des paiements. Le guide d'activation des paiements couvre les aspects de l'intégration communs à toute intégration de paiements, y compris:
- Configurer les flux pour inclure les 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, Actions Center, le partenaire / marchand et la société de traitement des paiements.
Ce guide explique plus en détail comment configurer vos flux pour spécifier le type de configuration de paiement qui s'applique à vos marchands et services.
- Aucun paiement / Paiement à l'arrivée
- Prépaiement total
- Frais en cas de non-présentation / Frais d'annulation
- Deposit
Tous les cas d'utilisation des paiements sont des extensions du cas d'utilisation sans paiement/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 couvre également les champs à suivre dans le serveur de réservation afin d'accepter la configuration de paiement particulière.
Aucun paiement / Paiement à l'arrivée
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 restent obligatoires.
Il s'agit de la configuration de base pour un service, qui contient un nom, une description et un prix. Il peut s'agir d'un seul message Service dans un élément ServiceFeed:
JSON
{
"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 n'est requise au-delà de l'implémentation standard dans le serveur de réservation pour permettre le paiement à l'arrivée.
Paiement d'avance
Cette configuration permet d'indiquer que le montant du service doit être intégralement payé 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 le paiement d'un service, vous devez définir 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 comme obligatoire, une carte de crédit sera collectée et ce prix pourra être débité au moment du règlement.
JSON
{
"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 des prépaiements, un jeton de paiement est transmis à votre serveur de réservation dans l'appel de 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 le flux décrit dans le guide d'activation des paiements.
Lorsque vous renvoyez une valeur CreateBookingResponse, le champ booking.payment_information doit être défini pour refléter 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. Un exemple minimal de traitement du prépaiement est fourni ci-dessous. Il est important que le prix affiché dans le champ "price" corresponde exactement à celui spécifié dans la requête. De plus, si un taux de taxe est spécifié dans le flux ou la demande, il doit également être inclus exactement.
Notez également que vous devez fournir un ID de transaction. Cet ID de transaction doit au minimum être unique parmi les transactions effectuées avec ce marchand. L'ID de transaction qui vous a été fourni par la société de traitement des paiements est un bon candidat.
JSON
{
"prepayment_status": "PREPAYMENT_PROVIDED",
"payment_processed_by": "PROCESSED_BY_PARTNER",
"payment_transaction_id": "[this-transaction-id]",
"price": {
"price_micros": "200000000",
"currency_code": "USD"
}
}
Frais en cas de non-présentation
Des frais de non-présentation peuvent être facturés aux utilisateurs s'ils ne assistent pas à leur réservation ou s'ils l'annulent après la période d'annulation. Si aucune période d'annulation n'est spécifiée, l'heure de début du créneau est définie par défaut.
Pour spécifier des frais de non-présentation, vous devez inclure le champ no_show_fee dans le flux de services comme indiqué dans l'exemple ci-dessous:
JSON
{
"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 spécifié dans le champ no_show_fee.fee.price_micros, si le titulaire du rendez-vous ne se présente pas au rendez-vous. 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 découvrir comment définir des frais de non-présentation au niveau de disponibilité, consultez cette section.
Serveur de réservation
Lors du traitement d'une requête incluant des frais de non-présentation, un jeton de paiement est transmis à votre serveur de réservation dans l'appel de CreateBooking via le champ payment_processing_parameters.unparsed_payment_method_token.
Ce jeton est transmis de la même manière que pour le prépaiement. Toutefois, comme le jeton n'est autorisé que pour une courte période, vous devez appeler l'API appropriée de votre société de traitement des paiements pour mettre à niveau ce jeton dans une version que vous pourrez conserver pour une utilisation ultérieure. Ce processus est décrit dans la section du guide sur l'activation des paiements sur le parcours de jetons de frais en cas de non-présentation.
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 dans l'exemple ci-dessous.
JSON
{
"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 la valeur no_show_fee est définie pour refléter le prix et la structure des frais susceptibles d'être facturés. Notez également que, comme dans l'exemple de prépaiement, un transaction_id est requis dans ce message.
Notez également que le booking_id défini dans CreateBookingResponse est obligatoire pour les mises à jour en temps réel à envoyer lorsque vous facturez des frais de non-présentation. Cet identifiant devrait être stocké avec les informations sur la réservation.
Mises à jour en temps réel
Si un utilisateur n'arrive pas à la réservation prévue ou s'il annule après la période d'annulation (en vous contactant directement, par exemple), vous pouvez éventuellement facturer les frais de non-présentation spécifiés à l'aide des informations de paiement que vous avez enregistré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 la requête devrait 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 requête peut être envoyée à:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
Avec un corps de requête:
JSON
{
"name": "partners/12345678/bookings/123123123"
"merchantId": "merchant-1"
"serviceId": "service-2-b"
"status": "NO_SHOW_PENALIZED"
}
Deposit
Un acompte est requis 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 dans lesquelles un acompte est remboursable, et les cas dans lesquels une réservation peut être annulée en ligne.
Pour spécifier un acompte, vous devez inclure le champ deposit dans le flux de services comme illustré dans l'exemple ci-dessous:
JSON
{
"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ù l'acompte est remboursable. Notez que dans l'exemple ci-dessus, un acompte peut indiquer une date d'annulation distincte des conditions de remboursement. Dans ce cas, l'utilisateur peut annuler le service en ligne jusqu'à 24 heures à l'avance (86 400 secondes). Le marchand est ainsi directement informé en cas d'annulation tardive. Toutefois, l'utilisateur peut toujours avoir droit à un remboursement de l'acompte jusqu'à quatre heures à l'avance (14 400 secondes) avant la réservation (en vous contactant ou en contactant le marchand pour procéder à l'annulation), comme indiqué dans les conditions lors du règlement et dans l'e-mail de confirmation.
Pour savoir comment les acomptes peuvent être définis en fonction du niveau de disponibilité, consultez cette section.
Serveur de réservation
Lors du traitement d'une requête incluant un acompte, un jeton de paiement est transmis à votre serveur de réservation dans l'appel de CreateBooking via le champ payment_processing_parameters.unparsed_payment_method_token.
Ce jeton est transmis de la même manière que pour le prépaiement. Si vous débitez l'acompte ou si vous désactivez la retenue au moment de la réservation, vous pouvez le faire lors de la demande.
Si vous avez l'intention de débiter le dépôt ultérieurement, étant donné que le jeton n'est autorisé que pour une courte période, vous devez appeler l'API appropriée de votre société de traitement des paiements pour mettre à niveau ce jeton et obtenir une version que vous pourrez conserver pour une utilisation ultérieure. Ce processus est décrit dans la section du guide sur l'activation des paiements sur le flux de jetons de dépôt.
Lorsque vous renvoyez un CreateBookingResponse, le champ booking.payment_information doit correctement renvoyer l'état du dépôt, comme dans l'exemple ci-dessous.
JSON
{
"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 l'acompte est défini pour refléter le prix et la structure de l'acompte qui sera débité ou retenu. Notez également que, comme dans l'exemple de prépaiement, un transaction_id est requis dans ce message.
Mises à jour en temps réel
Si un utilisateur annule sa réservation avant la période d'annulation de l'acompte, vous devez rembourser l'acompte que vous avez débité sur la carte de l'utilisateur. 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. Google est ainsi informé que l'acompte a été remboursé.
Par exemple, une requête peut être envoyée à:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
Avec un corps de requête:
JSON
{
"name": "partners/12345678/bookings/123123123"
"merchantId": "merchant-1"
"serviceId": "service-2-b"
"status": "CANCELED"
"paymentInformation": {
"prepaymentStatus": "PREPAYMENT_REFUNDED"
}
}
Carte de crédit requise
Un service peut nécessiter une carte de crédit comme validation supplémentaire de l'identité de l'utilisateur. Toutefois, vous ne devez pas l'utiliser pour les prépaiements, les acomptes ou les frais de non-présentation. Si ces cas d'utilisation sont nécessaires, vous devez les configurer explicitement en suivant les étapes ci-dessus. Notez également que l'utilisation d'une carte de crédit entraîne souvent une baisse significative du nombre de 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.
JSON
{
"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
Lors du traitement d'une requête nécessitant une carte de crédit, un jeton de paiement est transmis à votre serveur de réservation dans l'appel de CreateBooking via le champ payment_processing_parameters.unparsed_payment_method_token.
Ce jeton est transmis de la même manière que pour le prépaiement. Toutefois, comme le jeton n'est autorisé que pour une courte période, vous devez appeler l'API appropriée de votre société de traitement des paiements pour mettre à niveau ce jeton dans une version que vous pourrez conserver pour une utilisation ultérieure.
Au-delà du cas d'utilisation du paiement à l'arrivée, aucune information supplémentaire n'est requise dans la réponse du serveur de réservation.
Remplacement des prix au niveau de la disponibilité
Dans tous les exemples ci-dessus, la structure tarifaire / frais est spécifiée au niveau du service. Dans la plupart des cas, il convient d'utiliser cette tarification au niveau du service. Toutefois, dans certains cas, il est judicieux de modifier la structure de paiement pour certains créneaux de disponibilité. Par exemple, vous pouvez gérer les situations suivantes en remplaçant les prix / frais au niveau de la disponibilité:
- Les prix sont réduits le mardi et augmentent le samedi.
- Des frais de non-présentation ne s'appliquent aux disponibilités entre 17h et 19h.
Le tableau ci-dessous liste, pour chaque mode de paiement et de frais, le champ à utiliser dans le flux disponibilité pour remplacer la définition du niveau de service.
| Type de paiement | Frais / Prix – Définition | Remplaçable ? |
|---|---|---|
| Paiement sur place | Service.price
|
Prix remplaçable via Availability.payment_option_id qui mentionne Merchant.payment_option
|
| Paiement d'avance | Service.price
|
Vous pouvez remplacer le prix via Availability.payment_option_id en faisant référence à Merchant.payment_option
|
| Frais en cas de non-présentation | Service.no_show_fee
|
Availability.no_show_fee
|
| Deposit | Service.deposit
|
Availability.deposit
|
| Carte de crédit requise | 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. De plus, pour savoir comment ajouter des périodes d'annulation selon le niveau de disponibilité, consultez le guide Ajouter des périodes d'annulation.