Эта страница переведена с помощью Cloud Translation API.

Установите различные типы платежей

Платформа Actions Center поддерживает различные конфигурации приема платежей. Руководство по включению платежей охватывает аспекты интеграции, общие для всех интеграций платежей, в том числе:

Настройка каналов для включения информации tokenization_parameter
Обновление сервера бронирования для приема объектов payment_method_token
Обзор информации, которой обмениваются пользователь, Центр действий, партнер/продавец и платежная система.

В этом руководстве мы более подробно рассмотрим, как настроить ваши каналы , чтобы указать, какие из различных типов платежных конфигураций применимы к вашим продавцам и услугам.

Никаких платежей / Оплата по прибытии
Полная предоплата
Плата за отсутствие явки/Плата за отмену бронирования
Депозит

Все варианты использования платежей являются расширениями варианта использования без платежей/оплаты по прибытии (который не требует настройки оплаты), поэтому это руководство начнется с описания этой конфигурации и рассмотрения других конфигураций как расширений.

В каждом разделе также будут описаны поля, которые необходимо отслеживать на сервере бронирования , чтобы принять конкретную конфигурацию оплаты.

Никаких платежей / Оплата по прибытии

Для услуг, которые не требуют оплаты во время бронирования, настройка платежей на уровне продавца или услуги не требуется. Однако цены все равно необходимы.

Это базовая конфигурация услуги, которая содержит имя, описание и цену. Это будет одно служебное сообщение в 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"
    }
}

Для поддержки оплаты по прибытии на сервере бронирования не требуется никакой дополнительной настройки, помимо стандартной реализации.

Предварительная оплата

Эта конфигурация используется для указания того, что сумма за услугу должна быть оплачена полностью во время бронирования.

Предоплата указывается на уровне сервиса через поле prepayment_type Service . Чтобы требовать оплату за услугу, необходимо установить значение REQUIRED , как показано в примере ниже. Обратите внимание, что цена указывается так же, как и в примере с оплатой по прибытии. Здесь, поскольку мы устанавливаем обязательный тип предоплаты, оплата будет произведена с помощью кредитной карты, и эта сумма может быть снята во время оформления заказа.

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

Сервер бронирования

При приеме предоплаты токен платежа передается на ваш сервер бронирования при вызове CreateBooking через поле payment_processing_parameters.unparsed_payment_method_token . Вы должны взимать именно сумму, указанную в поле цены в фидах, и использовать валюту, указанную в фидах. Эти сборы должны соответствовать порядку, описанному в Руководстве по активным платежам .

При возврате CreateBookingResponse поле booking.payment_information должно быть правильно указано, чтобы правильно отразить, что предоплата была предоставлена и обработана.

Спецификация PaymentInformation содержит полную документацию для всех вариантов платежной информации. Ниже приведен минимальный пример обработки предоплаты. Важно, чтобы цена, возвращаемая в поле цены, точно соответствовала той, которая указана в запросе. Кроме того, если в фидах/запросе указана ставка налога, она также должна быть указана точно.

Также обратите внимание, что вы должны указать идентификатор транзакции. Этот идентификатор транзакции должен быть как минимум уникальным среди транзакций с этим продавцом. Хорошим кандидатом на идентификатор транзакции является идентификатор транзакции, предоставленный вам платежной системой.

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 , как показано в примере ниже:

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

В приведенном выше примере партнер или продавец имеет право взимать фиксированную плату в размере 25 долларов США, как указано в поле no_show_fee.fee.price_micros , если владелец встречи не присутствует на встрече. Эта плата также может взиматься, если пользователь отменяет встречу в течение 4 часов (14 400 секунд) до встречи, как указано в поле scheduling_rules.min_advance_online_canceling .

Чтобы узнать, как можно определить плату за неявку на уровне доступности, см. этот раздел .

Сервер бронирования

При обработке запроса, включающего плату за неявку, токен платежа передается на ваш сервер бронирования при вызове CreateBooking через поле payment_processing_parameters.unparsed_payment_method_token . Этот токен передается таким же образом, как и в случае предоплаты. Однако, поскольку токен авторизуется только на короткий период времени, вам необходимо вызвать соответствующий API вашего платежного процессора, чтобы обновить этот токен до версии, которую вы сможете сохранить для использования в более позднее время. Это описано в разделе руководства по включению платежей, посвященном потоку токенов No-Show Fee .

При возврате CreateBookingResponse поле booking.payment_information должно быть установлено так, чтобы правильно отображать статус платы за неявку, как показано в примере ниже.

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

Обратите внимание, что параметр no_show_fee отражает цену и структуру комиссии, которая может взиматься. Также обратите внимание, что, как и в примере с предоплатой, в этом сообщении требуется transaction_id .

Также обратите внимание, что booking_id заданный в CreateBookingResponse , является обязательным полем для обновлений в реальном времени, которые должны отправляться при взимании платы за неявку. Ожидается, что этот идентификатор будет храниться вместе с информацией о бронировании.

Обновления в реальном времени

Если пользователь не прибывает для запланированного бронирования или отменяет бронирование после периода отмены (например, связавшись с вами напрямую), вы можете дополнительно взимать указанную плату за неявку, используя платежную информацию, которую вы сохранили во время бронирования. Когда вы взимаете плату за неявку, вы должны отправить уведомление в режиме реального времени , в котором будет указано, что плата за неявку была взимана.

Для бронирований, созданных CreateBooking , обновление должно быть отправлено на notification.partners.bookings.patch . В теле этого запроса должно быть обновленное бронирование со статусом NO_SHOW_PENALIZED . Этот статус сообщает Google о том, что списание было произведено.

Например, запрос можно отправить по адресу:

PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status

С телом запроса:

JSON

{
    "name": "partners/12345678/bookings/123123123"
    "merchantId": "merchant-1"
    "serviceId": "service-2-b"
    "status": "NO_SHOW_PENALIZED"
}

Депозит

Депозиты используются для получения первоначального взноса, необходимого для бронирования. Залог может взиматься во время бронирования или позднее. Возможно, вам потребуется определить, на каких условиях подлежит возврату депозит, а также когда бронирование можно отменить онлайн .

Чтобы указать депозит, в фиде сервиса необходимо включить поле deposit , как показано в примере ниже:

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

В этом примере min_advance_online_canceling определяет окно отмены, а deposit.min_advance_cancellation_sec определяет, когда депозит подлежит возврату. Обратите внимание, что в приведенном выше примере для депозита может быть указано время отмены отдельно от условий возврата. В этом случае пользователь сможет отменить услугу онлайн не позднее, чем за 24 часа (86400 секунд). Это гарантирует, что продавец будет напрямую проинформирован о любых поздних аннулированиях. Тем не менее, пользователь по-прежнему может иметь право на возврат своего депозита не позднее, чем за 4 часа (14 400 секунд) до бронирования (путем обращения к вам или продавцу по поводу отмены), что будет указано в условиях при оформлении заказа и в электронное письмо с подтверждением.

Чтобы узнать, как можно определить депозиты на уровне доступности, смотрите этот раздел .

Сервер бронирования

При обработке запроса, включающего депозит, токен платежа передается на ваш сервер бронирования при вызове CreateBooking через поле payment_processing_parameters.unparsed_payment_method_token . Этот токен передается таким же образом, как и в случае предоплаты. Если вы взимаете залог или снимаете блокировку во время бронирования, вы можете сделать это во время этого запроса.

Если вы намерены снять депозит позже, поскольку токен авторизован только на короткий период времени, вам необходимо вызвать соответствующий API вашего платежного процессора, чтобы обновить этот токен до версии, которую вы можете сохранить для использования в любое время. позднее время. Это описано в разделе руководства по включению платежей, посвященном потоку депозитных токенов .

При возврате CreateBookingResponse поле booking.payment_information должно правильно отображать статус депозита, как в примере ниже.

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

Обратите внимание, что депозит настроен так, чтобы отражать цену и структуру депозита, который будет взиматься или удерживаться. Также обратите внимание, что, как и в примере с предоплатой, в этом сообщении требуется transaction_id .

Обновления в реальном времени

Если пользователь отменяет свое бронирование до наступления окна отмены депозита, вы должны вернуть любой депозит, который вы списали с карты пользователя. При возврате депозита вам необходимо отправить уведомление в режиме реального времени , в котором будет указано, что депозит был возвращен.

Для бронирований, созданных CreateBooking , обновление должно быть отправлено на notification.partners.bookings.patch . В теле этого запроса должно быть обновленное бронирование со статусом CANCELED и полем paymentInformation.prepaymentStatus со значением PREPAYMENT_REFUNDED . Это информирует Google о том, что депозит был возвращен.

Например, запрос можно отправить по адресу:

PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status

С телом запроса:

JSON

{
    "name": "partners/12345678/bookings/123123123"
    "merchantId": "merchant-1"
    "serviceId": "service-2-b"
    "status": "CANCELED"
    "paymentInformation": {
      "prepaymentStatus": "PREPAYMENT_REFUNDED"
    }
    
}

Требовать кредитную карту

Сервис может потребовать кредитную карту в качестве дополнительной проверки личности пользователя. Однако его не следует использовать для предоплаты, депозитов или сборов за неявку . Если эти варианты использования необходимы, их следует настроить явно, используя описанные выше шаги. Также обратите внимание, что требование кредитной карты часто приводит к значительному снижению количества заказов на эту услугу.

Чтобы потребовать предоставления кредитной карты при оформлении заказа, вы должны установить в поле require_credit_card значение 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"
}

Сервер бронирования

При обработке запроса, включающего требование кредитной карты, токен платежа передается на ваш сервер бронирования при вызове CreateBooking через поле payment_processing_parameters.unparsed_payment_method_token . Этот токен передается таким же образом, как и в случае предоплаты. Однако, поскольку токен авторизуется только на короткий период времени, вам необходимо вызвать соответствующий API вашего платежного процессора, чтобы обновить этот токен до версии, которую вы сможете сохранить для использования в более позднее время.

В ответе сервера бронирования не требуется никакой дополнительной информации, кроме информации о варианте использования с оплатой по прибытии.

Переопределение цен на уровне доступности

Во всех приведенных выше примерах структура цены/комиссии указывается на уровне Сервиса. В большинстве случаев следует использовать цены на уровне обслуживания. Однако в некоторых случаях имеет смысл изменить структуру платежей для определенных слотов доступности. Например, следующие ситуации можно решить путем переопределения цен/сборов на уровне доступности:

Цены снижаются по вторникам и повышаются по субботам.
Плата за показ не взимается при наличии мест с 17:00 до 19:00.

В таблице ниже для каждого метода оплаты/комиссии указано, какое поле следует использовать в канале доступности, чтобы переопределить определение уровня обслуживания.

Способ оплаты	Определение комиссии/цены	Переопределяемый?
Оплата по прибытии	`Service.price`	Цена может быть переопределена через `Availability.payment_option_id` , ссылающийся на `Merchant.payment_option`
Предварительная оплата	`Service.price`	Цена может быть переопределена через `Availability.payment_option_id` , ссылающийся на `Merchant.payment_option`
Без платы за выступление	`Service.no_show_fee`	`Availability.no_show_fee`
Депозит	`Service.deposit`	`Availability.deposit`
Требовать кредитную карту	`Service.require_credit_card`	`Availability.require_credit_card`

Обратите внимание: чтобы переопределить цену на уровне доступности, необходимо сначала определить вариант оплаты на уровне продавца. Кроме того, инструкции по добавлению окон отмены на уровне доступности см. в руководстве «Как добавить окна отмены» .