Nền tảng Actions Center hỗ trợ nhiều cấu hình để thanh toán. Hướng dẫn bật tính năng thanh toán sẽ trình bày các khía cạnh tích hợp phổ biến đối với mọi chế độ tích hợp thanh toán, bao gồm:
- Định cấu hình nguồn cấp dữ liệu để bao gồm thông tin về
tokenization_parameter - Đang cập nhật máy chủ đặt lịch hẹn để chấp nhận đối tượng
payment_method_token - Tổng quan về thông tin được trao đổi giữa người dùng, Trung tâm hành động, đối tác / người bán và công ty xử lý thanh toán.
Trong hướng dẫn này, chúng tôi sẽ đề cập chi tiết hơn về cách định cấu hình nguồn cấp dữ liệu để chỉ định những loại cấu hình thanh toán phù hợp với người bán và dịch vụ của bạn.
- Không thanh toán / thanh toán khi đến nơi
- Trả trước toàn bộ
- Phí vắng mặt / Phí huỷ
- Ký quỹ
Tất cả các trường hợp sử dụng tính năng thanh toán đều là phần mở rộng của trường hợp sử dụng không cần thanh toán/trả tiền khi đến nơi (không yêu cầu phải thiết lập thông tin thanh toán). Vì vậy, hướng dẫn này sẽ bắt đầu bằng cách mô tả cấu hình đó và coi các cấu hình khác là phần mở rộng.
Mỗi phần cũng sẽ bao gồm các trường cần theo dõi trong máy chủ đặt phòng để chấp nhận cấu hình thanh toán cụ thể.
Không thanh toán / thanh toán khi đến nơi
Đối với những dịch vụ không yêu cầu thanh toán tại thời điểm đặt trước, bạn không cần phải thiết lập thông tin thanh toán ở cấp người bán hoặc cấp dịch vụ. Tuy nhiên, bạn vẫn phải cung cấp giá.
Đây là cấu hình cơ sở của một dịch vụ, chứa tên, nội dung mô tả và giá. Đây sẽ là một thông báo Dịch vụ duy nhất trong 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"
}
}
Máy chủ đặt phòng không cần thiết lập gì thêm ngoài cách triển khai tiêu chuẩn để hỗ trợ việc thanh toán khi đến nơi.
Trả Tiền Trước
Cấu hình này dùng để chỉ định rằng khách hàng phải thanh toán toàn bộ số tiền cho dịch vụ tại thời điểm đặt trước.
Khoản trả trước được chỉ định cho cấp dịch vụ thông qua trường prepayment_type của Service. Để yêu cầu thanh toán cho một dịch vụ, bạn phải thiết lập thuộc tính này thành REQUIRED như trong ví dụ bên dưới. Xin lưu ý rằng giá tiền được chỉ định giống như ví dụ trả tiền khi đến nơi. Ở đây,
vì chúng tôi đang đặt hình thức trả trước thành bắt buộc, nên hệ thống sẽ thu thập thẻ tín dụng
và tính giá này tại thời điểm thanh toán.
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"
}
Máy chủ đặt phòng
Khi chấp nhận khoản trả trước, mã thông báo thanh toán sẽ được chuyển đến máy chủ đặt trước trong lệnh gọi đến CreateBooking thông qua trường payment_processing_parameters.unparsed_payment_method_token.
Bạn bắt buộc phải tính phí chính xác số tiền được chỉ định thông qua trường giá trong nguồn cấp dữ liệu và bạn phải sử dụng đơn vị tiền tệ được chỉ định trong các nguồn cấp dữ liệu đó. Các khoản phí này phải tuân theo quy trình được mô tả trong Hướng dẫn bật tính năng thanh toán.
Khi trả về một CreateBookingResponse, trường booking.payment_information phải được đặt để phản ánh chính xác rằng khoản thanh toán trước đã được cung cấp và xử lý.
Thông số kỹ thuật PaymentInformation chứa tài liệu đầy đủ cho tất cả các tuỳ chọn thông tin thanh toán. Dưới đây là một ví dụ tối thiểu về việc xử lý khoản trả trước. Điều quan trọng là giá được trả về trong trường giá phải khớp chính xác với giá được chỉ định trong yêu cầu. Ngoài ra, nếu thuế suất được chỉ định trong nguồn cấp dữ liệu/yêu cầu thì thuế suất cũng phải được cung cấp chính xác.
Ngoài ra, xin lưu ý rằng bạn phải cung cấp mã giao dịch. Mã giao dịch này tối thiểu phải là duy nhất trong các giao dịch với người bán đó. Mã giao dịch phù hợp là mã giao dịch mà công ty xử lý thanh toán cung cấp cho bạn.
JSON
{
"prepayment_status": "PREPAYMENT_PROVIDED",
"payment_processed_by": "PROCESSED_BY_PARTNER",
"payment_transaction_id": "[this-transaction-id]",
"price": {
"price_micros": "200000000",
"currency_code": "USD"
}
}
Phí vắng mặt
Người dùng có thể bị tính phí vắng mặt nếu họ không tham dự yêu cầu đặt chỗ, hoặc nếu họ huỷ sau thời hạn huỷ. Nếu bạn không chỉ định cửa sổ huỷ, thì thời gian bắt đầu của khung giờ sẽ được đặt mặc định.
Để chỉ định phí vắng mặt, trong nguồn cấp dữ liệu dịch vụ, bạn cần thêm trường no_show_fee như ví dụ dưới đây:
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"
}
}
Trong ví dụ trên, đối tác hoặc người bán được phép tính phí cố định là 25 USD như đã nêu trong trường no_show_fee.fee.price_micros nếu người đặt cuộc hẹn không tham dự cuộc hẹn. Google cũng có thể tính phí này nếu người dùng huỷ trong vòng 4 giờ (14400 giây) trước cuộc hẹn, như được nêu trong trường scheduling_rules.min_advance_online_canceling.
Để tìm hiểu cách xác định phí biểu diễn ở cấp độ phát sóng, hãy xem phần này.
Máy chủ đặt phòng
Khi xử lý một yêu cầu có bao gồm phí vắng mặt, mã thông báo thanh toán sẽ được chuyển đến máy chủ đặt chỗ trong lệnh gọi đến CreateBooking thông qua trường payment_processing_parameters.unparsed_payment_method_token.
Mã thông báo này được chuyển theo cách tương tự như trong trường hợp trả trước. Tuy nhiên, vì mã thông báo chỉ được uỷ quyền trong một thời gian ngắn, nên bạn phải gọi API có liên quan của công ty xử lý thanh toán để nâng cấp mã thông báo này thành một phiên bản mà bạn có thể duy trì sử dụng sau này. Nội dung này được mô tả trong phần hướng dẫn Bật tính năng thanh toán trên quy trình về mã thông báo Phí vắng mặt.
Khi trả về một CreateBookingResponse, bạn phải đặt trường booking.payment_information để lặp lại đúng cách trạng thái của phí không hiển thị như trong ví dụ dưới đây.
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"
}
}
Xin lưu ý rằng no_show_fee được đặt để phản ánh giá và cấu trúc của khoản phí có thể được tính phí. Ngoài ra, xin lưu ý rằng, tương tự như ví dụ về thanh toán trước, thông báo này bắt buộc phải có transaction_id.
Ngoài ra, xin lưu ý rằng booking_id được đặt trong CreateBookingResponse là trường bắt buộc đối với nội dung cập nhật theo thời gian thực phải được gửi khi tính phí vắng mặt. Mã dự kiến sẽ được lưu trữ cùng với thông tin về việc đặt vé.
Bản cập nhật theo thời gian thực
Nếu người dùng không đến để nhận lượt đặt chỗ theo lịch hoặc huỷ sau thời hạn huỷ (ví dụ: bằng cách liên hệ trực tiếp với bạn), bạn có thể tuỳ ý tính phí vắng mặt được quy định bằng cách sử dụng thông tin thanh toán mà bạn lưu trữ tại thời điểm đặt phòng. Khi tính phí vắng mặt, bạn phải gửi Thông tin cập nhật theo thời gian thực nêu rõ rằng phí vắng mặt bị tính.
Đối với các lượt đặt phòng do
CreateBooking tạo, hệ thống sẽ gửi thông tin cập nhật đến
notification.partners.bookings.patch. Trong phần nội dung của yêu cầu này phải là
yêu cầu đặt phòng đã cập nhật, và trạng thái được đặt thành
NO_SHOW_PENALIZED. Trạng thái này báo cho Google biết rằng bạn đã bị tính phí.
Ví dụ: một yêu cầu có thể được gửi đến:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
Với nội dung yêu cầu:
JSON
{
"name": "partners/12345678/bookings/123123123"
"merchantId": "merchant-1"
"serviceId": "service-2-b"
"status": "NO_SHOW_PENALIZED"
}
Ký quỹ
Tiền đặt cọc được dùng để thu phí ban đầu theo yêu cầu khi đặt phòng. Bạn có thể tính tiền đặt cọc tại thời điểm đặt phòng hoặc ngay sau đó. Bạn sẽ cần phải xác định điều khoản cho phép hoàn tiền đặt cọc cũng như thời điểm có thể huỷ lượt đặt phòng trực tuyến.
Để chỉ định một khoản tiền gửi, trong nguồn cấp dữ liệu dịch vụ, bạn nên thêm trường deposit như ví dụ dưới đây:
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"
}
}
Trong ví dụ này, min_advance_online_canceling xác định thời hạn huỷ và deposit.min_advance_cancellation_sec xác định thời điểm tiền đặt cọc có thể được hoàn lại. Xin lưu ý rằng trong ví dụ ở trên, khoản tiền gửi có thể chỉ định thời gian huỷ riêng biệt với điều khoản hoàn tiền. Trong trường hợp này, người dùng có thể huỷ dịch vụ trực tuyến trước tối đa 24 giờ (86400 giây). Điều này giúp đảm bảo người bán trực tiếp nhận được
thông báo về các yêu cầu huỷ trễ. Tuy nhiên, người dùng có thể vẫn đủ điều kiện được hoàn lại tiền đặt cọc cho đến 4 giờ trước khi đặt phòng (14.400 giây) trước khi đặt phòng (bằng cách liên hệ với bạn hoặc người bán để huỷ). Điều này sẽ được thể hiện trong các điều khoản ở bước thanh toán và trong email xác nhận.
Để xem cách xác định khoản tiền gửi ở cấp độ sẵn có, hãy xem phần này.
Máy chủ đặt phòng
Khi xử lý yêu cầu có một khoản tiền đặt cọc, mã thông báo thanh toán sẽ được chuyển đến máy chủ đặt trước của bạn trong lệnh gọi đến CreateBooking thông qua trường payment_processing_parameters.unparsed_payment_method_token.
Mã thông báo này được chuyển theo cách tương tự như trong trường hợp thanh toán trước. Nếu bạn
tính tiền đặt cọc hoặc xoá khoản tiền uỷ quyền tạm thời này tại thời điểm đặt vé, thì bạn có thể thực hiện
trong yêu cầu này.
Nếu có ý định tính phí khoản tiền gửi này vào lúc khác, vì mã thông báo chỉ được uỷ quyền trong một khoảng thời gian ngắn, bạn phải gọi API liên quan của công ty xử lý thanh toán để nâng cấp mã thông báo này thành một phiên bản mà bạn có thể duy trì sử dụng sau này. Nội dung này được mô tả trong phần hướng dẫn Bật tính năng thanh toán trong quy trình mã thông báo khoản tiền gửi.
Khi trả về một CreateBookingResponse, trường booking.payment_information phải lặp lại đúng cách trạng thái của khoản tiền gửi, như trong ví dụ dưới đây.
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"
}
}
Xin lưu ý rằng khoản tiền gửi được thiết lập để phản ánh giá và cấu trúc của khoản tiền gửi sẽ được tính hoặc giữ lại. Ngoài ra, xin lưu ý rằng, tương tự như ví dụ về thanh toán trước, thông báo này bắt buộc phải có transaction_id.
Bản cập nhật theo thời gian thực
Nếu người dùng huỷ lượt đặt trước trước thời hạn huỷ đặt cọc, bạn phải hoàn lại mọi khoản tiền đặt cọc đã tính vào thẻ người dùng. Khi hoàn tiền đặt cọc, bạn phải gửi Thông tin cập nhật theo thời gian thực để chỉ định rằng khoản tiền đó đã được hoàn lại.
Đối với các lượt đặt phòng do
CreateBooking tạo, hệ thống sẽ gửi thông tin cập nhật đến
notification.partners.bookings.patch. Trong phần nội dung của yêu cầu này phải là lượt đặt phòng đã cập nhật, trong đó trạng thái được đặt thành CANCELED và trường paymentInformation.prepaymentStatus được đặt thành PREPAYMENT_REFUNDED. Email này thông báo cho Google rằng khoản tiền đặt cọc đã được hoàn lại.
Ví dụ: một yêu cầu có thể được gửi đến:
PATCH https://mapsbooking.googleapis.com/v1alpha/notification/partners/12345678/bookings/123123123?updateMask=status
Với nội dung yêu cầu:
JSON
{
"name": "partners/12345678/bookings/123123123"
"merchantId": "merchant-1"
"serviceId": "service-2-b"
"status": "CANCELED"
"paymentInformation": {
"prepaymentStatus": "PREPAYMENT_REFUNDED"
}
}
Yêu cầu thẻ tín dụng
Một dịch vụ có thể yêu cầu thẻ tín dụng để xác minh thêm danh tính của người dùng. Tuy nhiên, bạn không nên sử dụng tài khoản này để thanh toán trước, đặt cọc hoặc phí không tham gia chương trình. Nếu cần phải thiết lập những trường hợp sử dụng đó, bạn nên định cấu hình một cách rõ ràng bằng các bước ở trên. Ngoài ra, xin lưu ý rằng việc yêu cầu thẻ tín dụng thường sẽ dẫn đến số lượt đặt trước dịch vụ này giảm đáng kể.
Để yêu cầu cung cấp thẻ tín dụng khi thanh toán, bạn phải đặt trường require_credit_card thành 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"
}
Máy chủ đặt phòng
Khi xử lý một yêu cầu có yêu cầu về thẻ tín dụng, mã thông báo thanh toán sẽ được chuyển đến máy chủ đặt trước của bạn trong lệnh gọi đến CreateBooking thông qua trường payment_processing_parameters.unparsed_payment_method_token.
Mã thông báo này được chuyển theo cách tương tự như trong trường hợp trả trước. Tuy nhiên, vì mã thông báo chỉ được uỷ quyền trong một thời gian ngắn, nên bạn phải gọi API có liên quan của công ty xử lý thanh toán để nâng cấp mã thông báo này thành một phiên bản mà bạn có thể duy trì sử dụng sau này.
Ngoài trường hợp sử dụng phương thức thanh toán khi đến nơi, bạn không cần cung cấp thêm thông tin nào khác trong phản hồi của máy chủ Đặt phòng.
Cơ chế ghi đè giá ở cấp độ sẵn có
Trong tất cả ví dụ trên, cơ cấu giá / phí được chỉ định ở cấp Dịch vụ. Trong hầu hết các trường hợp, bạn nên sử dụng mức giá ở mức dịch vụ này. Tuy nhiên, trong một số trường hợp, bạn nên thay đổi cơ cấu thanh toán cho những khung giờ còn trống nhất định. Ví dụ: Bạn có thể xử lý các trường hợp sau bằng cách ghi đè giá / phí ở cấp độ tình trạng còn hàng:
- Giá giảm vào thứ Ba và tăng vào thứ Bảy.
- Phí không hiển thị sẽ áp dụng nếu bạn đặt phòng trong khoảng thời gian từ 17:00 đến 19:00.
Đối với mỗi phương thức thanh toán / phí, bảng dưới đây cho biết những trường cần dùng trong nguồn cấp dữ liệu tình trạng còn hàng để ghi đè định nghĩa cấp dịch vụ.
| Hình thức thanh toán | Định nghĩa về phí / giá | Có thể ghi đè? |
|---|---|---|
| Thanh toán khi đến nơi | Service.price
|
Giá có thể ghi đè thông qua
Availability.payment_option_id tham chiếu đến
Merchant.payment_option
|
| Trả Tiền Trước | Service.price
|
Bạn có thể ghi đè giá thông qua Availability.payment_option_id tham chiếu đến Merchant.payment_option
|
| Phí xem không tham dự | Service.no_show_fee
|
Availability.no_show_fee
|
| Ký quỹ | Service.deposit
|
Availability.deposit
|
| Yêu cầu thẻ tín dụng | Service.require_credit_card
|
Availability.require_credit_card
|
Xin lưu ý rằng để thay thế giá ở cấp độ tình trạng còn hàng, trước tiên bạn phải xác định một tuỳ chọn thanh toán ở cấp người bán. Ngoài ra, để biết hướng dẫn về cách thêm khoảng thời gian huỷ ở cấp độ có thể huỷ, vui lòng xem hướng dẫn Cách thêm khoảng thời gian huỷ.