Khi dịch chuyển sang mô hình SaaS (software-as-a-service), các doanh nghiệp cần những phương thức thanh toán linh hoạt hơn, cho phép họ đáp ứng nhiều chiến lược và môhình thanh toán khác nhau.
Việc dịch chuyển sang SaaS thường đồng nghĩa với việc dịch chuyển sang mô hình kinh doanh theo hình thức đăng ký (subscription-based) hoặc tiêu thụ (consumption-based). Hơn thế nữa, các khách hàng sử dụng SaaS cũng mong đợi việc chỉ cần chi trả cho những gì mà họ sử dụng hơn là việc phải trả trước một khoản lớn.
Để hỗ trợ mô hình này, các doanh nghiệp cần xem xét việc áp dụng những công cụ hoặc dịch vụ mới có khả năng hỗ trợ các mô hình chi phí SaaS. Trong nhiều trường hợp, các nhà cung cấp SaaS sẽ dựa vào một bên thứ Ba để giải quyết các nhiệm vụ phức tạp liên quan tới hóa đơn và thanh toán. Các nhà cung cấp sẽ đề xuất các mô hình giá cả, quản trị đăng ký, hoá đơn, quản lý thông tin khách hàng, và các tính năng liên quan tới thanh toán khác cần thiết cho việc vận hành mô hình kinh doanh SaaS. Điều này cũng cho phép các nhà cung cấp SaaS tập trung hơn vào IP của họ, trong khi vẫn tận dụng được những cải tiến và phát triển được đề xuất bởi hệ thống thanh toán của bên thứ Ba.
Trong blog này, người viết sẽ tập trung phân tích cách mà các nhà cung cấp SaaS có thể tích hợp hoặc chuyển giao phương thức thanh toán, bằng cách thu thập dữ liệu và chuyển sang cho đơn vị thanh toán thứ Ba. Ngoài ra, người viết cũng sẽ xem xét một số một số mô hình thanh toán SaaS thường gặp và giới thiệu một bản mẫu thực hiện thanh toán để người đọc có thể hình dung dễ dàng hơn cách tích hợp phương thức thanh toán với đơn vị thanh toán thứ Ba.
Tổng quan khái niệm
Trước khi đi vào chi tiết của hình mẫu kiến trúc thanh toán, hãy cùng nhìn qua khung khái niệm, bao gồm những thành phần quan trọng trong quá trình thực hiện, phối hợp thanh toán giữa đơn vị cung cấp SaaS và đơn vị hỗ trợ thanh toán:
Hình 1. Khung khái niệm thể hiện quá trình triển khai tích hợp thanh toán
Từ bên trái, bạn có thể thấy ứng dụng SaaS sẽ dẫn tới hai loại hoạt động. Hoạt động đầu tiên là yêu cầu onboard (1), được gửi mỗi khi có một người dùng mới được thêm vào hệ thống. Hoạt động này sẽ được thêm vào cơ sở dữ liệu, sau đó cơ sở dữ liệu sẽ tạo một cấu hình cho người thuê trong phần chứng nhận thực hiện thanh toán (2).
Loại hoạt động thứ hai là thanh toán (3). Mỗi khi ứng dụng SaaS cần báo cáo bất kỳ hoạt động gì liên quan tới thanh toán của người dùng, ứng dụng sẽ tạo một sự kiện được lưu trữ trong cơ sở dữ liệu trung gian (4).
Theo định kỳ, các hoạt động đơn lẻ trong kho dữ liệu trung gian sẽ được tập hợp lại (5), lưu lại trong cơ sở dữ liệu (6), sau đó được công khai với đơn vị thanh toán (7, 8).
Tại sao phải xuất bản hoạt động tới một cơ sở dữ liệu trung gian thay vì gửi thẳng cho đơn vị thanh toán? Kho dữ liệu trung gian này sẽ tăng độ bền vững và khả năng phục hồi của quá trình tích hợp thanh toán. Bằng cách lưu trữ dữ liệu tại chỗ, bạn có thể giải quyết mọi tình huống khi mà hoạt động không thể được phát hành và gửi cho đơn vị thanh toán. Việc giữ lại các hoạt động cũng cho phép bạn phát hành lại vào bất kỳ thời điểm nào sau này. Sử dụng một cơ sở dữ liệu trung gian cũng giúp tránh việc chạm ngưỡng API mà các đơn vị thanh toán đã đặt ra.
Điều kiện tiên quyết
Đăng ký Stripe
Trước khi một người thuê được chấp thuận và đưa vào hệ thống Stripe Billing, bạn cần tạo một tài khoản Stripe, Khi tạo xong tài khoản, bạn sẽ bắt đầu làm quen với môi trường thử nghiệm. Điều này cho phép bạn sử dụng các tính năng của Stripe mà không cần đăng ký tài khoản merchant.
Tạo sản phẩm và giá trên Stripe
Sau khi tạo tài khoản Stripe, bạn cần tạo những cấu trúc thanh toán trong Stripe, được sử dụng để xác định giá tổng quan cũng như cấu trúc giá theo bậc của ứng dụng. Những lựa chọn này cần được định dạng trước khi thêm người dùng mới vào trong phần chứng thực thanh toán.
Để định dạng dữ liệu này, bạn cần đặt cấu hình cho sản phẩm và giá cả trên Stripe. Những cấu hình sẽ xác định cách mà hệ thống của bạn tính phí người dùng, cũng như cách mà bạn đặt các mức cho mô hình thanh toán. Nếu bạn có nhiều mức giá trong ứng dụng SaaS, bạn sẽ cần tạo những sản phẩm riêng lẻ cho từng mức độ.
Ví dụ, giả sử ứng dụng SaaS của bạn có 2 mức: Nhà phát triển và Doanh nghiệp. Bạn sẽ tạo hai sản phẩm Stripe tương ứng. Xuyên suốt quá trình tạo sản phẩm, bạn cần làm rõ mô hình giá, giá và định kỳ thanh toán. Ngoài ra, mức giá bạn tạo cần được xác nhận “Usage is metered". Chứng thực thanh toán sử dụng “Sum of usage values during period" bên dưới mục “Charge for metered usage by". Khi sản phẩm và giá đã được định dạng trong Stripe, bạn đã sẵn sàng để thêm người dùng.
Tạo các khoá hạn chế
Phần này miêu tả cách tạo các khoá hạn chế thay vì sử dụng khoá API cung cấp bởi Stripe. Khoá hạn chế cho phép các nhà phát triển tiếp cận với các tập con tính năng của Stripe. Thông tin về khoá hạn chế có thể được tìm thấy trong Stripe documentation.
Đối với phần chứng thực này, bạn cần tạo các khoá hạn chế với các quyền sau:
Hoá đơn, đọc (READ)
Đăng ký, đọc (READ)
Ghi nhận mức sử dụng, viết (WRITE)
Khoá được tạo cần được bắt đầu với “rk_”. Khoá này cần được đặt trong Secret Manager như một phần của quá trình triển khai ứng dung, được mô tả trong hình dưới đây:
Tổng quan quá trình thực hiện
Phương pháp cơ bản chúng ta đang áp dụng là nhằm mục đích tạo một cơ sở kiến trúc cho phép các nhà phát triển SaaS dễ dàng phát hành các hoạt động thanh toán được ghi nhận.
Phương pháp này bao gồm việc cung cấp tất cả những kiến trúc cần thiết để tiếp nhận và tổng hợp các hoạt động trước khi phát hành chúng tới hệ thống thanh toán (trong trường hợp này là Stripe). Dưới đây là một mô hình chứng thực, tuân thủ mô hình đã được đặt ra ở phần trước:
Hình 2 - Triển khai thanh toán và đo lường bằng cách sử dụng Stripe
Đầu tiên, bạn có thể để ý rằng kiến trúc này hoàn toàn chạy trên môi trường phi máy chủ (serverless). Hơn nữa, hoá đơn điện toán được tính dựa trên mức sử dụng thực tế. Nếu không có bất kỳ hoạt động nào chạy trên hệ thống, hoặc việc tổng hợp hoạt động không diễn ra, người điều hành ứng dụng chỉ cần chi trả cho việc lưu trữ dữ liệu trong Amazon DynamoDB và các thông tin mật trong AWS Secrets Manager.
Onboard người dùng mới
Sau khi tạo một tài khoản trên Stripe, và định dạng được một hoặc nhiều sản phẩm cũng như giá thành, bạn đã sẵn sàng để “onboard" người dùng mới. Có hai bước quan trọng để onboard người dùng trên hệ thống này.
Thứ nhất, bạn cần tạo một customer trong Stripe. Customer này sẽ đại diện cho đơn vị hoặc tổ chức sử dụng dịch vụ, không phải là một khách hàng cá nhân. Customer sẽ bao gồm một vài thông tin về đơn vị thuê dịch vụ, thông tin thanh toán.
Khi customer đã được tạo, bạn cần tạo một Stripe subscription. Điều này liên kết customer với một sản phẩm ở một mức giá cụ thể như kế hoạch mà người dùng chọn trong quá trình onboard.
Liên kết giữa subscription và customer dẫn đến subscription item ID. Số nhận dạng này rất quan trọng đối với trải nghiệm tích hợp thanh toán và được tham chiếu bởi mỗi hoạt động thanh toán được gửi đến Stripe.
Giải pháp thanh toán mẫu sử dụng Amazon EventBridge (Billing EventBridge trong sơ đồ trên) để xuất bản hoạt động onboard người dùng.
Ví dụ về lệnh gọi API này được viết bằng Python sẽ xuất hiện như sau:
EVENT_TYPE = “ONBOARD”
EVENT_BUS_NAME = “BillingEventBridge”
detail = json.dumps({
"TenantID": “Tenant1”,
"ExternalSubscriptionIdentifer": “si_00000000000000”})
event = {
'Source': 'ApplicationName',
'Detail': str(detail),
'DetailType': EVENT_TYPE,
'EventBusName': EVENT_BUS_NAME }
ebClient.put_events(Entries=event)
Tại mục nhập mã này, bạn sẽ thấy chúng tôi đã khởi tạo hai giá trị. EVENT_TYPE được sử dụng để xác định loại tin nhắn được gửi; nó được đặt thành ONBOARD. Điều này được sử dụng trong quá trình xử lý để phân biệt sự kiện onboard với sự kiện thanh toán.
Tiếp theo, bạn sẽ thấy cấu trúc chi tiết được sử dụng để giữ dữ liệu cho đối tượng thuê mới của chúng tôi. Ở đây, TenantID đại diện cho một ID được liên kết với người dùng. Điều này sẽ được chỉ định bởi ứng dụng SaaS của bạn và không có mối quan hệ với ID customer. Nó có thể là một GUID hoặc một số định danh duy nhất khác cho người thuê.
Mã định danh này sẽ có sẵn cho ứng dụng của bạn khi xử lý các yêu cầu liên quan đến thanh toán; nó được yêu cầu bởi kiến trúc tham chiếu thanh toán khi xử lý các hoạt động thanh toán.
Giá trị của trường ExternalSubscriptionIdentifier sẽ là giá trị nhận dạng được sử dụng trong các yêu cầu gửi đến nhà cung cấp dịch vụ thanh toán. Trong ví dụ trên, đó là ID đăng ký được Stripe Billing sử dụng.
Giá trị này sẽ phụ thuộc vào nhà cung cấp thanh toán bạn sử dụng. Sẽ có một ví dụ về cách sử dụng ExternalSubscriptionIdentifier trong phần Tổng hợp các sự kiện và xuất bản thành Stripe Billing.
Sau khi sự kiện được đặt vào Billing EventBridge, điều này sẽ kích hoạt chức năng AWS Lambda có nhãn “Chức năng dành cho người dùng mới tích hợp” trong sơ đồ trên. Hàm Lambda này xử lý sự kiện và lưu trữ kết quả trong Bảng DynamoDB Thanh toán và Đo lường.
Xử lý sự kiện thanh toán
Sau khi người dùng được onboard, bạn có thể bắt đầu xuất bản các sự kiện thanh toán. Nếu bạn có mô hình thanh toán dựa trên mức tiêu dùng, các sự kiện này sẽ được sử dụng để mô tả những đơn vị có thể tạo lập hóa đơn. Các sự kiện tiêu dùng này cuối cùng sẽ được tổng hợp lại và sử dụng để tính toán hóa đơn của người dùng trong Stripe.
Các sự kiện thanh toán này trông rất giống sự kiện onboard được giới thiệu ở phần trên. Các sự kiện được đặt trên cùng Amazon EventBridge, Billing EventBridge. Sau đây là một ví dụ viết bằng Python về một sự kiện thanh toán đang được xuất bản thông qua API EventBridge:
EVENT_TYPE = “BILLING”
EVENT_BUST_NAME = “BillingEventBridge”
detail = json.dumps({
"TenantID": “Tenant1”,
"Quantity": 1})
event = {
'Source': 'ApplicationName',
'Detail': str(detail),
'DetailType': EVENT_TYPE,
'EventBusName': EVENT_BUS_NAME }
ebClient.put_events(Entries=event)
Ở đây, chúng tôi sử dụng EVENT_TYPE để biểu thị rằng đây là một sự kiện THANH TOÁN. Chi tiết hơn, bạn sẽ thấy TenantID đại diện cho người dùng đang gửi sự kiện có thể lập hóa đơn. Giá trị này phải được đặt trong bối cảnh đối tượng người dùng được chuyển đến ứng dụng, thường là JWT mà ứng dụng sử dụng.
Số lượng thể hiện số lượng đơn vị có thể lập hóa đơn mà khách hàng đã tiêu thụ. Thông tin này được tạo ra khi một sự kiện có thể lập hóa đơn xảy ra.
Khi sự kiện này được đặt vào Thanh sự kiện Thanh toán, Chức năng Sự kiện Thanh toán Xử lý sẽ chạy. Hàm này xử lý sự kiện và đặt sự kiện đó vào bảng DynamoDB Thanh toán và Đo lường.
Lưu trữ các số liệu từ sự kiện và cấu hình người dùng
Tất cả dữ liệu mà giải pháp thanh toán mẫu nhập vào sẽ được lưu trữ trong một bảng DynamoDB duy nhất. Điều này thực chất sẽ dẫn đến việc nhiều loại dữ liệu được giữ trong một bảng.
Để hỗ trợ mô hình bảng đơn này, bảng DynamoDB sử dụng TenantID làm khóa phân vùng của nó. Bảng cũng sử dụng các khóa và tiền tố khóa khác nhau cho khóa sắp xếp để xác định kiểu dữ liệu được lưu trữ trong mỗi mục DynamoDB nhất định.
Có ba loại mục khác nhau sẽ được trình bày trong bảng này:
Cấu hình người thuê (khóa sắp xếp sẽ là CONFIG)
Các sự kiện riêng lẻ (khóa sắp xếp sẽ là EVENT#<epoch time in milliseconds>#<unique identifier>)
Sự kiện tổng hợp (khóa sắp xếp sẽ là AGGREGATE#<aggregation time range (MINUTE)>#<beginning of epoch time period>)
Các mục cấu hình đối tượng thuê sẽ lưu trữ mã định danh đăng ký được liên kết với nhà cung cấp dịch vụ thanh toán. Thông tin này được sử dụng trong bước cuối cùng (trong sơ đồ trên, trong chức năng Nhà xuất bản thanh toán). Cấu hình đối tượng thuê cũng chứa thời gian đóng cho hóa đơn sắp tới trong Stripe.
Các mục sự kiện riêng lẻ bao gồm ID đối tượng, thời gian xảy ra sự kiện và số lượng đơn vị có thể lập hóa đơn liên quan đến sự kiện. Khóa sắp xếp cho các sự kiện riêng lẻ cũng bao gồm một mã định danh duy nhất để ngăn sự xung đột nếu hai hoặc nhiều sự kiện được gửi đồng thời.
Cuối cùng, các sự kiện tổng hợp là các mục có chứa TenantID, khoảng thời gian tính bằng phút và tổng số lượng sự kiện đã xảy ra trong phút đó.
Tổng hợp các sự kiện và xuất bản lên Stripe Billing
Sau khi dữ liệu được chuyển đến bảng DynamoDB, một sự kiện tạo bởi CloudWatch (Sự kiện dựa trên thời gian tổng hợp các mục nhập thanh toán trong sơ đồ) sẽ gọi một Hàm AWS Step bao gồm hai Lambda: một hàm tổng hợp các sự kiện thanh toán riêng lẻ (chức năng Tổng hợp sự kiện thanh toán) và một hàm khác xuất bản các sự kiện lên Stripe Billing (chức năng Stripe Billing Publish). Điều này xảy ra, theo mặc định, một lần mỗi phút.
Việc xuất bản mỗi phút một lần diễn ra do yêu cầu của Stripe Billing, rằng các sự kiện cho thời hạn thanh toán trước đó sẽ được xuất bản trong vòng năm phút sau khi kết thúc thời hạn thanh toán. Để tránh bỏ sót các sự kiện vào cuối thời hạn thanh toán, việc tổng hợp diễn ra một lần mỗi phút, mặc dù thời gian đóng hóa đơn trong cấu hình đối tượng thuê được kiểm tra trước khi xuất bản lên Stripe. Nếu hóa đơn chưa được đóng, dữ liệu thanh toán sẽ không được xuất bản.
Khi các sự kiện thanh toán riêng lẻ được tổng hợp bởi chức năng Tổng hợp sự kiện thanh toán, các sự kiện này sẽ bị xóa khỏi bảng và được thay thế bằng một sự kiện tổng hợp dưới dạng tóm tắt các sự kiện sắp đến. Để đảm bảo các sự kiện tổng hợp không được xuất bản hai lần, chức năng Tổng hợp sự kiện tạo một khóa lý tưởng để sử dụng với Stripe Billing. Nếu hai sự kiện tổng hợp được chuyển vào Stripe Billing với cùng một khóa lý tưởng thì lần thử thứ hai sẽ không thành công.
Các sự kiện tổng hợp này được lưu trữ vô thời hạn trong bảng DynamoDB (mặc dù chúng có thể bị xóa sau khi được xuất bản lên Stripe). Các sự kiện tổng hợp có một thuộc tính có tên là “publish_to_billing_provider”. Khi giá trị này được đặt thành true trong bảng DynamoDB, sự kiện đã được gửi thành công đến Stripe Billing. Thời điểm loại bỏ các sự kiện đã được xác nhận là tùy thuộc vào người vận hành phần mềm.
Tại sao lại tổng hợp các sự kiện? Đầu tiên, điều này làm giảm số lượng mục trong bảng DynamoDB Thanh toán và Đo lường. Điều này làm giảm chi phí chạy triển khai tham chiếu thanh toán. Ngoài ra, bằng cách tổng hợp và lưu trữ trong bảng, sẽ có ít yêu cầu hơn đối với Stripe Billing.
Sau khi tổng hợp các sự kiện thanh toán riêng lẻ, chức năng Stripe Billing Publisher sẽ xuất bản các sự kiện thanh toán lên Stipe. Để đạt được điều này, trước tiên nó phải nhận được dữ liệu cấu hình cần thiết cho quá trình xuất bản này. Chức năng này sẽ thu thập dữ liệu cấu hình của người thuê từ bảng DynamoDB lập hóa đơn và đo lường để lấy mã định danh đăng ký bên ngoài của người thuê. Nó cũng sẽ truy xuất khóa Stripe API bị hạn chế từ Trình quản lý bí mật (được thể hiện dưới dạng Khóa API của nhà cung cấp thanh toán trên sơ đồ).
Bước cuối cùng của quy trình là đi qua từng sự kiện tổng hợp và gửi chúng đến hóa đơnđược liên kết với Mục đăng ký trong Thanh toán theo dải. Việc sử dụng sẽ không được xuất bản cho Stripe cho đến khi hóa đơn sắp tới được thiết lập để đóng. Điều này làm giảm số lượng yêu cầu đối với API Stripe.
Chạy giải pháp mẫu
Các giải pháp mẫu được mô tả trong bài đăng này có sẵn trong kho lưu trữ GitHub. Giải pháp này đại diện cho một ví dụ hoạt động của chiến lược và các khái niệm đã được nêu ở trên.
Chi tiết về cách thiết lập giải pháp và làm cho nó chạy được trình bày trong README của kho lưu trữ.
Kết luận
Việc chuyển sang mô hình SaaS đòi hỏi các công ty phải phát triển các chiến lược định giá mới. Các chiến lược này cũng yêu cầu các nhà phát triển SaaS giới thiệu các cấu trúc mới có thể lập hồ sơ và xuất bản dữ liệu về hoạt động của người thuê được sử dụng để tạo hóa đơn.
Một phần lớn của nỗ lực này thường bao gồm việc tạo tích hợp với nhà cung cấp dịch vụ thanh toán bên thứ ba. Bản chất của các tích hợp này có thể thay đổi từ nhà cung cấp này sang nhà cung cấp tiếp theo.
Giải pháp mà chúng tôi tham khảo trong bài viết này nhằm giải quyết các yếu tố cốt lõi của việc xây dựng tích hợp thanh toán. Bài viết cũng nêu ra một số cân nhắc chính sẽ định hình cách tiếp cận của bạn và sẽ giúp bạn có một khởi đầu thuận lợi trên con đường tạo mô hình tích hợp thanh toán của riêng mình.
Nếu vẫn còn gặp những khó khăn trong việc xử lý thanh toán và hoá đơn cho mô hình SaaS của bạn, hãy liên hệ OSAM ngay hôm nay để được tư vấn miễn phí bởi các chuyên gia và các kiến trúc sư công nghệ đầu ngành. Chúng tôi sẽ giúp doanh nghiệp của bạn giải quyết mọi vấn đề phức tạp liên quan tới thanh toán và xuất hoá đơn cho dịch vụ AWS, để bạn có thể tập trung thời gian và công sức cho việc nghiên cứu và phát triển ứng dụng SaaS của mình.
Nguồn:
Keith, P. (2021). Building a Third-Party SaaS Metering and Billing Integration on AWS. Available at: https://aws.amazon.com/vi/blogs/apn/building-a-third-party-saas-metering-and-billing-integration-on-aws/