Trong Thanh toán thông thường của Google, Thanh toán qua nhà mạng được coi là một hình thức thanh toán được mã hoá (FOP), nghĩa là Google và Nhà tích hợp thanh toán sẽ trao đổi thông tin xác thực danh tính tài khoản một lần để thiết lập mã thông báo. Sau đó, mã thông báo này sẽ được trả lại cho Nhà tích hợp thanh toán để xác định tài khoản cần tính phí.
Các phương thức thanh toán khác cũng sử dụng phương thức mã hoá, vì vậy, chúng tôi đã trình bày thông tin tổng quan chung về Phương thức thanh toán được mã hoá và chủ yếu liên quan đến phương thức Thanh toán qua nhà mạng. Quy trình Xác thực, Liên kết, Mua hàng và Chuyển tiền đều được mô tả chi tiết hơn trong phần tổng quan đó. Trang này cung cấp thêm thông tin chi tiết trong ngữ cảnh dành riêng cho việc Thanh toán qua nhà mạng.
Các nhà mạng tham gia Google Standard Payments bằng cách triển khai các API gồm các quy trình sau:
| Flow | Nội dung mô tả | Tương đương thông số kỹ thuật DCB3 |
|---|---|---|
| Xác thực | Xác định và xác thực tài khoản của người dùng trong hệ thống của Nhà tích hợp thanh toán sẽ được dùng để thanh toán qua phương thức DCB | SMS-MO với GoogleUserToken |
| Mối liên kết | Trao đổi một mã thông báo tồn tại lâu dài mà Google và Bên tích hợp thanh toán có thể dùng để thực hiện thanh toán bằng tài khoản Công ty tích hợp thanh toán của người dùng | chấp thuận lệnh gọi lại người dùng bằng OperatorUserToken và Getprovideing() |
| FundsTransfer | Đồng bộ chuyển tiền ra khỏi tài khoản Công ty tích hợp thanh toán của người dùng. Chuyển trách nhiệm pháp lý cho Nhà tích hợp thanh toán | Các dòng Auth() và CHARGE trong các tệp yêu cầu hàng loạt |
| Hoàn tiền | Đồng bộ trả về một số hoặc tất cả quỹ đã liên kết Chuyển tiền trước đó đến tài khoản Công ty tích hợp thanh toán của người dùng. Chuyển trách nhiệm pháp lý cho Google | Dòng REFUND trong các tệp yêu cầu hàng loạt |
| Chuyển tiền | Khoản thanh toán dựa trên API, tốt nhất là dựa trên cơ sở hằng ngày | Tệp PDF hoá đơn hằng tháng, tệp thông tin chi tiết về hoá đơn hằng tháng, tệp đối chiếu hằng ngày |
| UpdateAssociatedAccount | Thông báo cho Google về các thay đổi đối với tài khoản Đơn vị tích hợp thanh toán của người dùng (ví dụ: giới hạn giao dịch hoặc trạng thái cấp phép) | Cuộc thăm dò GetCung cấp() |
| Lừa đảo | Thông báo cho Google về các giao dịch đã bị huỷ bỏ do có tranh chấp của người dùng. Dữ liệu này được dùng để cải thiện công cụ phát hiện rủi ro của Google, nhưng không ảnh hưởng đến trách nhiệm pháp lý về tiền | Không có |
So sánh tổng thể với thông số kỹ thuật DCB3
Quy cách của Google Payments Standard giải quyết các vấn đề tương tự mà Quy cách DCB3 giải quyết. Tuy nhiên, API này sử dụng nhiều công nghệ và thiết kế API để cải thiện giải pháp. Sau đây là những điểm khác biệt chính:
So sánh công nghệ ngăn xếp
Mọi hoạt động giao tiếp qua API đều được thực hiện bằng cách sử dụng yêu cầu POST qua HTTPS với JSON được mã hoá bằng PGP và có chữ ký. Điều này có nghĩa là mỗi Google và Nhà tích hợp thanh toán chỉ có một khoá PGP để xoay vòng. Những công nghệ này cũng được hỗ trợ tốt hơn SOAP. Bạn có thể xem thêm thông tin chi tiết về ngăn xếp giao tiếp tại đây.
So sánh triết lý API
DCB3 chủ yếu dựa vào các tệp để điều chỉnh trạng thái thanh toán. Google Standard Payments không có tệp nào. Các lệnh gọi API sẽ được thử lại vô thời hạn cho đến khi trạng thái cuối cùng được xác định.
Các trạng thái cuối cùng thực sự là cuối cùng đối với một khoá không thay đổi giá trị nhận dạng cụ thể. Lỗi và trạng thái không xác định không được mô hình hoá dưới dạng giảm mà là phản hồi HTTP không phải 200. Điều này cho phép chúng tôi phát hiện lỗi nhanh hơn và tránh việc ẩn đi dưới dạng từ chối.
Tính năng mới
Thanh toán chuẩn của Google hỗ trợ các tính năng mới, bao gồm:
- Gian lận API để thông báo cho công cụ rủi ro của Google về những kẻ lừa đảo
- Cập nhật Associated Account API (API Tài khoản liên kết) để thông báo cho Google về việc cấp phép, giới hạn giao dịch và các thay đổi về trạng thái tài khoản
- Hỗ trợ thêm nhiều quy trình xác thực trong khi mua hàng, chẳng hạn như mã PIN USSD
- Chu kỳ chuyển tiền hằng ngày
Bản đồ thuật ngữ liên quan đến phương thức thanh toán chuẩn DCB3 của Google
Trong tài liệu này và thông số kỹ thuật, bạn sẽ thấy những thuật ngữ có vẻ mới nhưng thực ra chỉ là các từ khác cho các khái niệm hiện có.
- Nhà mạng -> Nhà tích hợp thanh toán
CẢNH BÁO: Để tránh nhầm lẫn với khái niệm nhà tích hợp DCB, tài liệu này cố gắng sử dụng "Trình tích hợp thanh toán" và "trình tích hợp DCB" thay vì chỉ sử dụng "trình tích hợp DCB". Tuy nhiên, tài liệu chung về Thanh toán chuẩn của Google sử dụng "Nhà tích hợp" làm tên viết tắt của "Nhà tích hợp thanh toán"
- ID thỏa thuận thanh toán -> ID tài khoản của đơn vị tích hợp thanh toán
- OperatorUserToken (OUT) -> GooglePaymentToken (GPT)
- tương quan_id -> mã yêu cầu
- Chia sẻ doanh thu -> phí
Luồng xác thực
Để biết thông tin tổng quan chung về quy trình xác thực cho Phương thức thanh toán được mã hoá, hãy xem trang này.
Quy định cụ thể về việc thanh toán qua nhà mạng
Đối với phương thức Thanh toán qua nhà mạng, mục tiêu của quy trình xác thực là chứng minh rằng người dùng có quyền kiểm soát đối với thẻ SIM liên kết với tài khoản của nhà mạng. Người dùng thanh toán qua nhà mạng có thể được xác thực bằng một trong ba cơ chế sau:
- Xác thực SMS-MO (Định nghĩa trong tổng quan về FOP được mã hoá)
- Xác thực chuyển hướng (Định nghĩa trong thông tin tổng quan về FOP được mã hoá)
- OTP qua SMS-MT (Định nghĩa trong phương thức FOP được mã hoá)
Bên tích hợp thanh toán có thể làm việc với Google để chọn cơ chế xác thực phù hợp nhất với sản phẩm của họ.
So sánh với DCB3
Quy trình xác thực thay thế lệnh gọi lại approveuser đến Google bằng cách sử dụng thông số kỹ thuật DCB3.
Trong DCB3, quy trình xác thực và liên kết được kết hợp thành một luồng duy nhất. Trong Google Standard Payments, việc xác thực là một mối quan tâm riêng biệt với việc liên kết tài khoản.
Quy trình liên kết
Để biết thông tin tổng quan chung về luồng liên kết cho Phương thức thanh toán được mã hoá, hãy xem trang này.
Điểm khác biệt chính giữa luồng liên kết dùng cho các Công cụ thanh toán qua nhà mạng và quy trình FOP được mã hoá chung là bằng chứng xác thực được cung cấp trong phương thức associateAccount sẽ khác nhau, tuỳ thuộc vào việc Trình tích hợp thanh toán có yêu cầu thêm thử thách người dùng hay không.
Nếu Công cụ tích hợp thanh toán trả lời rằng họ muốn thử thách người dùng bổ sung, thì bằng chứng xác thực sẽ là bất kỳ bằng chứng xác thực nào được tạo ra theo cơ chế xác thực cụ thể mà Google đã sử dụng cho thử thách bổ sung. Ví dụ: bằng chứng về việc xác thực do cơ chế OTP SMS-MT tạo ra là mã yêu cầu của phương thức sendOtp cộng với chính OTP.
Thuộc tính công cụ
Phần Tổng quan chung về phương thức thanh toán được mã hoá trong phần Thuộc tính công cụ thảo luận về khái niệm accountAlias, accountNickname và fullAccountNickname.
Quy định cụ thể về việc thanh toán qua nhà mạng
accountAliasphải là số điện thoại của người dùng. Thông tin này sẽ được dùng để giúp xác định công cụ trong trường hợp người dùng gọi điện cho nhóm hỗ trợ Google về tài khoản của họ.accountNicknamevàfullAccountNicknamelà tên hiển thị dùng để xác định phương thức trong giao diện người dùng.
So sánh với thông số kỹ thuật DCB3
Luồng liên kết thay thế các thành phần sau trong thông số kỹ thuật DCB3:
- Nhận lệnh gọi SOAP
- Lệnh gọi SOAP GetSubscriptionAddress
- OUT do nhà mạng tạo
Một điểm khác biệt lớn ở đây là trên thực tế, Google tạo Mã thông báo thanh toán của Google (GPT) trong quy trình liên kết thay vì nhà mạng tạo mã thông báo đó.
Một điều quan trọng cần lưu ý là không giống như trong DCB3, trong đó các OUT nằm trong một BillingBillingId cụ thể, GPT không thuộc phạm vi của bất kỳ PaymentIntegratorAccountID cụ thể nào.
Luồng mã làm mới
Để biết thông tin tổng quan chung về quy trình mã làm mới cho Phương thức thanh toán được mã hoá, hãy xem trang này.
Quy định cụ thể về việc thanh toán qua nhà mạng
Đối với các phương thức Thanh toán qua nhà mạng, chúng tôi đặc biệt không khuyến khích dùng Mã thông báo thanh toán của Google vì việc này sẽ khiến các đơn đặt hàng gói thuê bao bị huỷ. Thay vì mã thông báo hết hạn và dựa vào quy trình mã làm mới để khắc phục, trường hợp sử dụng của bạn thường có thể được hoàn thành bằng cách sử dụng quy trình cập nhật tài khoản được mô tả dưới đây.
Quy trình cập nhật tài khoản
Quy trình cập nhật tài khoản cho phép Đơn vị tích hợp thanh toán thông báo cho Google về các nội dung cập nhật đối với tài khoản của đơn vị tích hợp của người dùng. Ban đầu, các trường này được cung cấp cho Google trong quy trình liên kết. Một số ví dụ về dữ liệu tài khoản mà Nhà tích hợp thanh toán có thể muốn cập nhật bao gồm:
- hạn mức giao dịch hằng tháng, hằng ngày và theo từng mặt hàng của người dùng
- trạng thái cấp phép của tài khoản nhà tích hợp của người dùng
- loại tài khoản tích hợp của người dùng (trả trước, trả sau, doanh nghiệp, v.v.)
- "accountAlias", "accountBiệt hiệu" hoặc "fullAccountBiệt hiệu" của người dùng
- người dùng thiết lập, xoá hoặc thay đổi mã PIN tĩnh được chia sẻ trước
- liệu người dùng đã đóng tài khoản hoặc thay đổi số điện thoại của họ hay chưa – vô hiệu hoá phương thức của người dùng trong hệ thống của Google.
- xoá quy trình mã thông báo
So sánh với thông số kỹ thuật DCB3
Quy trình cập nhật tài khoản thay thế các thành phần sau đây của thông số kỹ thuật DCB3:
- Thăm dò lệnh gọi SOAP
- Vô hiệu hoá mã thông báo định kỳ
Quy trình mua
Để biết thông tin tổng quan chung về quy trình mua đối với các Phương thức thanh toán được mã hoá, hãy xem trang này.
Quy định cụ thể về việc thanh toán qua nhà mạng
Một số nhà mạng sử dụng USSD hoặc một công nghệ khác để thu thập mã PIN của người dùng trong mỗi giao dịch mua. Đối với các nhà mạng này, thay vì gọi capture(), chúng tôi gọi không đồng bộCapture() và cho phép nhà mạng nhắc người dùng nhập mã PIN và hoàn tất quá trình chụp trong 30 giây. Khi xác định được trạng thái cuối cùng của khoản thanh toán, nhà mạng sẽ thông báo kết quả cho Google bằng cách gọicaptureResultNotification().
So sánh với thông số kỹ thuật DCB3
Có những thay đổi lớn tại đây.
- Lệnh gọi phương thức đơn, đồng bộ -- capture() thay vì auth() + tệp xử lý hàng loạt
- Không có tệp hàng loạt nào
- Không có phương thức cancel() (capture + hoàn tiền thay vì xác thực + huỷ)
- Không có trường user_message nào được phản hồi – các mã từ chối được liên kết với thông báo do Google sở hữu được bản địa hoá sang ngôn ngữ trong tài khoản của người dùng.
- Thay đổi về thuật ngữ chính:
- Mã tham chiếu -> mã yêu cầu
- BillingTermsId -> paymentIntegratorAccountId
- OperatorUserToken -> googlePaymentToken
Quy trình mua hàng thử thách
Chúng tôi đang tiến hành quá trình phát triển để hỗ trợ quy trình mua hàng, trong đó có thử thách xác thực cho người dùng trước mỗi lần mua hàng. Hầu hết các phương thức xác thực có thể dùng trước quy trình liên kết cũng có thể được sử dụng trước quy trình mua có thách thức để cung cấp thêm hình thức xác thực người dùng.
Quy trình hoàn tiền
Để biết thông tin tổng quan chung về quy trình hoàn tiền cho các phương thức thanh toán được mã hoá, hãy xem trang này.
Phương thức FOP được mã hoá hỗ trợ một quy trình hoàn tiền thông báo duy nhất. Phương thức hoàn tiền hỗ trợ hoàn tiền cho toàn bộ giao dịch mua hoặc hoàn tiền một phần của giao dịch mua. Nhiều khoản tiền hoàn lại một phần có thể hoàn tiền cho một giao dịch mua.
Quy định cụ thể về việc thanh toán qua nhà mạng
Không có gì đặc biệt về các phương thức Thanh toán qua nhà mạng trong quy trình hoàn tiền.
So sánh với thông số kỹ thuật DCB3
Tiền hoàn lại được kích hoạt bằng lệnh gọi API đồng bộ thay vì tệp. Ngoài ra, bạn có thể tạo nhiều khoản tiền hoàn lại một phần cho một khoản thanh toán ban đầu thay vì chỉ hỗ trợ một khoản hoàn tiền toàn bộ giá trị.
Quy trình chuyển tiền
Để biết thông tin tổng quan chung về quy trình chuyển tiền cho các Phương thức thanh toán được mã hoá, hãy xem trang này.
Quy trình chuyển tiền là cách Google và Bên tích hợp thanh toán thực hiện quy trình thanh toán. Google là hệ thống kế toán ghi sổ và có tính đến các khoản chuyển tiền. Google sẽ thường xuyên gửi bảng sao kê chuyển tiền cho Bên tích hợp thanh toán. Bảng sao kê này tóm tắt số tiền mà Bên tích hợp thanh toán nợ Google cùng với hướng dẫn về cách thanh toán cho Google. Để điều chỉnh Nhà tích hợp thanh toán, Bên tích hợp thanh toán có thể truy vấn Google để biết thông tin chi tiết về cấp giao dịch trong bảng sao kê chuyển tiền.
Quy định cụ thể về việc thanh toán qua nhà mạng
Phương thức Thanh toán qua nhà mạng remittanceStatementDetails bao gồm các trường bổ sung chưa có trong danh sách định nghĩa API của quy trình chuyển tiền. Những quốc gia/khu vực này bao gồm:
- revshareCategory
- itemPrice
- tax
- timestamp
Đối với các nhà mạng có thoả thuận chia sẻ doanh thu 50/50 với Google, các khoản phí nêu trong remittanceStatementDetails sẽ được tổng hợp theo revshareCategory thay vì trình bày theo từng sự kiện.
So sánh với thông số kỹ thuật DCB3
Quy trình chuyển tiền thay thế các khái niệm sau trong thông số kỹ thuật DCB3:
- Báo cáo phí hằng tháng/Báo cáo thanh toán (PDF)
- Tệp CSV chứa thông tin chi tiết về hoá đơn hằng tháng
- Tệp CSV báo cáo hằng ngày
Điểm khác biệt chính ở đây là xoá mọi tệp và khả năng hỗ trợ việc chuyển tiền hằng ngày. Thay vì gửi tệp, số tiền cần chuyển sẽ được phân phối thông qua một API đồng bộ và một API khác hỗ trợ truy vấn để biết thông tin chi tiết về câu lệnh chuyển tiền.
Quy trình báo cáo gian lận
Quy trình báo cáo gian lận cho phép đơn vị tích hợp thanh toán thông báo cho Google về giao dịch có khả năng là gian lận bằng cách gọi phương thức fraudNotification. Quy trình này dùng để cập nhật công cụ rủi ro nội bộ của Google và không kích hoạt bất kỳ hoạt động chuyển tiền nào.
Quy định cụ thể về việc thanh toán qua nhà mạng
Không có gì đặc biệt về các phương thức Thanh toán qua nhà mạng trong quy trình thông báo huỷ khoản thanh toán.