Khi Nào Drupal Commerce Thắng Shopify

Với phần lớn cửa hàng trực tuyến, Drupal Commerce là câu trả lời sai. Đó không phải lời chê dự án, vốn được thiết kế tốt suốt mười lăm năm, mà là mô tả phần lớn cửa hàng: vài trăm SKU, một tiền tệ, khách tiêu dùng, cuối cùng một lần quẹt thẻ. Với hình hài đó, nền tảng lưu trữ sẵn thắng ở mọi trục quan trọng, và tranh luận kết thúc trước khi kịp bắt đầu.

Nhưng có một thiểu số mà phép tính đảo ngược hoàn toàn, và đó là thiểu số sinh lợi. Sản phẩm cấu hình được, không diễn đạt nổi bằng lưới biến thể. Tài khoản đại lý có bảng giá đã đàm phán. Danh mục cũng chính là nội dung biên tập. ERP nắm tồn kho và giá, xem website chỉ là bề mặt hiển thị. Ở đó, nền tảng lưu trữ sẵn không rẻ hơn: nó là khoản thuế vĩnh viễn, trả bằng ứng dụng, cách lách và những thứ bạn không được phép sửa.

Bài này nêu rõ ranh giới ấy nằm ở đâu, kèm con số của cả hai phía. Nếu đọc phần Shopify mà nhận ra chính mình, hãy dừng ở đó: bạn sẽ tiết kiệm rất nhiều tiền, và bài viết đã làm xong việc của nó.

Khi nào Drupal Commerce thắng Shopify? Khi sản phẩm không thể mô hình hóa thành lưới biến thể đơn giản, khi hai khách thấy giá khác nhau cho cùng một SKU, khi danh mục và nội dung biên tập là một, hoặc khi ERP là nguồn dữ liệu chuẩn còn cửa hàng chỉ là khung nhìn vào đó. Với danh mục tiêu dùng thường gặp trong một hai tiền tệ, Shopify rẻ hơn trong ba năm và chuyển đổi tốt hơn. Ranh giới nằm ở độ phức tạp của sản phẩm và giá, không phải lưu lượng hay doanh thu.

Drupal Commerce thực chất là gì

Drupal Commerce không phải một sản phẩm cửa hàng đóng gói. Nó là tập hợp các kiểu thực thể đặt trên hệ thống thực thể và trường của Drupal, và mọi điều trong bài này đều suy ra từ câu đó.

Sản phẩm trong Drupal Commerce là một thực thể có bundle, y hệt một node. Biến thể, đơn hàng, dòng đơn hàng, thanh toán, khuyến mãi và cửa hàng cũng vậy. Mỗi thứ đều nhận trường tùy ý, nên một biến thể có thể mang số lô, mã chứng chỉ, thời gian giao tính theo ngày làm việc và một kích thước dùng để tính giá. Đó không phải trường tùy chỉnh gắn thêm bên cạnh một lược đồ cố định. Đó chính là lược đồ.

Thứ được mua là biến thể, không phải sản phẩm. Sản phẩm là lớp vỏ trình bày, biến thể mới là mục có SKU và giá, còn thuộc tính sinh ra các tổ hợp chọn được. Kiểu sản phẩm quyết định sản phẩm có trường nào, kiểu biến thể quyết định biến thể mang thuộc tính nào. Không chỗ nào trong cách sắp xếp đó giả định bạn bán quần áo, bán hàng vật lý, hay số lựa chọn là cố định.

Hệ quả là Drupal Commerce gần như không áp đặt quan điểm nào về thứ bạn bán. Cái giá của tự do đó là nó cũng gần như không đưa ra quyết định nào, và ai đó phải đưa ra tất cả.

Vị trí hiện tại của Drupal Commerce

Bản phát hành được khuyến nghị hiện nay là Drupal Commerce 3.3.8, công bố ngày 17 tháng 7 năm 2026, chạy với Drupal 10.3 trở lên và Drupal 11. Các bản ổn định thuộc phạm vi chính sách cảnh báo bảo mật của Drupal, điều quan trọng hơn vẻ ngoài của nó: một lỗ hổng được công bố sẽ có bản vá phối hợp, thay vì một issue trên GitHub.

Trang dự án Drupal Commerce báo cáo 35.870 website đang dùng mô đun này. Commerce 3.0.0 là bản ổn định đầu tiên của nhánh 3.x, ra tháng 1 năm 2025, và bỏ hỗ trợ Drupal 9. Quanh nó là một hệ sinh thái đóng góp nhỏ: Commerce Shipping đang ở 3.0.3 với khoảng 15.200 lượt cài, còn các mô đun chuyên biệt bàn bên dưới chỉ ở mức vài nghìn.

Hãy so với WooCommerce, nơi báo cáo hơn 7 triệu lượt cài đang hoạt động và yêu cầu WordPress 6.9 cùng PHP 7.4 trở lên. Xét quy mô cài đặt, Drupal Commerce nhỏ hơn khoảng 200 lần.

Tỷ lệ đó là con số quan trọng nhất trong bài, và nó là lời cảnh báo chứ không phải lời khoe. Nó có nghĩa câu hỏi đã có sẵn mô đun cho việc này chưa thường nhận câu trả lời là chưa.

Nói công bằng về Shopify

Shopify giải quyết bốn vấn đề đủ sức nhấn chìm phần lớn cửa hàng tự vận hành, và giải quyết trước khi bạn viết dòng mã đầu tiên.

Nó được lưu trữ sẵn, nên thời gian hoạt động, mở rộng và vá lỗi thôi là khoản chi của bạn. Nó xử lý dữ liệu thẻ, nên phạm vi tuân thủ bạn gánh chỉ bằng một phần nhỏ. Quy trình thanh toán của nó được kiểm chứng qua khối lượng giao dịch thật mà không đơn vị nào tái tạo nổi, và ở quy mô ấy, chênh lệch chuyển đổi nhỏ đáng giá hơn mọi sở thích kiến trúc. Hệ sinh thái ứng dụng khiến phần lớn yêu cầu đến dưới dạng thuê bao thay vì một dự án.

Với danh mục tiêu dùng vài nghìn SKU, một hai loại tiền tệ và không có giá đàm phán, mọi lợi thế mô tả ở phần sau đều không áp dụng. Bạn sẽ trả tiền cho một đơn vị để dựng lại, tệ hơn, thứ hiện có với 65 bảng mỗi tháng.

Nói thẳng, vì phần còn lại của bài lập luận theo hướng ngược lại: phần lớn cửa hàng nên dừng ở Shopify. Nếu cửa hàng của bạn là một trong số đó, bài so sánh Shopify với thương mại điện tử làm riêng bàn kỹ hơn trang này.

Shopify tốn bao nhiêu tại Anh

Shopify công bố giá tại Anh bằng bảng, nên không cần quy đổi. Theo trang giá của Shopify đọc vào tháng 9 năm 2026, Basic là 25 bảng mỗi tháng khi trả theo tháng hoặc 19 bảng khi trả theo năm, Grow là 65 hoặc 49 bảng, Advanced là 344 hoặc 259 bảng, còn Plus khởi điểm 1.800 bảng mỗi tháng. POS Pro cộng thêm 69 bảng mỗi tháng cho mỗi điểm bán.

Phí thẻ quan trọng hơn phí thuê bao. Phí thẻ trực tuyến qua Shopify Payments là 2% cộng 25 xu ở Basic, 1.7% cộng 25 xu ở Grow và 1.5% cộng 25 xu ở Advanced. Con số hầu hết mọi người bỏ sót là phí nhà cung cấp thanh toán bên thứ ba, tính khi bạn dùng cổng khác Shopify Payments: 2% ở Basic, 1% ở Grow, 0.6% ở Advanced và 0.2% ở Plus.

Phí đó nằm trên phí của chính cổng thanh toán. Một cửa hàng doanh thu 1 triệu bảng mỗi năm, dùng Advanced và một đơn vị thu hộ bên ngoài, chỉ riêng phí bên thứ ba đã là 6.000 bảng mỗi năm, tức 18.000 bảng trong ba năm, để được quyền không dùng Shopify Payments.

Nơi Shopify hết chỗ xoay xở

Các giới hạn đều công khai và rất cụ thể. Tài liệu Shopify về thêm biến thể nêu rõ mỗi sản phẩm có tối đa ba tùy chọn và tối đa 2.048 biến thể, vượt một trong hai thì cần ứng dụng bên thứ ba hoặc mã giao diện để bắt thuộc tính dòng đơn hàng.

Ba tùy chọn là trần chạm trước tiên. Một khung cửa sổ, một tấm in, một bộ rèm đo may hay một cỗ máy đã cấu hình thường có sáu đến tám lựa chọn độc lập, và ngay khi vượt ba, nền tảng thôi mô hình hóa sản phẩm của bạn mà bắt đầu xấp xỉ nó.

Bức tường thứ hai là trang thanh toán. Tiện ích mở rộng giao diện thanh toán của Shopify cho các bước thông tin, vận chuyển và thanh toán chỉ có trên gói Plus. Dưới Plus, bạn gắn thương hiệu được nhưng không chèn logic vào được, nên mất khả năng chọn khung giờ giao, kiểm tra hạn mức công nợ và chặn tuân thủ đúng lúc cần.

Thứ ba là sự tích tụ. Mọi khoảng trống đều lấp bằng ứng dụng, mỗi ứng dụng là một khoản phí tháng và một ràng buộc nâng cấp, còn cửa hàng có hai mươi ứng dụng thì gánh đúng bài toán bảo trì mà nó từng bỏ chạy.

Ưu điểm của WooCommerce và chỗ nó đuối

WooCommerce xứng đáng được đối xử công bằng hơn thường lệ. Nó miễn phí, chạy trên hosting vài chục bảng mỗi tháng, dữ liệu là của bạn, và kho tiện ích mở rộng lớn nhất ngành thương mại điện tử. Với cửa hàng tiêu dùng vừa và nhỏ mà đội ngũ đã quen WordPress, nó thường là câu trả lời đúng và rẻ nhất.

Nó đuối ở ba chỗ đoán trước được. Thứ nhất là mô hình dữ liệu: sản phẩm là một kiểu bài viết WordPress với thuộc tính lưu dạng meta tuần tự hóa, nên lọc một danh mục lớn nhiều thuộc tính đồng nghĩa với truy vấn bảng khóa và giá trị thay vì cột thật. Ở 1.000 sản phẩm còn chịu được, ở 50.000 thì rất đau.

Thứ hai là hiệu năng theo số biến thể, lý do phổ biến nhất khiến một cửa hàng WooCommerce chậm. Chúng tôi đã mổ xẻ cơ chế đó trong bài vì sao cửa hàng WooCommerce chậm, và tóm lại thì sản phẩm biến thể nhân truy vấn lên chứ không phải nhân số dòng.

Thứ ba là nạn phình plugin. WooCommerce giải quyết vấn đề bằng cách cài thêm thứ gì đó, và sau bốn năm, cửa hàng được định nghĩa bởi lịch phát hành của ba mươi nhà cung cấp chứ không phải của bạn.

Mô hình sản phẩm phức tạp, ranh giới thật đầu tiên

Trường hợp rõ ràng nhất cho Drupal Commerce là sản phẩm được cấu hình chứ không phải được chọn. Vải bán theo mét kèm phí cắt. Kính tính giá theo chiều rộng nhân chiều cao với mức tối thiểu. Máy có tám nhóm tùy chọn, trong đó vài nhóm vô hiệu hóa nhóm khác. Ấn phẩm in có đường giảm giá theo số lượng và phí cài đặt cho mỗi lệnh in.

Không thứ nào là lưới biến thể. Trên nền tảng lưu trữ sẵn, chúng được xấp xỉ bằng một ứng dụng và một tập thuộc tính dòng đơn hàng, nghĩa là giá hiển thị cho khách được tính bên ngoài logic giá của chính nền tảng và phải đối soát ở đâu đó về sau.

Trong Drupal Commerce, giá được giải bằng mã bạn viết. Một price resolver nhận biến thể, số lượng và ngữ cảnh hiện tại rồi trả về một mức giá. Chẳng có gì kỳ lạ ở đó, nhưng nó khiến giá đã cấu hình là giá thật ở mọi nơi: trong giỏ, trong đơn, trong tính thuế và trong dữ liệu xuất sang ERP.

Phép thử rất đơn giản. Nếu bạn viết được danh mục thành một bảng tính với mỗi dòng là một thứ mua được, bạn không cần thứ này. Nếu không viết được, mọi phần còn lại của bài đều liên quan.

Giá B2B, bảng giá và điều khoản đàm phán

Ranh giới thứ hai là liệu có bao giờ hai khách hàng thấy giá khác nhau cho cùng một SKU. Cửa hàng tiêu dùng trả lời không. Doanh nghiệp bán buôn trả lời có, và câu trả lời đó thường là toàn bộ công việc kinh doanh.

Shopify có B2B, và tài liệu về tính năng theo gói B2B xác nhận nó có trên Basic, Grow, Advanced và Plus. Chi tiết nằm ở giới hạn: dưới Plus bạn có tối đa ba danh mục đang bật trên toàn bộ thị trường B2B, danh mục gắn trực tiếp cho công ty chỉ có ở Plus, và tiền đặt cọc, thanh toán từng phần cùng yêu cầu thu tiền theo lần giao cũng chỉ có ở Plus. Ba danh mục thì đủ cho ba bậc giá và vô dụng với bốn mươi tài khoản đã đàm phán.

Bên phía Drupal, thứ tương đương là mô đun Commerce Price List, hiện ở 8.x-2.16 với khoảng 1.662 lượt cài được báo cáo và có đội bảo mật theo dõi. Nó đặt giá theo người dùng hoặc theo vai trò, hỗ trợ bậc số lượng và khoảng ngày, và nhập được từ CSV.

Điểm cuối cùng mới là điểm thực dụng. Một nhà bán buôn có bốn mươi tài khoản, mỗi tài khoản một bảng giá riêng, làm mới hàng quý từ ERP, thì đó là việc nhập CSV chứ không phải một cuộc chuyển nền tảng.

Nhiều cửa hàng, nhiều tiền tệ và nhiều ngôn ngữ từ một mã nguồn

Cửa hàng là thực thể hạng nhất trong Drupal Commerce, và sản phẩm được gán cho những cửa hàng được phép bán nó. Đó là quyết định thiết kế nhỏ với hệ quả lớn: nhiều mặt tiền có thể dùng chung một danh mục, một luồng đơn hàng và một trang quản trị, trong khi mang tiền tệ, cấu hình thuế, cổng thanh toán và quy tắc vận chuyển khác nhau.

Hình hài quen thuộc là một site Anh, một site EU và một cổng đại lý, tất cả chạy từ một lần triển khai. Dữ liệu sản phẩm nhập một lần. Bảng giá chỉ áp cho cửa hàng đại lý. Thuế được giải theo từng cửa hàng, vì mỗi cửa hàng mang quốc gia xuất hóa đơn và đăng ký thuế của riêng nó.

Nhân Drupal còn mang lại lớp đa ngữ thực sự mạnh, với bí danh URL theo ngôn ngữ, thực thể được dịch và liên kết ngôn ngữ thay thế, đó là lý do Drupal hiện diện dày đặc trong giáo dục đại học và khu vực công.

Shopify Markets nay đã bao phủ khá nhiều phần này, nhưng thanh toán theo ngữ cảnh và tùy biến mặt tiền qua Markets chỉ có ở gói Advanced và Plus, nên đối tượng so sánh tối thiểu là 259 bảng mỗi tháng chứ không phải 25 bảng.

Khi danh mục chính là nội dung biên tập

Một số danh mục vốn là nội dung. Nhà bán lẻ chuyên ngành có trang sản phẩm kèm cẩm nang mua, bảng so sánh, bài giải thích kỹ thuật và ghi chú của người đánh giá thì thực chất đang vận hành một ấn phẩm có thu tiền.

Trên nền tảng lưu trữ sẵn, đó là hai hệ thống. CMS giữ bài viết, cửa hàng giữ SKU, và chúng nối với nhau bằng một liên kết cùng một lần xuất dữ liệu ban đêm. Biên tập viên làm việc ở hai nơi, tìm kiếm lập chỉ mục hai lần, và cấu trúc URL mọc một đường nối chạy giữa.

Trong Drupal Commerce, sản phẩm là thực thể cùng hệ thống với mọi bài viết, nên nó dùng chung quy trình biên tập, lịch sử phiên bản, bộ từ vựng phân loại, thư viện media, chỉ mục tìm kiếm và mô hình phân quyền. Một trang sản phẩm tham chiếu được ba bài viết và một bài viết tham chiếu được chín sản phẩm, cả hai đều là tham chiếu thực thể thật chứ không phải liên kết dán vào.

Đây là lập luận hay được dùng nhất để biện minh cho Drupal ở một doanh nghiệp lẽ ra ngồi yên trên Shopify, và cũng là lập luận hay bị gạt đi nhất, cho tới khi đội biên tập đã mất một năm làm việc trong hai trang quản trị.

Sản phẩm bị quản lý chặt và nhiều thuộc tính

Sản phẩm mang dữ liệu tuân thủ là trường hợp thứ tư. Hóa chất kèm bảng dữ liệu an toàn. Thiết bị y tế có số chứng nhận và hạn dùng. Thực phẩm có ma trận dị nguyên. Hàng điện có tuyên bố hợp chuẩn. Bất cứ thứ gì cần truy xuất theo lô hoặc cờ hạn chế bán.

Yêu cầu không chỉ là lưu các giá trị đó. Mà là kiểm tra chúng, lưu phiên bản, hiển thị đúng bản ứng với lô khách thực sự nhận, và về sau chứng minh được điều gì đã công bố vào một ngày cụ thể. Field API và hệ thống phiên bản của Drupal làm được vì chúng sinh ra cho quản trị nội dung chứ không phải cho trưng bày hàng.

Phía cưỡng chế cũng quan trọng ngang thế. Một trình xử lý đơn có thể từ chối đơn giao hàng hạn chế độ tuổi tới quốc gia cấm, hoặc đơn ghép hai mặt hàng không được vận chuyển cùng nhau, và làm việc đó ngay trong luồng đơn hàng chứ không phải trong mẫu giao diện.

Trên nền tảng lưu trữ sẵn, mỗi kiểm tra như vậy là một ứng dụng, mà ứng dụng thì không ghép được với nhau. Hai ứng dụng cùng sửa giỏ hàng là hai ứng dụng sớm muộn sẽ mâu thuẫn.

Khi ERP là nguồn dữ liệu chuẩn

Trường hợp thứ năm mang tính cấu trúc. Trong doanh nghiệp phân phối hay sản xuất, ERP nắm tồn kho, giá, hạn mức tín dụng và trạng thái đơn, còn website là bề mặt hiển thị gắn thêm giỏ hàng. Câu hỏi không phải cửa hàng làm được gì, mà giữ nó khớp với hệ thống thực sự cầm trịch rẻ đến đâu.

Drupal Commerce thoải mái ở đây vì phần tích hợp chạy trong tiến trình của chính bạn. Queue API lo việc bất đồng bộ, Migrate API lo các lần nhập lặp lại và bất biến, và không có bên trung gian nào tính phí theo bản ghi hay bóp cửa sổ đồng bộ. Nhập giá và tồn kho 200.000 dòng mỗi đêm chỉ là một tác vụ cron.

Trên nền tảng lưu trữ sẵn, cùng phần tích hợp ấy là một thuê bao ứng dụng hoặc một thuê bao middleware, và giới hạn tần suất API của nền tảng trở thành ràng buộc kiến trúc bạn phải thiết kế vòng qua, chứ không còn là chi tiết. Cách đó vẫn chạy được, và với nhiều doanh nghiệp là đánh đổi đúng. Nó thôi đúng khi việc đồng bộ vừa lớn, vừa thường xuyên, vừa sống còn.

Nếu phần tích hợp mới là khối lượng chính của dự án chứ không phải cửa hàng, thì đó là một hợp đồng phát triển phần mềm có gắn mặt tiền, và nên được định phạm vi như thế ngay từ đầu.

Thuế là chỗ nền tảng lưu trữ sẵn hết rẻ

Thuế là trung tâm chi phí thầm lặng trong thương mại điện tử xuyên biên giới, và là chỗ phép so sánh phí thuê bao bắt đầu gây hiểu nhầm. Hai ngưỡng quyết định phần lớn câu chuyện.

Ngưỡng đăng ký VAT tại Anh

Hướng dẫn của GOV.UK về thời điểm đăng ký VAT đặt ngưỡng ở 90.000 bảng tổng doanh thu chịu thuế. Hai phép thử riêng biệt kích hoạt nghĩa vụ đăng ký: phép thử luân phiên mười hai tháng, theo đó bạn phải đăng ký trong vòng 30 ngày kể từ cuối tháng mà doanh thu vượt 90.000 bảng, và phép thử nhìn tới, theo đó bạn phải đăng ký ngay khi nhận ra doanh thu sẽ vượt 90.000 bảng trong 30 ngày kế tiếp.

Phép thử nhìn tới mới là thứ tóm được các cửa hàng đang lớn, vì ngày đăng ký là ngày bạn nhận ra, không phải ngày tiền về.

VAT của EU và cơ chế một cửa

Hướng dẫn của Ủy ban châu Âu về nơi đánh thuế đặt ngưỡng gộp hằng năm 10.000 euro, tính chung bán hàng từ xa nội khối cùng dịch vụ viễn thông, phát sóng và điện tử. Dưới ngưỡng, nơi đánh thuế là nơi bắt đầu gửi hoặc vận chuyển. Trên ngưỡng, việc đánh thuế chuyển sang nơi kết thúc vận chuyển, tức thuế suất tại nước của khách.

Cơ chế một cửa cho phép khai toàn bộ trong một tờ khai tại một nước thành viên, nộp theo quý với hạn cuối tháng 4, tháng 7, tháng 10 và tháng 1. Cơ chế một cửa nhập khẩu bao trùm hàng nhập từ ngoài EU trong các lô không vượt 150 euro.

Drupal Commerce làm được gì sẵn

Commerce đưa plugin thuế VAT của Liên minh châu Âu vào lõi chứ không bán rời. Nó mang thuế suất của cả 27 nước thành viên cộng Monaco, phân biệt thuế suất chuẩn, giảm, trung gian, siêu giảm và bằng không, đồng thời xử lý các vùng lãnh thổ đặc biệt vốn làm hỏng bảng thuế phẳng, gồm Corsica, Azores, Madeira, các đảo Hy Lạp và vùng đất kẹp Jungholz của Áo.

Nó áp dụng cả quy tắc chứ không riêng thuế suất: đánh thuế theo nơi đến cho hàng số, và miễn thuế cho giao dịch nội khối giữa doanh nghiệp khi có mã số thuế hợp lệ. Trên nền tảng lưu trữ sẵn, hành vi đó thường là một ứng dụng tính phí theo giao dịch.

Thanh toán, PCI DSS và cách bạn nhận thẻ

Cách bạn thu số thẻ quyết định gánh nặng tuân thủ, và quy tắc vừa đổi theo cách bị hiểu sai rất rộng.

Bản làm rõ tiêu chí đủ điều kiện SAQ A của Hội đồng Tiêu chuẩn Bảo mật PCI giải thích một tiêu chí có hiệu lực từ ngày 1 tháng 4 năm 2025. Đơn vị bán phải xác nhận website của mình không dễ bị tấn công bởi script có thể ảnh hưởng tới hệ thống thương mại điện tử của họ. Cách đáp ứng là triển khai kỹ thuật trong yêu cầu 6.4.3 và 11.6.1 của PCI DSS, hoặc lấy xác nhận từ nhà cung cấp thanh toán rằng giải pháp nhúng của họ đã có các biện pháp ấy.

Phần hay bị hiểu sai là phạm vi. Tiêu chí ấy chỉ áp dụng cho đơn vị bán nhúng biểu mẫu thanh toán của nhà cung cấp vào trang của mình, thường trong iframe. Hội đồng nêu rõ nó không áp dụng cho đơn vị bán chuyển hướng khách sang nhà cung cấp, dù bằng chuyển hướng HTTP, meta refresh hay JavaScript, và cũng không áp dụng cho đơn vị bán thuê ngoài hoàn toàn chức năng thanh toán.

Vậy nên chuyển hướng ra ngoài giữ bề mặt rủi ro nhỏ. Trường nhúng, vốn chuyển đổi tốt hơn và gần như là thứ ai cũng muốn, lại kéo tính toàn vẹn của mọi script trên trang thanh toán vào câu chuyện tuân thủ của bạn.

Lợi thế thật sự của Shopify nằm ở đây, vì trang thanh toán và mọi script trên đó đều của họ. Trên Drupal Commerce, trang thanh toán là của bạn, nên câu trả lời phải được thiết kế: chính sách bảo mật nội dung nghiêm ngặt, subresource integrity, danh mục mọi script chạy trên trang thanh toán, và cơ chế phát hiện khi một trong số đó đổi. Việc này không khó và cũng không tùy chọn, nó cần nằm trong ngân sách thay vì bị phát hiện giữa một cuộc kiểm toán.

Khả năng tiếp cận là rủi ro pháp lý và thương mại

Lỗi tiếp cận trong thương mại điện tử tụ ở trang thanh toán, nơi mọi lỗi đều tốn tiền trực tiếp.

Tài liệu tham chiếu là WCAG 2.2, Khuyến nghị của W3C công bố ngày 12 tháng 12 năm 2024. Các tiêu chí cắn vào một cửa hàng rất cụ thể. Mức AA 1.3.5 Nhận diện mục đích nhập lo tự động điền cho trường địa chỉ và thẻ. Mức A 3.3.7 Nhập trùng lặp bị vi phạm mỗi khi trang thanh toán bắt khách gõ lại địa chỉ giao ở bước trả tiền. Mức AA 3.3.8 Xác thực tiếp cận được chi phối việc tạo tài khoản và đăng nhập. Mức AA 2.5.8 Kích thước mục tiêu bắt lỗi nút tăng giảm số lượng và nút xóa khỏi giỏ, còn mức AA 1.4.3 Độ tương phản bắt lỗi nút xám như bị vô hiệu nhưng thực ra vẫn bấm được.

Hai tiêu chí nữa xoay quanh chính đơn hàng: mức A 3.3.1 Nhận diện lỗi, và mức AA 3.3.4 Ngăn ngừa lỗi cho giao dịch pháp lý, tài chính và dữ liệu, vốn nói thẳng về việc đặt hàng.

Vị thế pháp lý tại Anh thường bị nói quá. Nhà bán lẻ tư nhân không bị ràng buộc bởi đạo luật nào nêu đích danh mức tuân thủ WCAG. Thứ áp dụng là nghĩa vụ trong mục 20 của Đạo luật Bình đẳng 2010: có bước đi hợp lý để tránh gây bất lợi đáng kể cho người khuyết tật, gồm cả cung cấp phương tiện hỗ trợ. Quy định duy nhất nêu mức tuân thủ, tức Quy định về Khả năng tiếp cận của Cơ quan Khu vực công (Website và Ứng dụng di động) (số 2) năm 2018, áp dụng cho cơ quan khu vực công chứ không phải cửa hàng.

Luận điểm thương mại sắc hơn luận điểm pháp lý. Trên giao diện lưu trữ sẵn, bạn không phải lúc nào cũng sửa được thứ một ứng dụng chèn vào trang thanh toán. Trên nền tảng bạn kiểm soát, bạn sửa được.

Ba năm thực sự tốn bao nhiêu

Phép so sánh người ta hay làm là phí thuê bao tháng với phí hosting tháng, và đó là dòng ít quan trọng nhất trong bảng. Chi phí dựng và bảo trì mới áp đảo, còn ở quy mô lớn thì tỷ lệ phí giao dịch áp đảo.

Các khoảng dưới đây là ước tính nội bộ của Mecanik cho một cửa hàng tầm trung tại Anh, trừ các con số thuê bao và phí của Shopify vốn được trích đúng bằng bảng như Shopify công bố. Phần còn lại là mức chúng tôi dự kiến sẽ báo, và biên độ trong mỗi dòng còn rộng hơn khoảng cách giữa các nền tảng ở đầu thấp.

Mỗi dòng trong bảng thực sự mua được gì

Nói bằng lời: Shopify Advanced tốn 9.324 đến 12.384 bảng tiền thuê bao trong ba năm tùy bạn có cam kết theo năm hay không, đã gồm hosting, nhưng cộng thêm phí ứng dụng thực tế chạy từ 5.400 đến 14.400 bảng cùng kỳ. WooCommerce không trả gì cho nền tảng và trả 3.600 đến 14.400 bảng cho hosting, với tiện ích mở rộng ở mức 3.000 đến 9.000 bảng trong ba năm. Drupal Commerce không trả phí giấy phép, chi nhiều nhất cho hosting ở mức 5.400 đến 21.600 bảng vì là ứng dụng nặng nhất trong ba, và chi ít nhất cho bổ trợ, từ 0 đến khoảng 3.000 bảng, vì thứ tương đương là mô đun đóng góp chứ không phải hàng thương mại.

Chi phí dựng mới là chỗ các nền tảng tách nhau. Một bản dựng Shopify 8.000 đến 25.000 bảng mua được cửa hàng có giao diện và các tích hợp chuẩn, so với 10.000 đến 35.000 bảng trên WooCommerce. Cùng yêu cầu đó trên Drupal Commerce là 35.000 đến 120.000 bảng, vì trang thanh toán, logic giá và các tích hợp đều được viết chứ không phải cấu hình. Bảo trì cũng theo hình đó, ở mức 3.000 đến 9.000 bảng mỗi năm cho Shopify, 4.000 đến 12.000 bảng cho WooCommerce và 12.000 đến 30.000 bảng cho Drupal Commerce, phản ánh đơn giá ngày của đơn vị Anh vào khoảng 600 đến 900 bảng như trong bài về đơn giá lập trình viên Drupal.

Tổng ba năm rơi vào đâu

Tổng ba năm rơi vào khoảng 32.000 đến 79.000 bảng với Shopify, 29.000 đến 94.000 bảng với WooCommerce và 76.000 đến 235.000 bảng với Drupal Commerce. Phí thẻ và phí cổng nằm trên cả ba và tăng theo doanh thu, đó là lý do phí cổng bên thứ ba 0.6% của Shopify trên gói Advanced đáng giá 18.000 bảng trong ba năm với một cửa hàng doanh thu 1 triệu bảng.

Đọc bảng cho trung thực thì Drupal Commerce đắt gấp hai đến ba lần. Nó chỉ chính đáng khi phương án kia thực ra không dùng được, và đó là toàn bộ ý nghĩa của năm phần trước.

Drupal Commerce headless và tách lớp

Tách lớp Drupal Commerce là nhu cầu thật trong một nhóm hẹp và là mốt trong phần lớn số còn lại. Phép thử trung thực là liệu có thứ gì ngoài website cần đúng danh mục đó không.

Đó là nhu cầu thật khi một ứng dụng di động gốc và một website phải dùng chung một mô hình sản phẩm và giá, khi một giao diện sẵn có do đội khác dựng sẽ không bị thay, khi máy bán hàng tại quầy hoặc kiosk dùng chung giỏ, hoặc khi hệ thống thiết kế do bên ngoài dự án sở hữu và không diễn đạt được bằng Twig. Trong các trường hợp đó, API mới là sản phẩm còn CMS được cố ý giấu đi.

Đó là mốt khi lý do đưa ra là hiệu năng. Một giao diện Drupal truyền thống có bộ nhớ đệm tốt sẽ phục vụ trang sản phẩm cho khách ẩn danh ngay từ biên, và cách kết xuất hiếm khi là thứ làm một cửa hàng chậm.

Chi phí dồn vào một chỗ. Nhân Drupal phơi nội dung qua JSON:API mà không cần cấu hình, còn mô đun Commerce Cart API đặt giỏ hàng sau một giao diện REST, nên đọc danh mục và dựng giỏ gần như miễn phí. Trang thanh toán thì không. Xử lý địa chỉ, hiển thị thuế, chọn vận chuyển, khuyến mãi, tích hợp thành phần thanh toán và xác nhận đơn đều phải dựng lại ở giao diện, và phần đó thường chiếm 40% trở lên của toàn bộ bản dựng.

Quy tắc quyết định trong năm phút

Hãy trả lời sáu câu hỏi về danh mục của bạn. Mỗi câu có tính một điểm.

Có sản phẩm nào cần hơn ba tùy chọn, hoặc hơn 2.048 tổ hợp mua được không? Có bao giờ hai khách khác nhau trả giá khác nhau cho cùng một SKU không? Bạn có bán sang nhiều nước với cách xử lý VAT khác nhau, hoặc dự kiến phải nộp tờ khai OSS không? Danh mục có đồng thời là nội dung biên tập do chính đội đó viết và duy trì không? ERP hay PIM có phải là nơi quyết định giá và tồn kho, còn cửa hàng nằm ở hạ nguồn không? Bạn có cần chèn logic riêng vào trang thanh toán, chứ không chỉ gắn thương hiệu cho nó không?

Được không hoặc một điểm thì chọn Shopify. Các lợi thế nêu trong bài không áp dụng cho bạn, và bạn sẽ trả tiền để dựng lại thứ đang thuê.

Được hai điểm thì quyết định thực sự còn mở, với WooCommerce thường là lối giữa tốt hơn, nhất là khi đội đã vận hành WordPress.

Được ba điểm trở lên thì Drupal Commerce đáng được báo giá tử tế, vì các cách lách cần đến ở nơi khác sẽ đắt hơn nền tảng trong ba năm. Được năm hay sáu điểm thì nền tảng lưu trữ sẵn không phải lựa chọn rẻ hơn, nó là một sản phẩm khác không làm nổi việc này.

Dự án Drupal Commerce thường sai ở đâu

Thất bại phổ biến nhất là chọn nó vì lý do sai. Chúng tôi vốn đã chạy Drupal không phải là một yêu cầu thương mại. Site nội dung và site giao dịch có yêu cầu thời gian hoạt động khác nhau, cách kiểm thử khác nhau và hậu quả khác nhau khi triển khai hỏng, và coi cửa hàng như một mục nữa của site sẵn có chính là cách một dự án thương mại điện tử nhỏ bỗng phải nuôi một đội nền tảng ngoài kế hoạch.

Thứ hai là thiếu nguồn lực bảo trì. Với 35.870 lượt cài, hệ sinh thái đủ nhỏ để bạn sẽ dùng những mô đun chỉ có vài người duy trì, và bên bạn phải có người theo dõi cảnh báo bảo mật rồi lên lịch cập nhật. Một site Drupal Commerce không ai chịu trách nhiệm việc đó là một sự cố bảo mật có hẹn giờ, điều chúng tôi bàn kỹ hơn cùng yêu cầu hosting mà Drupal thực sự đòi hỏi.

Thứ ba là mặc định rằng đã có mô đun. Hãy kiểm tra trước khi định phạm vi. Nếu chưa có, phần việc đó là một nhiệm vụ phát triển website làm riêng và cần ước tính thật chứ không phải một dòng trong bảng.

Thứ tư là kỷ luật phiên bản lớn. Commerce 3 yêu cầu Drupal 10.3 trở lên, và một site tụt lại sau nhân rốt cuộc sẽ thấy các mô đun thương mại đã đi tiếp mà không có nó. Bài hướng dẫn phát triển Drupal 2026 và bài về chi phí cùng hạn chót khi chuyển đổi đều đi sâu vào chu kỳ đó.

Ra quyết định cho đúng

Lựa chọn được quyết bởi độ phức tạp của sản phẩm và giá, không phải bởi lưu lượng, doanh thu hay sở thích. Hãy mô hình hóa danh mục trên giấy trước, gồm mọi tùy chọn, mọi mức giá đã đàm phán và mọi tích hợp phải giữ khớp với thứ khác. Nếu mô hình đó vừa một lưới biến thể, hãy mua nền tảng lưu trữ sẵn và dồn ngân sách tiết kiệm được vào khâu trưng bày hàng.

Mecanik dựng và bảo trì cả hai loại cửa hàng, và chúng tôi sẽ nói bạn đang ở phía nào của ranh giới trước khi báo bất kỳ giá nào. Nếu câu trả lời là Drupal Commerce, công việc đó là một hợp đồng phát triển website với phần tích hợp đáng kể; nếu phần ERP nặng hơn mặt tiền, nó thuộc về phát triển phần mềm. Nếu câu trả lời là Shopify, chúng tôi sẽ nói vậy, và thà nói bây giờ còn hơn nói khi bản dựng lại đã đi được mười tám tháng.

Câu hỏi thường gặp

Drupal Commerce có tốt hơn Shopify không? Với phần lớn cửa hàng thì không. Shopify rẻ hơn trong ba năm, lo phần tuân thủ PCI và hosting, và có quy trình thanh toán được kiểm chứng ở quy mô không đơn vị nào sánh được. Drupal Commerce thắng trong một nhóm hẹp: sản phẩm cần hơn ba tùy chọn hoặc hơn 2.048 biến thể, giá đàm phán riêng theo khách, danh mục đồng thời là nội dung biên tập, và cửa hàng có ERP nắm giá cùng tồn kho.

Dựng một hệ Drupal Commerce tại Anh tốn bao nhiêu? Hãy tính 35.000 đến 120.000 bảng cho bản dựng ban đầu và 12.000 đến 30.000 bảng mỗi năm cho bảo trì, với đơn giá ngày của đơn vị Anh khoảng 600 đến 900 bảng. Trong ba năm, một cửa hàng Drupal Commerce thường rơi vào 76.000 đến 235.000 bảng gồm cả hosting, so với khoảng 32.000 đến 79.000 bảng cho Shopify Advanced. Đây là ước tính nội bộ, không phải báo giá.

Nên dùng phiên bản Drupal Commerce nào? Dùng Drupal Commerce 3, hiện ở 3.3.8, phát hành ngày 17 tháng 7 năm 2026. Nó chạy với Drupal 10.3 trở lên và Drupal 11, và các bản ổn định thuộc phạm vi chính sách cảnh báo bảo mật của Drupal. Commerce 2 hỗ trợ Drupal 9 và 10 và thuộc chu kỳ phát hành trước, nên dự án mới nên bắt đầu ở nhánh 3.x.

Drupal Commerce có xử lý VAT của EU và OSS không? Các quy tắc thuế nằm sẵn trong lõi Commerce chứ không bán rời. Plugin VAT của Liên minh châu Âu mang thuế suất của cả 27 nước thành viên cộng Monaco, phân biệt thuế suất chuẩn, giảm, trung gian, siêu giảm và bằng không, xử lý các vùng lãnh thổ đặc biệt, áp dụng đánh thuế theo nơi đến cho hàng số và miễn thuế cho giao dịch B2B nội khối khi có mã số thuế hợp lệ. Việc nộp tờ khai OSS vẫn là công việc kế toán.

Khi nào Drupal Commerce headless mới đáng làm? Khi có thứ khác ngoài website dùng chung danh mục đó, chẳng hạn ứng dụng gốc, máy bán hàng tại quầy hay một giao diện do đội khác sở hữu. Không đáng làm chỉ vì tốc độ, vì giao diện truyền thống có bộ nhớ đệm vốn đã nhanh. Hãy dự trù ngân sách dựng lại trang thanh toán, phần thường chiếm 40% trở lên của một bản dựng tách lớp.