BillingMeld: tại sao server cần xác nhận giao dịch thay vì ứng dụng

Mua hàng trong ứng dụng di động thường chỉ đơn giản đối với người dùng. Họ nhấn nút, xác nhận thanh toán, truy cập vào tính năng hoặc đăng ký — và mong đợi mọi thứ sẽ tự động hoạt động sau đó.

Đối với nhà phát triển, phía đằng sau nút đó bắt đầu là một quá trình phức tạp hơn nhiều. Họ cần xác nhận chính giao dịch, tính các phần mở rộng, kết thúc đăng ký, hoàn trả, theo dõi phản hồi giao dịch, thay đổi thiết bị và các khác biệt giữa các cửa hàng Apple và Google.

Vấn đề chính nảy sinh khi server bắt đầu coi ứng dụng khách là nguồn đúng sự thật.

Nếu ứng dụng thông báo: “Giao dịch đã xong”, server mở khóa quyền truy cập và tiếp tục dựa vào trạng thái đã nhận được một lần. Nhưng vòng đời của giao dịch không kết thúc tại đó.

Đăng ký có thể được gia hạn, tự động gia hạn có thể bị tắt, thanh toán có thể bị hoàn tiền, và chính giao dịch có thể bị thu hồi bởi cửa hàng.

Chính vì vậy, trong BillingMeld, việc xác nhận mua hàng là do server thực hiện, chứ không phải ứng dụng.

Khách hàng báo cáo nhưng không quyết định

Trong kiến trúc của BillingMeld, ứng dụng di động không phải là nguồn chính của thông tin về mua hàng.

Khách hàng có thể gửi dữ liệu về giao dịch đã thực hiện, nhưng đó chỉ là căn cứ để xác minh. Quyết định cuối cùng thuộc về phần server của BillingMeld, dựa trên việc xác minh thông tin qua hạ tầng của Apple hoặc Google.

Đây là sự khác biệt mang tính nguyên tắc.

Ứng dụng trên điện thoại có thể hoạt động với trạng thái cũ, không nhận được cập nhật mới kịp thời hoặc gửi dữ liệu đã không còn phù hợp với trạng thái hiện tại của mua hàng.

Hơn nữa, khách hàng không nên có khả năng tự quyết định quyền truy cập trả phí của người dùng.

Ví dụ, BillingMeld xác thực các trường hợp sau:

• Xác nhận rằng giao dịch tồn tại thực sự;

• Giao dịch thuộc về ứng dụng và sản phẩm phù hợp;

• Kỳ hạn đã trả hiện tại còn hiệu lực;

• Giao dịch đã được gia hạn lần nữa;

• Chế độ tự động gia hạn đã bị tắt;

• Giao dịch đã bị hoàn tiền;

• Giao dịch đã bị thu hồi;

• Kỳ hạn đã kết thúc.

Qua đó, tin nhắn của khách hàng không còn là bằng chứng của mua hàng nữa, mà là lý do để xác minh trạng thái thực của nó.

Nguồn sự thật duy nhất cho server

Các dịch vụ kết nối không cần tự xây dựng toàn bộ tích hợp cùng lúc với Apple và Google.

Họ tiếp cận BillingMeld và nhận được trạng thái đã chuẩn hóa của mua hàng.

Chẳng hạn: quyền truy cập vẫn còn, kỳ hạn trả đã kết thúc, gia hạn mới đã được xác nhận, tự động gia hạn đã bị tắt hoặc mua bị thu hồi.

Điều này giúp phân chia rõ trách nhiệm.

Apple và Google là nguồn trạng thái của chính hoạt động mua bán. BillingMeld xác minh dữ liệu này, chuẩn hóa thành mô hình chung và lưu giữ trạng thái cập nhật. Quyết định về quyền truy cập cuối cùng được đưa ra dựa trên trạng thái của BillingMeld.

Đối với các server của sản phẩm, điều này nghĩa là có một hợp đồng duy nhất thay vì nhiều tích hợp độc lập.

Không cần phải riêng biệt xử lý các quy tắc của App Store, Google Play hoặc cố gắng đồng bộ các định dạng, sự kiện và trạng thái của các nền tảng khác nhau này.

Tại sao không thể hoàn toàn tin tưởng vào khách hàng

Ứng dụng khách chạy trên thiết bị của người dùng.

Nó có thể bị đóng, khởi động lại, khôi phục từ sao lưu, cập nhật sau này hoặc chạy trên thiết bị khác. Trong một thời gian, nó có thể làm việc với trạng thái cũ hoặc không nhận được sự kiện đã xảy ra sau khi mua ban đầu.

Ngay cả mà không cần sự can thiệp của người dùng, ứng dụng vẫn là nguồn kém tin cậy cho trạng thái cuối cùng của đăng ký.

Ví dụ, người dùng đăng ký và có quyền truy cập. Sau đó, có thể đã có hoàn trả hoặc cửa hàng thu hồi giao dịch.

Nếu server chỉ biết về thông báo ban đầu của ứng dụng khách, thì vẫn cho rằng mua hàng còn hiệu lực.

Một trường hợp khác, người dùng có thể tắt tự động gia hạn. Thời gian trả đã thanh toán vẫn còn hiệu lực cho đến khi kết thúc kỳ hạn.

Nếu hệ thống chỉ dựa trên trạng thái đơn giản như “đăng ký còn / đăng ký hết”, sẽ dễ dàng kết thúc quyền truy cập sớm quá mức hoặc để quyền đó tồn tại sau khi đã hết hạn.

BillingMeld được xây dựng dựa trên nguyên tắc khác: khách hàng không xác nhận quyền của chính họ. Thay vào đó, họ báo cáo sự kiện, còn server xác định trạng thái thực của giao dịch.

Mua hàng không chỉ là một sự kiện

Một trong những sai lệch chính trong kiến trúc xử lý thanh toán là xem mua hàng như một sự kiện đơn lẻ.

Thực tế, nó có vòng đời riêng của nó.

Ban đầu có giao dịch được tạo ra. Sau đó, nó được xác nhận bởi cửa hàng. Đăng ký bắt đầu kỳ hạn trả. Sau đó, có thể có sự gia hạn tiếp theo.

Người dùng có thể tắt tự động gia hạn nhưng vẫn tiếp tục sử dụng đăng ký cho đến khi hết kỳ trả đã thanh toán.

Thanh toán có thể không thành công trong lần gia hạn tiếp theo.

Có thể có hoàn trả.

Trong một số trường hợp, mua hàng có thể bị thu hồi.

Điều này có nghĩa là, chỉ riêng việc xảy ra giao dịch "đã từng tồn tại" là chưa đủ.

Server cần hiểu rõ trạng thái hiện tại của nó.

Việc thu hồi mua hàng không bị bỏ qua

Chẳng hạn rõ nhất, điều này đặc biệt dễ thấy trong các hoàn trả và thu hồi.

Mua ban đầu có thể hoàn toàn chính xác. Người dùng thực sự đã thanh toán và có quyền truy cập.

Nhưng trạng thái của giao dịch sau đó đã thay đổi.

Nếu BillingMeld nhận được thông tin thay đổi, nó cập nhật trạng thái mua hàng của mình và, nếu cần, xác minh bổ sung qua cửa hàng.

Sau đó, dịch vụ kết nối làm việc với trạng thái mới của nó.

Như vậy, ứng dụng không còn tin tưởng hoàn toàn vào dữ liệu đã từng nhận của khách hàng vài tuần hoặc vài tháng trước đó.

Nếu cửa hàng không còn xác nhận quyền này nữa, BillingMeld phản ánh điều đó trong trạng thái của nó.

Hủy đăng ký và kết thúc quyền truy cập không giống nhau

Có sự khác biệt quan trọng.

Nếu người dùng tắt tự động gia hạn, điều này thường không có nghĩa là quyền truy cập phải bị khóa ngay lập tức.

Kỳ hạn trả hiện tại vẫn có thể còn hiệu lực.

Trong trường hợp đó, BillingMeld cần lưu trữ thông tin rằng chức năng tự gia hạn đã bị tắt, đồng thời hiểu rõ ngày kết thúc của kỳ hạn đã trả.

Chỉ sau khi hết hạn này, quyền truy cập mới bị coi là kết thúc nếu không có sự xác nhận mới về gia hạn.

Đây là một ví dụ về việc tại sao một giá trị boolean đơn giản như subscription = true không đủ cho xử lý thanh toán đúng đắn.

Trạng thái đăng ký luôn liên quan đến thời gian và các sự kiện của vòng đời.

Gia hạn cũng là một phép kiểm tra riêng

Đăng ký không kết thúc sau lần thanh toán đầu tiên.

Server cần xác định xem có sự gia hạn tiếp theo hay không, và liệu kỳ hạn trả tiếp theo có thực sự được xác nhận bởi cửa hàng.

BillingMeld theo dõi các thay đổi này và cập nhật trạng thái đăng ký.

Nếu gia hạn được xác nhận, quyền truy cập tiếp tục.

Nếu lần trừ tiếp theo không thành công hoặc cửa hàng không xác nhận kỳ hạn tiếp theo nữa, hệ thống không nên tự ý gia hạn quyền truy cập.

Điều này trông tự nhiên với người dùng: quyền truy cập tồn tại đúng theo đăng ký thanh toán thực tế.

Với các nhà phát triển, điều này có nghĩa là không cần phải lặp lại cùng một logic gia hạn trong từng ứng dụng.

Ví dụ về quy trình thông thường

Người dùng đăng ký trong ứng dụng di động.

Khách hàng nhận thông tin về mua hàng và gửi các dữ liệu cần thiết đến BillingMeld. Tuy nhiên, chính thông báo này chưa đủ để xem xét mua hàng đã được xác nhận hoàn toàn.

BillingMeld xác thực giao dịch qua cửa hàng phù hợp.

Nếu App Store hoặc Google Play xác nhận mua hàng và trạng thái phù hợp với quy định của sản phẩm, BillingMeld ghi nhận quyền hợp lệ.

Sau đó, dịch vụ kết nối cung cấp quyền truy cập đã thanh toán cho người dùng.

Trạng thái sau đó còn tiếp tục tồn tại bất kể thông báo ban đầu của khách hàng.

Nếu đăng ký gia hạn, BillingMeld cập nhật kỳ hạn trả mới.

Nếu người dùng tắt tự động gia hạn, kỳ hạn hiện tại vẫn còn hiệu lực đến khi kết thúc.

Nếu có hoàn trả hoặc thu hồi, trạng thái lại thay đổi.

Trong sơ đồ này, ứng dụng không lưu trữ “sự thật” riêng về mua hàng. Nó làm việc dựa trên trạng thái đã xác nhận và lưu giữ bởi BillingMeld.

Chuyện xảy ra khi thay đổi thiết bị

Kiến trúc dựa trên server đặc biệt hữu ích khi người dùng đổi điện thoại hoặc cài lại ứng dụng.

Quyền mua không nên chỉ dựa vào việc một bản cài đặt cụ thể từng ghi nhận thành công một giao dịch nào đó.

Ngược lại, việc cài đặt lại không nên xóa bỏ quyền đã xác nhận của người dùng.

Nếu trạng thái mua hàng nằm trên server và liên quan đến một giao dịch xác nhận của cửa hàng, thiết bị mới có thể nhận trạng thái cập nhật qua server đó.

Đây là lý do khác khiến không nên chỉ lưu logic quyền truy cập trong ứng dụng khách.

Những lợi ích cho nhà phát triển

Đối với nhóm phát triển phát hành nhiều ứng dụng di động hoặc làm việc với cả iOS và Android, xử lý thanh toán nhanh chóng trở thành một nhiệm vụ hạ tầng riêng biệt.

Họ cần lưu ý:

• định dạng dữ liệu khác nhau của Apple và Google;

• Xác nhận mua ban đầu;

• Gia hạn đăng ký;

• Kết thúc kỳ hạn đã trả;

• Tắt tự động gia hạn;

• Hoàn trả;

• Thu hồi giao dịch;

• Cài đặt lại ứng dụng;

• Thay đổi thiết bị;

• Khôi phục mua hàng;

• Thay đổi trạng thái xảy ra mà không có sự tham gia của khách hàng.

BillingMeld tách biệt toàn bộ logic này thành một lớp chuyên biệt.

Các server sản phẩm làm việc với lớp đó theo một hợp đồng thống nhất và không tự ý giải thích các đặc điểm của từng nền tảng.

Điều này giảm thiểu mã lặp lại và, quan trọng hơn, giảm nguy cơ các ứng dụng của cùng một công ty hiểu sai khác nhau về cùng một kịch bản thanh toán.

Điều quan trọng là không phải biên nhận mà là quyền thực sự

Bản thân tôi đặc biệt quan tâm đến chuyển đổi từ kiểm tra từng mua sang kiểm soát trạng thái hiện tại.

Sự kiện thanh toán ban đầu chưa đủ để trả lời câu hỏi quan trọng của sản phẩm:

người dùng có quyền sử dụng chức năng trả phí hay không tại thời điểm hiện tại?

Có thể đã có mua ban đầu thành công, nhưng đã hết kỳ hạn.

Đăng ký có tự động gia hạn tắt, nhưng thời hạn trả đã thanh toán vẫn còn hiệu lực.

Có thể có gia hạn xác nhận.

Hoặc đã có hoàn trả.

Cửa hàng có thể thu hồi giao dịch.

Chính vì thế, không phải biên nhận hay câu trả lời ban đầu của khách hàng mới là chính xác, mà là quyền của người dùng dựa trên trạng thái xác nhận của mua hàng.

Chính trạng thái này của BillingMeld mới là thứ các dịch vụ khác dựa vào.

BillingMeld như ranh giới giữa cửa hàng và sản phẩm

Kết quả là, kiến trúc rõ ràng hơn hình thành.

Một bên là App Store và Google Play cùng với các định dạng, sự kiện, quy tắc và vòng đời mua hàng của chúng.

Mặt khác là các ứng dụng và dịch vụ nội bộ, với câu trả lời đơn giản hơn nhiều: quyền hiện tại của người dùng là gì.

Trong giữa là BillingMeld.

Nó chấp nhận dữ liệu từ cửa hàng, xác minh, chuẩn hóa theo mô hình của riêng nó và cung cấp kết quả đã chuẩn hóa cho hạ tầng khác.

Nhờ đó, các sản phẩm không cần phải biết tất cả các đặc điểm phức tạp của từng nền tảng thanh toán.

Tại sao điều này quan trọng cho người dùng

Tiêu chuẩn về kiến trúc thanh toán đúng đắn về lý thuyết sẽ gần như không để người dùng phát hiện ra.

Nếu mua hàng đã được xác nhận và kỳ hạn trả còn hiệu lực, quyền truy cập phải hoạt động.

Nếu người dùng tắt tự động gia hạn, thời hạn đã trả không nên kết thúc sớm hơn dự kiến.

Nếu có gia hạn mới thành công, quyền truy cập tiếp tục.

Nếu cửa hàng xác nhận hoàn trả hoặc thu hồi, hệ thống cần phản ánh chính xác quyền của người dùng.

Khi thay đổi thiết bị hoặc cài lại ứng dụng, người dùng không cần phải tự chứng minh cho từng phần của hạ tầng rằng giao dịch thực sự tồn tại.

Quy tắc đơn giản có thể tóm tắt như sau:

Khách hàng báo cáo mua hàng, cửa hàng là nguồn bên ngoài của trạng thái của nó, BillingMeld xác minh và chuẩn hóa trạng thái, các dịch vụ khác quyết định dựa trên dữ liệu đã xác nhận này.

Chính vì vậy, BillingMeld không chỉ là một module thanh toán nữa.

Đây là lớp server trung tâm của niềm tin giữa ứng dụng di động, các cửa hàng của Apple và Google, cùng các sản phẩm cần hiểu rõ các quyền trả phí của người dùng tại thời điểm hiện tại.

Chi tiết về dự án tại: billingmeld.de.