Définir différents modes de paiement

La plate-forme du centre d'actions accepte différentes configurations pour accepter les paiements. La Le guide d'activation des paiements couvre les aspects de l'intégration sont communs à toutes les intégrations de paiement, y compris les suivants:

1. Configurer les flux de façon à inclure les informations tokenization_parameter
2. Mise à jour du serveur de réservation pour qu'il accepte payment_method_token... objets
3. Une vue d'ensemble des informations échangées entre un utilisateur, le centre d'actions le partenaire / marchand et la société de traitement des paiements.

Dans ce guide, nous verrons plus en détail configurer vos flux afin de spécifier les types configurations de paiement s'appliquent à vos marchands et services.

1. Aucun paiement / Paiement à l'arrivée
2. Pré-paiement intégral
3. Frais de non-présentation / frais d'annulation
4. Deposit

Tous les cas d'utilisation des paiements sont des extensions de l'absence de paiement / paiement à l'arrivée (qui ne nécessite aucune configuration de paiement). vous allez d'abord décrire cette configuration et traiter les autres en tant qu'extensions.

Chaque section aborde également les champs à suivre dans le serveur de réservation afin d'accepter le paiement configuration.

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. d'application. Toutefois, les prix restent obligatoires.

Il s'agit de la configuration de base d'un service, qui contient son nom, sa description et son prix. Il s'agirait d'un seul message de service dans un délai 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 doivent être payés intégralement au moment de la réservation.

Le pré-paiement est défini au niveau du service via la Champ prepayment_type de Service Pour exiger le paiement d'un service, doit être défini sur REQUIRED, comme dans l'exemple ci-dessous. Notez que le prix est spécifié de la même façon que dans l'exemple du paiement à l'arrivée. Ici, étant donné que le type de pré-paiement est défini sur "Obligatoire", une carte de crédit est s'il est collecté et ce prix peut être facturé au moment du règlement.

<ph type="x-smartling-placeholder">

</ph> Important:Sauf indication contraire avec cancellation_policy (utilisation limitée, veuillez vous adresser à votre contact Google) nous partons du principe que le terme "annulable" signifie "remboursable à 100 %". Assurez-vous de configurer correctement période d'annulation.

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 réservation. dans l'appel de CreateBooking à travers le champ payment_processing_parameters.unparsed_payment_method_token Vous devez facturer exactement le montant spécifié dans les dans les flux et vous devez utiliser la devise spécifiées dans les flux. Ces frais doivent suivre la procédure décrite dans Guide d'activation des paiements

Lorsque vous renvoyez un CreateBookingResponse le champ booking.payment_information doit être défini correctement indiquer que le prépaiement a été fourni et traité.

La La spécification PaymentInformation contient la valeur pour connaître toutes les options concernant les informations de paiement. Un exemple minimal pour du prépaiement est indiqué ci-dessous. Il est important que le prix renvoyées dans le champ "price" doit correspondre exactement à celle indiquée dans le champ requête. De plus, si un taux de taxe est spécifié dans les flux/la demande, doivent également être inclus exactement.

Notez également que vous devez indiquer un ID de transaction. Cet ID de transaction doit, au minimum, être unique parmi les transactions effectuées avec ce marchand. A Un ID de transaction est parfaitement adapté à l'ID de transaction fourni par la société de traitement des paiements.

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 de absence

Des frais de non-présentation peuvent être facturés à l'utilisateur s'il n'est pas présent réservation ou s'il l'annule après période d'annulation. Si aucune période d'annulation n'est spécifiée, est défini par défaut sur l'heure de début du créneau.

Pour indiquer des frais de non-présentation, vous devez inclure le paramètre no_show_fee, 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 taux fixe de 25 USD, comme indiqué dans les Champ no_show_fee.fee.price_micros si le détenteur du rendez-vous n'assiste pas au rendez-vous. Ces frais peuvent également être facturés si l'utilisateur annule dans les 4 heures (14 400 secondes) avant le rendez-vous, spécifié dans les scheduling_rules.min_advance_online_canceling .

<ph type="x-smartling-placeholder">

</ph> Important:Sauf indication contraire avec cancellation_policy (utilisation limitée, veuillez vous adresser à votre contact Google) nous partons du principe que le terme "annulable" signifie "remboursable à 100 %". Assurez-vous de configurer correctement période d'annulation.

Pour découvrir comment définir des frais de non-présentation au niveau de la disponibilité, consultez cette section.

Serveur de réservation

Lors du traitement d'une demande incluant des frais de non-présentation, un jeton de paiement est transmise à votre serveur de réservation dans l'appel CreateBooking à travers 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 vers une version que vous pouvez conserver pour une utilisation plus tard. Cette procédure est décrite dans la section "Activer les paiements". sur Parcours du jeton de frais en cas de non-présentation.

Lorsque vous renvoyez un CreateBookingResponse le champ booking.payment_information doit être défini de manière appropriée renvoient 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 no_show_fee est défini pour refléter le prix et structure des frais susceptibles d'être facturés. Notez également que, comme pour exemple de 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 à envoyer lors de la facturation. des frais de non-présentation. Il est attendu que cet ID soit stocké avec les informations concernant la réservation.

Real-Time Updates (Mises à jour en temps réel)

Si un utilisateur n'arrive pas à la réservation planifiée ou l'annule après la période d'annulation (en vous contactant directement, par exemple), peut éventuellement facturer les frais de non-présentation indiqué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 un Mise à jour en temps réel indiquant que des frais de non-présentation ont été facturés.

Pour les réservations créées avant le 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, dont l'état est défini sur NO_SHOW_PENALIZED Cet état indique à Google qu'un débit a été débité

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

Les dépôts servent à collecter les frais initiaux pour réservation. Les acomptes peuvent être facturés au moment de la réservation ou ultérieurement en temps réel. Vous devrez peut-être définir les conditions de remboursement des acomptes. ainsi que lorsqu'une réservation peut être annulée en ligne.

Pour spécifier un acompte, vous devez inclure dans le flux de services le deposit, 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": 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 le délai d'annulation et la deposit.min_advance_cancellation_sec détermine quand l'acompte est remboursable. Notez que, dans l'exemple ci-dessus, un acompte peut spécifier un délai d'annulation séparément des conditions de remboursement. Dans ce cas, l'utilisateur pourra annuler le service en ligne jusqu'à 24 heures à l'avance (86 400 secondes). Cela garantit que le marchand directement informée de toute annulation tardive. Toutefois, il se peut que l'utilisateur peuvent obtenir un remboursement sur leur acompte jusqu'à 4 heures à l'avance ; (14 400 secondes) avant la réservation (en vous contactant ou en contactant le marchand pour l'annulation) qui apparaîtra dans les conditions lors du règlement et dans l'e-mail de confirmation.

<ph type="x-smartling-placeholder">

</ph> Important:Sauf indication contraire avec cancellation_policy (utilisation limitée, veuillez contacter votre contact Google) ou deposit.min_advance_cancellation_sec, nous partons du principe que le terme "annulable" signifie "remboursable à 100 %". Assurez-vous de configurer correctement période d'annulation.

Pour découvrir comment définir des acomptes au niveau de la disponibilité, consultez cette section.

Serveur de réservation

Lors du traitement d'une demande incluant un virement, un jeton de paiement est transmis à votre serveur de réservation dans l'appel CreateBooking à travers 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 ou prélever la retenue au moment de la réservation, vous pouvez le faire lors de cette demande.

Si vous avez l'intention de débiter le virement ultérieurement, car le jeton n'est autorisé que pour une courte période, vous devez appeler la méthode API pertinente de votre société de traitement des paiements pour convertir ce jeton en que vous pouvez conserver pour une utilisation ultérieure. C'est décrites dans la section "Activer les paiements" du guide flux des jetons de dépôt.

Lorsque vous renvoyez un CreateBookingResponse le champ booking.payment_information doit correctement l'écho de l'état du virement, 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 le versement est configuré pour refléter le prix et la structure du qui sera débité ou retenu. Notez également que, comme pour exemple de 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 fin de la période d'annulation de l'acompte, vous doit rembourser tout acompte que vous avez facturé sur la carte de l'utilisateur. Quand ? pour le remboursement d'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 avant le CreateBooking, une mise à jour doit être envoyée à notification.partners.bookings.patch Dans le corps de ce doit correspondre à la réservation mise à jour, et son état est défini sur CANCELED et les Champ paymentInformation.prepaymentStatus défini sur PREPAYMENT_REFUNDED Google informe ainsi Google que le virement a été remboursée.

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"
    }
    
}

Exiger une carte de crédit

Un service peut nécessiter une carte de crédit supplémentaire de l'identité de l'utilisateur. Toutefois, il ne doit pas être utilisé concernant les prépaiements, les acomptes ou les frais de non-présentation. Si ces cas d'utilisation sont s'ils sont obligatoires, ils doivent être configurés explicitement ci-dessus. Notez également que l'obligation de fournir une carte de crédit entraîne souvent une une baisse significative du nombre de réservations pour ce service.

Pour exiger la fourniture d'une carte de crédit lors du règlement, vous devez définir le champ require_credit_card pour 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

Dans le cadre du traitement d'une demande qui exige une carte de crédit, un paiement est transmis à votre serveur de réservation dans l'appel CreateBooking à travers 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 vers une version que vous pouvez conserver pour une utilisation plus tard.

Aucune information supplémentaire n'est requise dans la réponse du serveur de réservation au-delà du paiement à l'arrivée.

Remplacer un prix au niveau de la disponibilité

Dans tous les exemples ci-dessus, la structure de prix / frais est spécifiée au niveau du service. Dans la plupart des cas, ces tarifs de service doivent être utilisé. Toutefois, dans certains cas, il peut être judicieux de modifier la structure de paiement pour certains créneaux de disponibilité. Par exemple, les situations suivantes peut être géré en remplaçant les prix / frais au niveau de la disponibilité:

• Les prix sont réduits le mardi et augmentés le samedi.
• Si vous ne vous présentez pas dans l'établissement, des frais s'appliquent si vous n'êtes pas disponible entre 17h et 19h.

Le tableau ci-dessous indique, pour chaque mode de paiement ou de frais, quel champ à utiliser dans le flux disponibilité pour remplacer la définition du niveau de service.

Type de paiement	Définition des frais / prix	Remplaçable ?
Paiement à l'arrivée	Service.price	Prix pouvant être remplacé via Availability.payment_option_id référençant Merchant.payment_option
Paiement d'avance	Service.price	Vous pouvez remplacer le prix via Availability.payment_option_id référençant 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

Pour remplacer le prix au niveau de la disponibilité, vous devez d'abord définir une option de paiement au niveau du marchand. En outre, pour obtenir des conseils sur l'ajout les périodes d'annulation au niveau de la disponibilité, consultez le guide Ajouter des périodes d'annulation