Câu hỏi thường gặp về việc thanh toán RCS cho Doanh nghiệp

RCS cho Doanh nghiệp sử dụng 2 mô hình thanh toán: mô hình thanh toán tiêu chuẩn cho lưu lượng truy cập bên ngoài Hoa Kỳ và mô hình thanh toán tại Hoa Kỳ cho lưu lượng truy cập tại Hoa Kỳ. Tài liệu này giải đáp các câu hỏi thường gặp về mô hình thanh toán tiêu chuẩn. Để biết thông tin chi tiết về các phân loại thanh toán ở Hoa Kỳ, hãy tham khảo hướng dẫn về mô hình thanh toán ở Hoa Kỳ.

Danh mục thanh toán

Danh mục thanh toán của nhân viên hỗ trợ là gì?

Danh mục thanh toán là một phân loại cho nhân viên hỗ trợ RCS for Business, cho biết logic thanh toán đối với những tin nhắn mà nhân viên hỗ trợ của bạn gửi. Bạn chọn danh mục này khi tạo nhân viên hỗ trợ và không thể thay đổi sau này.

Hai danh mục thanh toán chính được mô tả trong bảng sau.

Lưu ý: Bất kể danh mục tính phí là gì, nhân viên hỗ trợ vẫn có thể gửi mọi loại tin nhắn.

Danh mục thanh toán	Loại nhân viên hỗ trợ	Ví dụ về các trường hợp sử dụng	Phương thức thanh toán
Không liên quan đến hoạt động trò chuyện	Những tác nhân chủ yếu gửi tin nhắn một chiều	OTP Cảnh báo Khuyến mại	Tính phí theo từng tin nhắn.
Trò chuyện	Nhân viên hỗ trợ được thiết kế để trao đổi qua lại với người dùng	Tìm sản phẩm phù hợp Đặt vé Khắc phục sự cố	Tính phí theo mỗi cuộc trò chuyện: Nếu một bên (nhân viên hỗ trợ hoặc người dùng) trả lời tin nhắn của bên kia trong vòng 24 giờ, thì một cuộc trò chuyện sẽ bắt đầu. Trong cửa sổ trò chuyện (24 giờ sau lượt trả lời đầu tiên), nhân viên hỗ trợ và người dùng có thể trao đổi bao nhiêu tin nhắn tuỳ ý và nhân viên hỗ trợ sẽ bị tính phí cố định cho cuộc trò chuyện. Tính phí theo từng tin nhắn: Nếu nhân viên hỗ trợ gửi một tin nhắn mà người dùng không trả lời trong vòng 24 giờ, thì nhân viên hỗ trợ sẽ bị tính phí cho từng tin nhắn, tương tự như nhân viên hỗ trợ không trò chuyện.

Làm cách nào để biết tôi nên chọn danh mục thanh toán nào cho đại lý của mình?

Có hai danh mục thanh toán chính: đàm thoại và không đàm thoại.

• Các tác nhân không đàm thoại sẽ bị tính phí cho mỗi tin nhắn mà họ gửi cho người dùng.
  • Danh mục này phù hợp nhất với những trợ lý ảo không cần phản hồi thường xuyên.
• Các tác nhân đàm thoại được tính phí cố định cho cuộc trò chuyện, bao gồm tất cả tin nhắn được trao đổi trong khoảng thời gian 24 giờ.
  • Danh mục này phù hợp nhất với những tác nhân tham gia vào các cuộc trò chuyện nhiều lượt với người dùng.

Lưu ý: Để đơn giản hoá cấu trúc thanh toán, chúng tôi đã hợp nhất các danh mục thanh toán Tin nhắn cơ bản và Tin nhắn đơn lẻ cũ thành một danh mục thanh toán Không phải là tin nhắn hội thoại duy nhất. Developer Console đã được cập nhật và hiện hiển thị danh mục hợp nhất này cho tất cả các tác nhân mới. Xem chủ đề Danh mục thanh toán không mang tính trò chuyện để biết thông tin chi tiết về việc di chuyển các tác nhân hiện có và cửa sổ tích hợp API.

Chọn danh mục thanh toán phù hợp nhất với trường hợp sử dụng và mức độ tương tác dự kiến của người dùng. Nhân viên hỗ trợ có thể gửi mọi loại tin nhắn, bất kể danh mục.

Lý do là vì danh mục thanh toán xác định cách tính phí tin nhắn, chứ không phải loại tin nhắn mà nhân viên hỗ trợ có thể gửi. Ví dụ: một Conversational agent (Tác nhân đàm thoại) vẫn có thể gửi tin nhắn cơ bản và một Non-conversational agent (Tác nhân không đàm thoại) có thể gửi nhiều tin nhắn, bao gồm cả thẻ đa phương tiện.

Danh mục thanh toán không liên quan đến hoạt động trò chuyện

Việc hợp nhất danh mục Tin nhắn cơ bản và Tin nhắn đơn lẻ thành một danh mục Không mang tính trò chuyện ảnh hưởng như thế nào đến các tác nhân của tôi?

Vào ngày 20 tháng 11 năm 2025, chúng tôi đã đơn giản hoá cấu trúc tính phí bằng cách kết hợp 2 danh mục tính phí cũ là Tin nhắn cơ bản và Tin nhắn đơn thành một danh mục tính phí Không mang tính trò chuyện.

Quan trọng: Bản cập nhật này không ảnh hưởng đến các sự kiện thanh toán mà trợ lý ảo của bạn tạo ra. Vì các danh mục cũ có cùng một cách tính phí, nên thay đổi này là việc hợp nhất các nhãn chứ không phải thay đổi cách tính phí đối với bạn.

Kể từ bây giờ, mọi trợ lý ảo sẽ được phân loại là Đàm thoại hoặc Không đàm thoại.

Thay đổi này ảnh hưởng đến RcsBusinessMessagingAgentBillingConfig và áp dụng cho tất cả nhà phát triển sử dụng Developer Console hoặc Management API, cũng như tất cả hãng vận chuyển sử dụng Operations API.

Người dùng API có thời gian chuyển đổi là 90 ngày (cho đến ngày 18 tháng 2 năm 2026) để tích hợp danh mục mới trên các hệ thống của bạn. Để biết đầy đủ thông tin chi tiết về kế hoạch chuyển đổi, bao gồm cả khả năng tương thích ngược của API và các thay đổi được đề xuất đối với mã, hãy xem các phần sau.

Di chuyển tác nhân hiện có (bạn không cần làm gì cả)

Nhóm hỗ trợ sẽ tự động xử lý việc di chuyển:

• Tất cả các tác nhân được phân loại là Tin nhắn cơ bản hoặc Tin nhắn đơn sẽ được phân loại lại thành Không mang tính trò chuyện trong khoảng thời gian chuyển đổi 90 ngày.
• Bạn sẽ nhận được thông báo 30 ngày trước khi quá trình di chuyển các trợ lý hiện có diễn ra.

Developer Console (Nhà phát triển)

• Các tác nhân hiện có: Developer Console sẽ tiếp tục hiển thị các danh mục Tin nhắn cơ bản và Tin nhắn đơn cũ cho các tác nhân hiện có cho đến hết ngày 18 tháng 2 năm 2026.
• Nhân viên hỗ trợ mới: Bạn sẽ chỉ có thể tạo nhân viên hỗ trợ mới dưới dạng Đàm thoại hoặc Không đàm thoại.

Management API (Nhà phát triển)

• Khả năng tương thích ngược: Management API sẽ hỗ trợ và trả về cả giá trị BASIC_MESSAGE và SINGLE_MESSAGE cũ và giá trị NON_CONVERSATIONAL mới trong quá trình chuyển đổi kéo dài 90 ngày.
• Việc cần làm: Cập nhật logic của tác nhân để sử dụng giá trị NON_CONVERSATIONAL mới trước ngày 18 tháng 2 năm 2026.

Operations API (Hãng vận chuyển)

• Khả năng tương thích ngược: Để tránh gián đoạn, Operations API sẽ trả về giá trị SINGLE_MESSAGE cũ cho những tác nhân được đánh dấu là NON_CONVERSATIONAL trong quá trình chuyển đổi kéo dài 90 ngày.
• Việc cần làm: Cập nhật hệ thống của bạn để xử lý giá trị NON_CONVERSATIONAL mới trước ngày 18 tháng 2 năm 2026.
• Áp dụng sớm: Các hãng vận chuyển có thể liên hệ với Nhóm hỗ trợ để chọn nhận enum NON_CONVERSATIONAL mới trước ngày 18 tháng 2 năm 2026. Khi được chọn sử dụng, các tác nhân được định cấu hình dưới dạng NON_CONVERSATIONAL (thông qua Developer Console hoặc Management API) sẽ trả về giá trị NON_CONVERSATIONAL trong Operations API.

Sự kiện có thể lập hóa đơn

Sự kiện có thể lập hoá đơn là gì?

Sự kiện có tính phí là những lượt tương tác giữa một nhân viên RCS cho doanh nghiệp và một người dùng được theo dõi cho mục đích thanh toán. Các sự kiện được phân loại dựa trên loại thông báo và thời gian tương tác.

Google theo dõi và báo cáo những sự kiện này để giúp hãng vận chuyển tính phí đối tác cho những tin nhắn do nhân viên của họ gửi.

Những sự kiện có tính phí nào áp dụng cho từng loại thông báo?

Lưu ý: Các sự kiện trong phần này chỉ áp dụng cho mô hình thanh toán tiêu chuẩn (lưu lượng truy cập không phải ở Hoa Kỳ). Để tìm hiểu về các sự kiện có tính phí đối với lưu lượng truy cập ở Hoa Kỳ, hãy tham khảo hướng dẫn về mô hình thanh toán ở Hoa Kỳ.

Có 5 loại sự kiện có tính phí được ghi lại trong báo cáo thanh toán. Các sự kiện này bao gồm sự kiện MT và MO, được gọi là sự kiện A2P và P2A.

• A2P (Ứng dụng đến người dùng) là MT (Mobile Terminated): Tin nhắn do doanh nghiệp gửi.
• P2A (Người dùng đến ứng dụng) là MO (Mobile Originated): Một thông báo hoặc hành động do người dùng bắt đầu.

Bảng sau đây mô tả từng sự kiện có tính phí khi áp dụng cho các tác nhân không đàm thoại và đàm thoại.

Loại sự kiện	Nội dung mô tả	Nhân viên hỗ trợ không trò chuyện	Nhân viên hỗ trợ trò chuyện
basic_message	Tin nhắn A2P chỉ chứa văn bản có tối đa 160 ký tự. Xem ví dụ.	Luôn được coi là một sự kiện riêng lẻ có tính phí, bất kể người dùng có trả lời hay không.	Được coi là một sự kiện riêng lẻ có tính phí, trừ phi người dùng trả lời trong vòng 24 giờ. Trong trường hợp đó, tin nhắn sẽ trở thành một phần của a2p_conversation.
single_message	Tin nhắn A2P có nội dung đa dạng hoặc chỉ có văn bản dài hơn 160 ký tự. Xem ví dụ	Luôn được coi là một sự kiện riêng lẻ có tính phí, bất kể người dùng có trả lời hay không.	Được coi là một sự kiện riêng lẻ có tính phí, trừ phi người dùng trả lời trong vòng 24 giờ. Trong trường hợp đó, tin nhắn sẽ trở thành một phần của a2p_conversation.
a2p_conversation (do doanh nghiệp bắt đầu)	Được bắt đầu khi người dùng trả lời một tin nhắn A2P trong vòng 24 giờ kể từ khi nhận được tin nhắn đó, bên ngoài một cuộc trò chuyện hiện có. Xem ví dụ.	Không có. Các tác nhân không đàm thoại sẽ không bao giờ tạo loại sự kiện này.	Nếu một tin nhắn P2A được gửi trong vòng 24 giờ sau nhiều tin nhắn A2P, thì chỉ tin nhắn A2P ngay trước tin nhắn P2A được dùng để bắt đầu cuộc trò chuyện. Thông báo A2P này và mọi thông báo được gửi trong vòng 24 giờ tới đều thuộc a2p_conversation.
p2a_conversation (do người dùng tiến hành)	Được bắt đầu khi nhân viên hỗ trợ trả lời tin nhắn P2A trong vòng 24 giờ kể từ khi nhận được tin nhắn đó, bên ngoài một cuộc trò chuyện hiện có. Xem ví dụ.	Không có. Các tác nhân không đàm thoại sẽ không bao giờ tạo loại sự kiện này.	Nếu một tin nhắn A2P được gửi trong vòng 24 giờ sau nhiều tin nhắn P2A, thì chỉ tin nhắn P2A ngay trước tin nhắn A2P được dùng để bắt đầu cuộc trò chuyện. Thông báo P2A này và mọi thông báo được gửi trong vòng 24 giờ tiếp theo đều thuộc p2a_conversation.
p2a_message	Thông báo P2A thuộc mọi loại. Xem ví dụ.	Luôn được coi là một sự kiện có tính phí riêng lẻ, bất kể trợ lý có trả lời hay không.	Được coi là một sự kiện có tính phí riêng lẻ, trừ phi nhân viên hỗ trợ trả lời trong vòng 24 giờ.

Đâu là ví dụ về những thông báo kích hoạt từng sự kiện thanh toán?

Thông báo cơ bản

Xin lưu ý rằng ảnh chụp màn hình sau đây cho thấy bản xem trước URL trong tin nhắn văn bản. Đây không phải là thẻ thông tin chi tiết.

Thông báo đơn lẻ

A2P hội thoại

Thông báo P2A

Cuộc trò chuyện P2A

Lợi ích của từng sự kiện thanh toán là gì?

Thông báo cơ bản

Các lợi ích chính của Thông báo cơ bản:

• Xây dựng niềm tin: Thông tin xác minh và thương hiệu giúp tạo dựng niềm tin và uy tín.
• Xem trước URL: Tin nhắn cơ bản có thể chứa văn bản và hình ảnh xem trước URL có thể nhấp.
• Chương trình khuyến mãi chiến thuật một lần: Phù hợp với các chương trình khuyến mãi ngắn hạn hoặc thông báo thông tin không yêu cầu người dùng phản hồi.
• Tăng lưu lượng truy cập: Basic Messages có thể hướng người dùng đến ứng dụng, trang web hoặc các tài nguyên khác của thương hiệu.

Thông báo đơn lẻ

Lợi ích chính của một Thông báo duy nhất:

• Tác động về mặt hình ảnh: Đồ hoạ chất lượng cao thu hút sự chú ý và làm rõ các lựa chọn, từ đó tăng mức độ tương tác của người dùng.
• Một thẻ, nhiều hành động: Thẻ đa phương tiện hoặc băng chuyền có thể thúc đẩy nhiều hành động bằng đề xuất để tạo sự kiện trên lịch, tìm vị trí, quay số hoặc mở một URL – tất cả đều từ một tin nhắn duy nhất.
• Giá trị rõ ràng, thông điệp ngắn gọn: Khuyến khích người dùng thực hiện bước tiếp theo.

Trò chuyện

Lợi ích chính của cuộc trò chuyện A2P và P2A:

• Tích hợp nội dung đa phương tiện: Kết hợp nhiều nội dung nghe nhìn, chẳng hạn như hình ảnh, video và tệp PDF, cũng như các hành động và câu trả lời được đề xuất.
• Tương tác được cá nhân hoá: Cho phép đối thoại qua lại, cung cấp thông tin trợ giúp phù hợp và đề xuất sản phẩm.
• Cơ hội chuyển đổi: Cho phép người dùng thực hiện hành động trong cuộc trò chuyện, giảm sự phiền hà và tăng tỷ lệ chuyển đổi.

Danh mục thanh toán của nhân viên hỗ trợ có liên quan như thế nào đến sự kiện thanh toán?

Bạn không nên nhầm lẫn các sự kiện thanh toán basic_message và single_message với các danh mục thanh toán Tin nhắn cơ bản và Tin nhắn đơn.

• Mọi nhân viên hỗ trợ (bất kể danh mục thanh toán) đều có thể tạo sự kiện thanh toán basic_message và single_message.
• Danh mục thanh toán Tin nhắn cơ bản và Tin nhắn đơn được dùng để phân loại các tác nhân không đàm thoại. Các tác nhân trong những danh mục tính phí này không tạo ra sự kiện tính phí dựa trên cuộc trò chuyện (a2p_conversations hoặc p2a_conversations). Thay vào đó, chúng tạo ra các sự kiện tính phí riêng lẻ basic_message, single_message và p2a_message.

Cuộc trò chuyện là gì?

Trong RCS cho Doanh nghiệp, cuộc trò chuyện là một chuỗi tin nhắn được trao đổi giữa người dùng và nhân viên hỗ trợ đàm thoại trong khoảng thời gian 24 giờ. Chỉ những tác nhân có danh mục Thanh toán theo cuộc trò chuyện mới có thể tạo cuộc trò chuyện và bị tính phí cho những sự kiện có tính phí sau đây:

• A2P (Ứng dụng đến người dùng): Do doanh nghiệp gửi.
• P2A (Người dùng đến ứng dụng): Do người dùng gửi.

Cách hoạt động của cuộc trò chuyện

• Bắt đầu: Cuộc trò chuyện bắt đầu khi một bên (nhân viên hỗ trợ hoặc người dùng) phản hồi tin nhắn của bên kia trong vòng 24 giờ kể từ khi nhận được tin nhắn, ngoài bất kỳ cuộc trò chuyện nào đang diễn ra.
  • Cuộc trò chuyện A2P: Bắt đầu khi người dùng phản hồi tin nhắn của nhân viên hỗ trợ.
  • Cuộc trò chuyện P2A: Bắt đầu khi nhân viên hỗ trợ phản hồi tin nhắn của người dùng.
• Cửa sổ trò chuyện: Cuộc trò chuyện vẫn hoạt động trong 24 giờ sau khi bắt đầu. Cuộc trò chuyện bao gồm tất cả tin nhắn trong khoảng thời gian 24 giờ này, cũng như tin nhắn đầu tiên được trả lời ban đầu.
• Thanh toán: Thay vì tính phí cho từng tin nhắn riêng lẻ, các tác nhân đàm thoại sẽ được tính phí dựa trên toàn bộ cuộc trò chuyện. Điều này có nghĩa là chi phí được liên kết với chuỗi hội thoại, chứ không phải số lượng tin nhắn trong chuỗi đó.

Sơ đồ sau đây minh hoạ ví dụ về một phiên tính phí A2P cho các tác nhân đàm thoại:

Lưu ý quan trọng

• Cuộc trò chuyện không áp dụng cho các tác nhân không đàm thoại. Những tác nhân có danh mục thanh toán Tin nhắn cơ bản hoặc Tin nhắn đơn lẻ sẽ bị tính phí theo từng tin nhắn, bất kể người dùng có trả lời hay không.
• Đối với các tác nhân đàm thoại, việc tạo báo cáo sự kiện thanh toán và nhật ký hoạt động có thể bị trễ tối đa 2 ngày. Độ trễ này cho phép RCS cho Doanh nghiệp ghi lại tất cả tin nhắn trong một cuộc trò chuyện trước khi tính toán sự kiện thanh toán.

Những sự kiện thanh toán nào được tạo nếu nhân viên hỗ trợ gửi nhiều tin nhắn trước khi người dùng trả lời?

Danh mục thanh toán của trợ lý ảo và thời gian trả lời của người dùng sẽ xác định loại sự kiện được tạo.

Đối với các tác nhân không đàm thoại: Mỗi thông báo sẽ tạo ra sự kiện riêng

• Tin nhắn của nhân viên hỗ trợ tạo ra sự kiện basic_message hoặc single_message.
• Thông báo của người dùng sẽ tạo ra một sự kiện p2a_message.

Đối với nhân viên hỗ trợ đàm thoại: Kết quả phụ thuộc vào thời điểm người dùng trả lời tin nhắn cuối cùng của nhân viên hỗ trợ

• Nếu người dùng trả lời trong vòng 24 giờ:
  • Một sự kiện a2p_conversation bắt đầu. Sự kiện này bao gồm tin nhắn cuối cùng của nhân viên hỗ trợ, câu trả lời của người dùng và tất cả tin nhắn trao đổi trong khoảng thời gian 24 giờ sau câu trả lời của người dùng.
  • Mọi thông báo của tác nhân được gửi trước thông báo cuối cùng của tác nhân đều không thuộc cuộc trò chuyện; mỗi thông báo sẽ tạo ra sự kiện basic_message hoặc single_message riêng.
• Nếu người dùng trả lời sau 24 giờ:
  • Mỗi tin nhắn của nhân viên hỗ trợ sẽ tạo ra một sự kiện basic_message hoặc single_message.
  • Câu trả lời của người dùng sẽ tạo ra một sự kiện p2a_conversation nếu trợ lý phản hồi trong vòng 24 giờ. Nếu tác nhân không phản hồi trong khung thời gian đó, thì sự kiện p2a_message sẽ được tạo.

Những phản hồi nào của người dùng góp phần tạo nên sự kiện thanh toán?

Chỉ những phản hồi cụ thể của người dùng mới đóng góp vào sự kiện thanh toán. Những phản hồi này bao gồm phản hồi tạo sự kiện p2a_message hoặc là một phần của sự kiện a2p_conversation hoặc p2a_conversation. Bảng sau đây làm rõ những phản hồi của người dùng góp phần tạo nên các sự kiện thanh toán.

Lưu ý: Các hãng vận chuyển quyết định xem có tính phí các sự kiện p2a_message và p2a_conversation hay không và tính phí như thế nào. Các sự kiện này được đưa vào báo cáo thanh toán để đảm bảo tính minh bạch và cho phép hãng vận chuyển theo dõi mức độ tương tác của người dùng.

Sau đây là bản tóm tắt:

Phản hồi của người dùng	Đóng góp vào các sự kiện thanh toán	Ghi chú
Gửi tệp	Có	Được coi là tin nhắn do thiết bị di động gửi (MO).
Gửi tin nhắn văn bản	Có	Được coi là một tin nhắn MO.
Nhấn vào một câu trả lời được đề xuất	Có	Được coi là một tin nhắn MO.
Nhấn vào một hành động được đề xuất	Không	Dữ liệu đăng lại từ chính thao tác nhấn không góp phần tạo ra một sự kiện thanh toán.
Chia sẻ vị trí	Có	Tin nhắn MO chứa vị trí của người dùng sẽ góp phần tạo ra một sự kiện thanh toán. Điều này áp dụng cho cả trường hợp vị trí được chia sẻ theo cách thủ công hoặc thông qua hành động được đề xuất.
Nhấn vào Huỷ đăng ký hoặc Đăng ký	Có	Sự kiện webhook thu được không được tính là một sự kiện thanh toán, nhưng thông báo DỪNG hoặc BẮT ĐẦU tự động được gửi khi người dùng nhấn vào lựa chọn Huỷ đăng ký hoặc Đăng ký được coi là một thông báo MO.

Khi một câu trả lời của người dùng tạo ra một sự kiện có tính phí (như mô tả ở trên), loại sự kiện sẽ phụ thuộc vào danh mục thanh toán của tác nhân.

Đối với các tác nhân không đàm thoại:

• Sự kiện thanh toán do phản hồi của người dùng tạo ra luôn là p2a_message.

Đối với nhân viên hỗ trợ trò chuyện:

Loại sự kiện cũng được xác định theo thời gian gửi tin nhắn trong khoảng thời gian 24 giờ.

• Khi người dùng phản hồi tin nhắn của nhân viên hỗ trợ:
  • Trong vòng 24 giờ: Câu trả lời của người dùng sẽ góp phần vào một sự kiện a2p_conversation hiện có.
  • Sau 24 giờ: Câu trả lời của người dùng sẽ tạo ra một sự kiện p2a_message mới.
• Khi nhân viên hỗ trợ phản hồi tin nhắn của người dùng:
  • Trong vòng 24 giờ: Câu trả lời của nhân viên hỗ trợ sẽ tạo ra một p2a_conversation, bắt đầu bằng tin nhắn ban đầu của người dùng.
  • Sau 24 giờ: Tin nhắn của người dùng sẽ tạo ra một sự kiện p2a_message.

Báo cáo thanh toán

Báo cáo thanh toán là gì?

Đây là bản ghi về các sự kiện có tính phí, được tính dựa trên danh mục thanh toán của tác nhân và các loại thông báo mà tác nhân gửi. Tất cả những nhà mạng đang tích cực vận hành RCS cho doanh nghiệp đều có thể sử dụng báo cáo thanh toán.

Để biết thêm thông tin về báo cáo thanh toán, hãy xem bài viết Báo cáo sự kiện thanh toán và nhật ký hoạt động.

Tôi có thể nhận báo cáo thanh toán không?

Chỉ những nhà mạng đang vận hành RCS cho Doanh nghiệp mới nhận được báo cáo thanh toán. Đối tác không nhận được báo cáo thanh toán.

Để tìm hiểu cách nhận báo cáo thanh toán, hãy xem phần Lưu trữ và truy cập vào tệp. Đây là hướng dẫn về cách truy xuất báo cáo thanh toán bằng Giao thức truyền tệp bảo mật (SFTP) dành cho những hãng vận chuyển có quyền truy cập vào báo cáo thanh toán.

Điều gì sẽ xảy ra nếu báo cáo thanh toán bị thiếu thông tin?

Nếu bạn nhận thấy báo cáo bị thiếu một số thông tin, hãy khắc phục vấn đề này với Nhóm hỗ trợ. Để biết thêm thông tin, hãy tham khảo hướng dẫn khắc phục sự cố về RCS cho doanh nghiệp.

Tại sao tôi thấy các khoản phí trong một tháng mà tôi không gửi tin nhắn nào?

Sự kiện thanh toán RCS dành cho doanh nghiệp được ghi lại dựa trên thời gian gửi tin nhắn, chứ không phải thời gian tin nhắn được gửi.

Ví dụ:

Bạn gửi tin nhắn vào cuối tháng 6, nhưng tin nhắn được gửi đến thiết bị của người dùng vào đầu tháng 7 (ví dụ: nếu điện thoại của người dùng không kết nối mạng), thì những khoản phí đó sẽ xuất hiện trong báo cáo thanh toán tháng 7 của bạn. RCS cho Doanh nghiệp sẽ cố gắng gửi một tin nhắn trong tối đa 30 ngày trước khi tin nhắn đó hết hạn.

Mô hình thanh toán

Những điểm khác biệt chính giữa mô hình thanh toán tiêu chuẩn và mô hình thanh toán ở Hoa Kỳ là gì?

Cả mô hình tiêu chuẩn và mô hình của Hoa Kỳ đều sử dụng danh mục thanh toán được chọn trước của nhân viên hỗ trợ (đàm thoại hoặc không đàm thoại) để xác định cấu trúc mức giá tổng thể. Điểm khác biệt chính là tập hợp các phân loại được dùng cho sự kiện có tính phí.

Mô hình thanh toán tiêu chuẩn (Lưu lượng truy cập không phải ở Hoa Kỳ)

Mô hình này áp dụng cho tất cả lưu lượng truy cập bên ngoài Hoa Kỳ.

• Việc phân loại dựa trên danh mục thanh toán của tác nhân và nội dung tin nhắn.
  • Tác nhân không đàm thoại: Tính phí theo từng tin nhắn. Nội dung tin nhắn xác định sự kiện: tin nhắn cơ bản hoặc tin nhắn đơn.
  • Nhân viên hỗ trợ đàm thoại: Tính phí theo cuộc trò chuyện. Cuộc trò chuyện là khoảng thời gian 24 giờ mà người dùng và nhân viên hỗ trợ có thể trao đổi tin nhắn không giới hạn, được tính phí theo mức cố định. Nếu người dùng không trả lời trong vòng 24 giờ, thì tin nhắn của nhân viên hỗ trợ sẽ được tính phí riêng lẻ dưới dạng tin nhắn cơ bản hoặc tin nhắn đơn.
• Sự kiện lập hoá đơn:
  • basic_message
  • single_message
  • a2p_conversation
  • p2a_conversation
  • p2a_message
• Logic thanh toán: Khoản phí cuối cùng được xác định theo danh mục thanh toán của tác nhân, dẫn đến mức phí cố định cho mỗi tin nhắn (không mang tính trò chuyện) hoặc mức phí cố định cho mỗi cửa sổ trò chuyện 24 giờ (mang tính trò chuyện).

Mô hình thanh toán ở Hoa Kỳ

Mô hình này áp dụng cho tất cả lưu lượng truy cập đến và đi từ số điện thoại ở Hoa Kỳ. Để biết thêm thông tin, hãy tham khảo hướng dẫn về mô hình thanh toán ở Hoa Kỳ.

• Việc phân loại từng thư và hành động của người dùng là tự động và dựa trên nội dung. Bất kể danh mục thanh toán của nhân viên hỗ trợ, mọi sự kiện có tính phí đều được phân loại là một trong những sự kiện sau:
  • Tin nhắn đa dạng thức (MT/MO)
  • Tin nhắn đa phương tiện (MT/MO)
  • Lượt nhấp vào hành động được đề xuất (chỉ dành cho thiết bị di động)
• Sự kiện lập hoá đơn:
  • a2p_rich_message
  • a2p_rich_media_message
  • p2a_rich_message
  • p2a_rich_media_message
  • suggested_action_click
• Logic thanh toán: Khoản phí cuối cùng được xác định theo danh mục thanh toán của nhân viên hỗ trợ, sử dụng các phân loại sự kiện có tính phí để áp dụng cấu trúc mức phí phù hợp.

Sự khác biệt về kỹ thuật và báo cáo

• RBM API: Các tài nguyên API AgentMessage và UserMessage bao gồm một đối tượng richMessageClassification để chỉ xác định loại thông báo cho lưu lượng truy cập ở Hoa Kỳ. Thông tin này được cung cấp theo thời gian thực khi có lệnh gọi API và tách biệt với báo cáo thanh toán sau này.
• Báo cáo thanh toán: Báo cáo thanh toán được điều chỉnh cho phù hợp với từng mô hình và có một cột type liệt kê các sự kiện có tính phí dành riêng cho mô hình đó. Báo cáo thanh toán tại Hoa Kỳ cũng có một cột segment_count, chỉ áp dụng cho Tin nhắn đa dạng.