Định cấu hình thanh toán

Nền tảng Đặt chỗ với Google hỗ trợ nhiều cấu hình để thanh toán. Hướng dẫn bật chế độ thanh toán trình bày các khía cạnh của quá trình tích hợp chung, áp dụng cho mọi hoạt động tích hợp thanh toán, bao gồm:

  1. Thiết lập nguồn cấp dữ liệu để thêm thông tin về tokenization_parameter
  2. Cập nhật máy chủ đặt vé để chấp nhận đối tượng payment_method_token
  3. Thông tin tổng quan về thông tin được trao đổi giữa người dùng, tính năng Đặt chỗ bằng Google, đối tác / người bán và đơn vị xử lý thanh toán.

Trong hướng dẫn này, chúng tôi sẽ giới thiệu chi tiết hơn về cách thiết lập nguồn cấp dữ liệu để chỉ định loại cấu hình thanh toán cho các người bán và dịch vụ của bạn.

  1. Không thanh toán / Thanh toán khi đến nơi
  2. Thanh toán trước đầy đủ
  3. Phí không có buổi chiếu / Phí huỷ
  4. Ký quỹ

Tất cả các trường hợp sử dụng cho việc thanh toán đều là phần mở rộng của trường hợp sử dụng không thanh toán/trả trước khi đến nơi (không yêu cầu cấu hình 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 để theo dõi trong máy chủ đặt phòng nhằm 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 các dịch vụ không yêu cầu thanh toán tại thời điểm đặt phòng, bạn không cần phải thiết lập cấu hình 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ở cho 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"
    }
}

Không cần phải định cấu hình thêm ngoài quá trình 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 rằng toàn bộ số tiền dịch vụ phải được thanh toán tại thời điểm đặt phòng.

Khoản thanh toán trước được chỉ định ở 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 đặt giá trị này cho REQUIRED như trong ví dụ dưới đây. Xin lưu ý rằng giá này được chỉ định giống như ví dụ về cách thanh toán khi đến nơi. Ở đây, vì chúng tôi đang đặt loại hình trả trước là bắt buộc, nên thẻ tín dụng sẽ được thu thập và bạn có thể 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 hình thức trả trước, mã thông báo thanh toán sẽ được chuyển đến máy chủ đặt phòng trong cuộc gọi đến CreateBooking thông qua trường payment_processing_parameters.unparsed_payment_method_token. Bạn phải tính chính xác số tiền quy đị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ệ đã 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 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 đúng cách việc trả trước đã được cung cấp và xử lý.

Thông số PaymentInformation chứa đầy đủ tài liệu cho tất cả các tùy chọn thông tin thanh toán. Dưới đây là ví dụ về cách xử lý khoản trả trước tối thiểu. Điều quan trọng là giá được trả về trong trường giá khớp chính xác với giá được chỉ định trong yêu cầu. Ngoài ra, nếu bạn chỉ định thuế suất trong nguồn cấp dữ liệu/yêu cầu thì thuế suất đó cũng phải được bao gồm 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 đó. Một đề xuất phù hợp cho mã giao dịch là mã giao dịch do 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í không đến

Người dùng có thể tính phí không đến nếu không tham gia lượt đặt phòng hoặc nếu họ huỷ sau thời hạn huỷ. Nếu bạn không chỉ định thời gian hủy, thì giá trị này sẽ mặc định là thời gian bắt đầu của khung giờ.

Để chỉ định phí không hiển thị, trong nguồn cấp dữ liệu dịch vụ, bạn nên thêm trường no_show_fee như trong 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 ở mức giá 25 USD như được chỉ định trong trường no_show_fee.fee.price_micros nếu người tham gia cuộc hẹn không tham dự cuộc hẹn. Chúng tôi 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 chỉ định trong trường scheduling_rules.min_advance_online_canceling.

Để biết cách xác định phí hiển thị ở cấp tình trạng rảnh/bận, hãy xem phần này.

Máy chủ đặt phòng

Khi xử lý một yêu cầu có phí không xuất hiện, mã thông báo thanh toán sẽ được chuyển đến máy chủ đặt phòng trong cuộc 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 này chỉ được uỷ quyền trong một khoảng thời gian ngắn nê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 lên một phiên bản mà bạn có thể tiếp tục sử dụng sau. Phần 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 mã thông báo không hiển thị phí.

Khi trả lại một CreateBookingResponse booking.payment_information phải đặt trường để lặp lại đúng cách trạng thái không tính phí 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 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, bạn phải cung cấp 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 đối với các nội dung cập nhật theo thời gian thực và phải được gửi khi tính phí không hiển thị. Dự kiến, mã nhận dạng này được lưu trữ cùng với thông tin về lượt đặt phòng.

Thông tin cập nhật theo thời gian thực

Nếu người dùng không đến được lịch hẹn đã đặt trước hoặc hủy sau thời gian hủy (ví dụ: bằng cách liên hệ trực tiếp với bạn), bạn có thể tùy ý tính phí không hiển thị bằng thông tin thanh toán đã lưu tại thời điểm đặt phòng. Khi tính phí không đến, bạn phải gửi Thông tin cập nhật theo thời gian thực để xác định rằng phí không đến.

Đối với các lượt đặt phòng do CreateBooking tạo, bản cập nhật sẽ được gửi đến notification.partners.bookings.patch. Trong nội dung của yêu cầu này, lượt đặt phòng sẽ được cập nhật và đặt trạng thái thành NO_SHOW_PENALIZED. Trạng thái này cho Google biết rằng bạn đã bị tính phí.

Ví dụ: hệ thống có thể gửi yêu cầu đế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 dùng để thu một khoản phí ban đầu theo yêu cầu đặt phòng. Khách có thể trả tiền đặt cọc tại thời điểm đặt phòng hoặc sau này. Bạn có thể cần xác định các điều khoản để nhận được một khoản tiền hoàn lại, cũng như thời điểm có thể huỷ một yêu cầu đặt phòng 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 nên bao gồ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, 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 khoản tiền hoàn lại. Xin lưu ý rằng trong ví dụ ở trên, một khoản tiền gửi có thể chỉ định thời gian hủy riêng biệt với các điều khoản hoàn tiền. Trong trường hợp này, người dùng sẽ có thể hủy 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 sẽ trực tiếp nhận được thông báo về mọi lượt giao hàng trễ. Tuy nhiên, người dùng vẫn có thể đủ điều kiện được hoàn tiền đối với khoản tiền đặt trước của họ cho tới 4 giờ trước (14400 giây) trước khi đặt phòng (bằng cách liên hệ với bạn hoặc với người bán để hủy), điều khoản sẽ hiển thị 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 độ sẵn có, hãy xem phần này.

Máy chủ đặt phòng

Khi xử lý yêu cầu chứa tiền đặt cọc, mã thông báo thanh toán sẽ được chuyển đến máy chủ đặt phòng của bạn trong cuộc 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. Nếu tính phí cho khoản tiền đặt cọc hoặc gỡ lệnh tạm ngưng tại thời điểm đặt phòng, thì bạn có thể thực hiện trong yêu cầu này.

Nếu bạn có ý định tính phí gửi sau, vì mã thông báo này chỉ được ủy 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 lên một phiên bản mà bạn có thể sử dụng sau. Phần 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 gửi mã thông báo.

Khi trả về 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 đặt để phản ánh giá và cấu trúc của khoản tiền gửi sẽ được tính phí hoặc giữ lại. Ngoài ra, xin lưu ý rằng tương tự như ví dụ về khoản trả trước, bạn phải cung cấp transaction_id trong thông báo này.

Thông tin cập nhật theo thời gian thực

Nếu người dùng huỷ yêu cầu đặt phòng trước thời hạn huỷ, thì bạn phải hoàn tiền cho những khoản tiền đã tính cho thẻ người dùng đó. Khi hoàn lại tiền đặt cọc, bạn phải gửi Cập nhật theo thời gian thực để thông báo rằng khoản tiền gửi đã được hoàn lại.

Đối với các lượt đặt phòng do CreateBooking tạo, bản cập nhật sẽ được gửi đến notification.partners.bookings.patch. Trong 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, trong đó trạng thái được đặt là CANCELED và trường paymentInformation.prepaymentStatus được đặt thành PREPAYMENT_REFUNDED. Thông báo này sẽ cho Google biết rằng khoản tiền hoàn lại này đã được hoàn lại.

Ví dụ: hệ thống có thể gửi yêu cầu đế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

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 thuộc tính này để trả trước, gửi tiền hoặc không trả phí hiển thị. Nếu bắt buộc phải có những trường hợp sử dụng này, bạn phải định cấu hình rõ ràng theo 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ẽ làm giảm đáng kể số lượt đặt trước dịch vụ này.

Để yêu cầu cung cấp thẻ tín dụng trong quá trình 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ý yêu cầu có yêu cầu thẻ tín dụng, mã thông báo thanh toán sẽ được chuyển đến máy chủ đặt phòng trong cuộc 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 này chỉ được uỷ quyền trong một khoảng thời gian ngắn nê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 lên một phiên bản mà bạn có thể tiếp tục sử dụng sau.

Không cần thêm thông tin trong phản hồi của máy chủ Đặt chỗ ngoài thông tin trong trường hợp sử dụng trả tiền.

Ghi đè giá ở cấp độ có sẵn

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, bạn nên sử dụng giá này ở cấp dịch vụ. 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ố khu vực rảnh/bận. Ví dụ: các trường hợp sau có thể được xử lý 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.
  • Không có phí chương trình áp dụng cho thời gian rảnh từ 5 giờ chiều đến 7 giờ tối.
  • Dịch vụ do nhà tạo mẫu cao cấp cung cấp đắt hơn so với dịch vụ cấp dưới.

Bảng bên dưới liệt kê định nghĩa trường dành cho mỗi phương thức thanh toán / phí để 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 Giá có thể ghi đè thông qua Availability.payment_option_id, tham chiếu đến Merchant.payment_option
Không có phí chương trình 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 để ghi đè giá ở cấp tình trạng còn hàng, trước tiên bạn phải xác định một cách thanh toán ở cấp người bán. Ngoài ra, để xem hướng dẫn về cách thêm thời hạn huỷ ở cấp phát, vui lòng xem hướng dẫn Cách thêm Thời hạn huỷ.