Nền tảng Actions Center hỗ trợ nhiều cấu hình để thanh toán. Chiến lược phát hành đĩa đơn Bật Hướng dẫn thanh toán trình bày các khía cạnh của việc tích hợp áp dụng chung cho tất cả 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
tokenization_parameter - Đang cập nhật máy chủ đặt phòng để chấp nhận
payment_method_tokenđồ vật - Tổng quan về thông tin được trao đổi giữa người dùng, Actions Center, đố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 của mình để chỉ định những loại cấu hình thanh toán sẽ áp dụng cho người bán và dịch vụ của bạn.
- Không thanh toán / Thanh toán khi đến nơi
- Khoản thanh toán trước toàn bộ
- Phí vắng mặt / Phí huỷ phòng
- Khoản tiền gửi
Tất cả các trường hợp sử dụng phương thức thanh toán đều là thời gian gia hạn của phương thức không thanh toán / trường hợp sử dụng thanh toán khi đến nơi (không yêu cầu thiết lập thông tin thanh toán) sẽ bắt đầu bằng cách mô tả cấu hình đó và xử lý các cấu hình dưới dạng tiện ích.
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 khoản thanh toán cụ thể .
Không thanh toán / Thanh toán khi đến nơi
Đối với các dịch vụ không yêu cầu thanh toán tại thời điểm đặt trước, không cần thiết lập thông tin thanh toán với người bán hoặc dịch vụ cấp độ. Tuy nhiên, bạn vẫn phải cung cấp giá.
Đây là cấu hình cơ sở cho một dịch vụ, trong đó có
tên, mô tả và giá. Đây sẽ là một thông báo Dịch vụ duy nhất
trong một
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"
}
}
Bạn không cần phải sử dụng cấu hình bổ sung ngoài cách triển khai chuẩn trong máy chủ đặt phòng để hỗ trợ thanh toán khi đến nơi.
Trả Tiền Trước
Cấu hình này dùng để chỉ định số tiền của dịch vụ phải được thanh toán đầy đủ tại thời điểm đặt phòng.
Khoản trả trước được chỉ định theo 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ụ,
phải được đặt thành REQUIRED như trong ví dụ bên dưới. Lưu ý rằng
giá được chỉ định giống như ví dụ khi trả tiền khi đến nơi. Tại đây,
bởi vì chúng tôi đang đặt loại thanh toán trước thành bắt buộc, thẻ tín dụng sẽ
thu và mức giá này có thể được tính 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 thông tin đặt chỗ của bạn
máy chủ trong lệnh gọi đến
CreateBooking thông qua trường này
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 bắt buộc phải sử dụng đơn vị tiền tệ
được chỉ định trong 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
Bật Hướng dẫn thanh toán.
Khi trả lại một
CreateBookingResponse
trường booking.payment_information phải được thiết lập đúng
phản ánh rằng khoản thanh toán trước đã được cung cấp và xử lý.
Chiến lược phát hành đĩa đơn
Thông số kỹ thuật PaymentInformation chứa đầy đủ
chứng từ cho tất cả tuỳ chọn thông tin thanh toán. Một ví dụ tối giản về
việc xử lý khoản thanh toán trả trước được cung cấp bên dưới. Quan trọng là giá
trả về trong trường giá khớp chính xác với giá trị được chỉ định trong
của bạn. Ngoài ra, nếu thuế suất được chỉ định trong nguồn cấp dữ liệu/yêu cầu, nó
cũng phải được đưa vào 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 số các giao dịch với người bán đó. Đáp Mã giao dịch là mã giao dịch được cung cấp cho 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ể phải trả phí vắng mặt nếu họ không tham dự đặt chỗ hay nếu họ huỷ sau thời hạn huỷ. Nếu không có cửa sổ huỷ nào được chỉ định, thời gian bắt đầu của vị trí đặt quảng cáo mặc định.
Để chỉ định phí vắng mặt, bạn nên thêm thuộc tính này vào nguồn cấp dữ liệu dịch vụ
Trường no_show_fee như trong ví dụ bên dưới:
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 uỷ quyền để
tính phí theo mức cố định là 25 đô la theo quy định trong
Trường no_show_fee.fee.price_micros nếu người giữ cuộc hẹn
không tham dự cuộc hẹn. Phí này cũng có thể được tính nếu người dùng
huỷ trong vòng 4 giờ (14400 giây) trước cuộc hẹn, như
được chỉ định trong scheduling_rules.min_advance_online_canceling
.
Để xem cách xác định phí không hiển thị ở cấp độ hiện có, hãy xem phần này.
Máy chủ đặt phòng
Khi xử lý yêu cầu kèm theo phí vắng mặt, mã thông báo thanh toán
được chuyển đến máy chủ đặt phòng trong lệnh gọi đến
CreateBooking thông qua trường này
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 phương thức thanh toán trước
trường hợp. Tuy nhiên, vì mã thông báo này chỉ được cấp phép trong một khoảng thời gian ngắn
bạn phải gọi API tương ứng 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ể tiếp tục sử dụng tại
lúc khác. Điều này được mô tả trong phần hướng dẫn Bật tính năng thanh toán
về
Quy trình mã thông báo Phí không hiển thị.
Khi trả lại một
CreateBookingResponse
trường booking.payment_information phải được đặt đúng cách
lặp lại trạng thái của phí vắng mặt 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 thiết lập để phản ánh giá và
phần cấu trúc của khoản phí có thể được tính. Ngoài ra, xin lưu ý rằng, tương tự như
ví dụ về khoản trả trước, yêu cầu phải có transaction_id trong thông báo này.
Ngoài ra, xin lưu ý rằng booking_id được đặt trong
CreateBookingResponse
là trường bắt buộc cho thông tin cập nhật theo thời gian thực phải được gửi khi sạc
không phải trả phí tham dự. Mã nhận dạng này được dự kiến được lưu trữ cùng với thông tin
về việc đặt phòng.
Cập nhật theo thời gian thực
Nếu người dùng không đến theo lịch đặt chỗ hoặc huỷ sau thời gian 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 chỉ đị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 bắt buộc phải gửi Thông tin cập nhật theo thời gian thực nêu rõ rằng bạn đã tính phí vắng mặt.
Đối với các lượt đặt trước được tạo bởi
CreateBooking, bản cập nhật sẽ được gửi tới
notification.partners.bookings.patch. Trong phần nội dung của yêu cầu này phải
lượt đặt phòng được cập nhật, với trạng thái được đặt thành
NO_SHOW_PENALIZED. Trạng thái này cho Google biết rằng một khoản phí đã
đã thực hiện.
Ví dụ: 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"
}
Khoản tiền gửi
Khoản tiền gửi được sử dụng để thu khoản phí ban đầu như một yêu cầu cho đặt chỗ. Bạn có thể phải đặt cọc tại thời điểm đặt phòng hoặc sau đó bất cứ lúc nào. Bạn có thể cần phải xác định điều khoản mà khoản tiền gửi có thể được hoàn lại cũng như khi một lượt đặt trước có thể bị huỷ trên mạng.
Để chỉ định một khoản tiền gửi, trong nguồn cấp dữ liệu dịch vụ, bạn phải thêm
Trường deposit như trong ví dụ bên dưới:
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, phương thức
min_advance_online_canceling xác định cửa sổ huỷ và
deposit.min_advance_cancellation_sec
xác định thời điểm khoản tiền gửi 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ỷ tách biệt với điều khoản hoàn tiền. Trong trường hợp này, người dùng sẽ có thể huỷ
dịch vụ trực tuyến trước tối đa 24 giờ (86400 giây). Điều này đảm bảo rằng người bán
thông báo trực tiếp về bất kỳ trường hợp huỷ trễ nào. Tuy nhiên, người dùng vẫn có thể
đủ điều kiện được hoàn lại tiền đặt cọc trước tối đa 4 giờ
(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ỷ yêu cầu),
Thông tin này sẽ xuất hiện trong các điều khoản khi thanh toán và trong email xác nhận.
Để xem cách xác định khoản tiền gửi ở cấp độ khả dụng, hãy xem phần này.
Máy chủ đặt phòng
Khi xử lý yêu cầu có chứa khoản tiền gửi, mã thông báo thanh toán sẽ
được chuyển đến máy chủ đặt phòng của bạn trong lệnh gọi đến
CreateBooking thông qua trường này
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. Nếu bạn
tính phí tiền đặt cọc hoặc rút tiền tạm giữ tại thời điểm đặt phòng, bạn có thể làm như vậy
trong yêu cầu này.
Nếu bạn định tính phí khoản tiền gửi vào lúc khác, vì mã thông báo chỉ được cấp quyền trong một khoảng thời gian ngắn, bạn phải gọi API phù hợp của công ty xử lý thanh toán để nâng cấp mã thông báo này thành mà bạn có thể duy trì để sử dụng sau này. Đây là được mô tả trong phần hướng dẫn Bật tính năng thanh toán trên quy trình mã thông báo gửi tiền.
Khi trả lại một
CreateBookingResponse trường booking.payment_information phải
lặp lại đúng 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 thử này được đặt để phản ánh giá và cấu trúc của
khoản tiền gửi sẽ bị tính phí hoặc bị giữ lại. Ngoài ra, xin lưu ý rằng, tương tự như
ví dụ về khoản trả trước, yêu cầu phải có transaction_id trong thông báo này.
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 gửi mà bạn đã tính vào thẻ người dùng. Thời gian hoàn lại một khoản tiền đặt cọc, bạn sẽ phải gửi Cập nhật theo thời gian thực chỉ định rằng khoản tiền gửi đã được hoàn lại.
Đối với các lượt đặt trước được tạo bởi
CreateBooking, bản cập nhật sẽ được gửi tới
notification.partners.bookings.patch. Nội dung chính của tài liệu này
yêu cầu phải là lượt đặt phòng đã cập nhật, với trạng thái được đặt thành
CANCELED và
Đã đặt trường paymentInformation.prepaymentStatus thành
PREPAYMENT_REFUNDED. Điều này thông báo cho Google rằng khoản tiền gửi đã
đã hoàn tiền.
Ví dụ: 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 làm thẻ xác minh danh tính của người dùng. Tuy nhiên, không nên sử dụng đối với phí trả trước, đặt cọc hoặc phí vắng mặt. Nếu những trường hợp sử dụng đó bắt buộc, chúng phải được định cấu hình rõ ràng bằng cách sử dụ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 giảm đáng kể số lượt đặt phòng cho dịch vụ này.
Để yêu cầu cung cấp thẻ tín dụng khi thanh toán, bạn phải đặt
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ý yêu cầu có bao gồm yêu cầu về thẻ tín dụng, khoản thanh toán
mã thông báo được chuyển đến máy chủ đặt chỗ trong lệnh gọi đến
CreateBooking thông qua trường này
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 phương thức thanh toán trước
trường hợp. Tuy nhiên, vì mã thông báo này chỉ được cấp phép trong một khoảng thời gian ngắn
bạn phải gọi API tương ứng 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ể tiếp tục sử dụng tại
lúc khác.
Không cần thêm thông tin trong phản hồi của máy chủ Đặt phòng ngoài trường hợp sử dụng trả tiền khi đến nơi.
Ghi đè giá ở cấp tình trạng còn hàng
Trong tất cả ví dụ trên, cấu trúc giá / phí được chỉ định ở cấp Dịch vụ. Trong hầu hết các trường hợp, mức giá ở cấp dịch vụ này đã sử dụng. Tuy nhiên, trong một số trường hợp, bạn nên thay đổi cấu trúc thanh toán cho một số khung giờ trống nhất định. Ví dụ: những trường hợp sau có thể xử lý bằng cách ghi đè giá / phí ở cấp độ sẵn có:
- Giá giảm vào thứ Ba và tăng vào thứ Bảy.
- Thời gian trống từ 17:00 đến 19:00 không áp dụng phí chương trình.
Bảng dưới đây liệt kê những trường cần nhập vào từng phương thức thanh toán / phí dùng trong nguồn cấp dữ liệu về tình trạng còn hàng để thay thế định nghĩa về 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
Merchant.payment_option
|
| Trả Tiền Trước | Service.price
|
Có thể ghi đè giá thông qua
Availability.payment_option_id tham chiếu
Merchant.payment_option
|
| Phí vắng mặt | Service.no_show_fee
|
Availability.no_show_fee
|
| Khoản tiền gửi | Service.deposit
|
Availability.deposit
|
| Cần có 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, để được hướng dẫn về cách thêm thời hạn huỷ ở mức độ sẵn có, vui lòng xem hướng dẫn Cách thêm cửa sổ huỷ.