Nền tảng HstockPlus: Cách Đơn hàng, Xử lý đơn và API Thực sự Kết nối với nhau

Trang này mô tả cách chợ hoạt động như một hệ thống: các vai trò của nó, đường đi của một đơn hàng và những gì API phơi bày. Không có gì được bán từ trang này.

Hai danh mục, không phải một

Nền tảng mang hai loại hàng tồn kho và chúng hoạt động khác nhau đủ để nếu coi chúng là một thứ sẽ gây ra vấn đề.

Danh sách sản phẩm là hàng hóa kỹ thuật số được bán theo đơn vị từ kho của người bán: tài khoản, hộp thư, proxy, khóa. Khoảng mười bảy nghìn sản phẩm hiển thị cho người mua tại bất kỳ thời điểm nào, được lấy từ một danh mục lớn hơn bao gồm bản nháp, danh sách chờ phê duyệt và danh sách mà người bán đã tắt. Chúng được nhóm thành các danh mục và danh mục con, được gắn thẻ để lọc và được định giá theo biến thể thay vì theo danh sách, vì vậy một danh sách duy nhất có thể mang nhiều tùy chọn mua với giá khác nhau.

Dịch vụ tăng trưởng dựa trên số lượng: bạn đặt một số lượng người theo dõi, lượt xem hoặc bình luận cho một liên kết. Khoảng ba mươi nghìn dịch vụ đang hoạt động. Chúng sử dụng phân loại riêng và từ vựng thẻ riêng, và không được tính vào giới hạn danh sách sản phẩm của người bán.

Số người bán ở mức thấp hàng trăm theo danh mục hoạt động, so với khoảng một nghìn năm trăm tài khoản giữ vai trò người bán, trải rộng trên khoảng năm trăm sáu mươi cửa hàng.

Vai trò và những gì mỗi vai trò có thể tiếp cận

Có ba vai trò và chúng mang tính cộng dồn thay vì loại trừ, vì vậy một tài khoản có thể vừa là người mua vừa là người bán.

• Người mua duyệt, đặt hàng, giữ số dư trang web, theo dõi đơn hàng và mở vé hỗ trợ.
• Người bán quản lý danh sách và kho hàng, xử lý đơn hàng, cấu hình mã giảm giá và yêu cầu thanh toán. Hồ sơ người bán có thể được hiển thị công khai để người mua có thể duyệt mọi thứ người bán đó cung cấp ở một nơi.
• Quản trị viên phê duyệt người bán và danh sách, giải quyết tranh chấp và nắm giữ các cài đặt mà hầu hết hành vi của nền tảng đọc từ đó.

Phê duyệt người bán hiện đang được yêu cầu và nó chặn cả API lẫn giao diện: người bán có tài khoản chưa được phê duyệt sẽ nhận được phản hồi chờ phê duyệt rõ ràng thay vì danh mục trống, điều này hữu ích để phân biệt khi tích hợp trả về không có gì.

Người bán nằm trên một trong năm bậc được tính từ doanh số quy kết trong mười hai tháng trượt. Bậc không chỉ mang tính trang trí. Nó đặt thời gian nền tảng chờ trước khi tự động giải phóng tiền và nó cung cấp cho việc tính toán giới hạn danh sách.

Đơn hàng di chuyển như thế nào

Trạng thái đơn hàng và trạng thái thanh toán được theo dõi riêng biệt và cả hai đều quan trọng khi bạn đọc API.

Trạng thái của một đơn hàng chạy qua đang chờ xử lý, đang xử lý, hoàn thành và sau đó có thể là hoàn tiền, với hủy và lỗi là các cạnh cuối. Trạng thái thanh toán là một trường riêng biệt với các giá trị riêng: hoàn thành, một phần, đã hoàn tiền, thất bại, đang chờ xử lý và đang xử lý. Một điều cần lưu ý nếu bạn đang viết bộ lọc: không có trạng thái thanh toán "đã thanh toán". Truy vấn cho một trạng thái như vậy trả về không có gì, trông giống như kết quả trống thay vì lỗi trong truy vấn.

Việc hoàn thành khác nhau theo loại danh sách. Danh sách tự động và dựa trên kho hàng bàn giao hàng tồn kho mà nền tảng đã nắm giữ. Danh sách thủ công là những danh sách cần người bán hoặc phần mềm của người bán hành động và đó là những gì API hoàn thành dành cho.

Khi người mua đã nhận được những gì họ đặt, một cửa sổ bảo hành sẽ mở ra. Nó được đo bằng giờ và chạy từ thời điểm giao hàng thay vì từ thanh toán, với mức sàn toàn trang là vài giờ và cài đặt riêng cho từng người bán cao hơn mức đó. Trong cửa sổ đó, người mua có thể mở vé hoặc tranh chấp; ngoài cửa sổ đó, tuyến tranh chấp từ chối. Tiền được giải phóng cho người bán khi người mua xác nhận hoặc khi bộ đếm thời gian tự xác nhận cho bậc của người bán đó hết hạn, tùy điều nào đến trước và một tranh chấp đang hoạt động sẽ giữ việc giải phóng.

API và sự khác biệt quan trọng nhất

Có hai bề mặt API, cả hai đều được xác thực bằng khóa.

Bề mặt dành cho người mua tuân theo quy ước bảng điều khiển được sử dụng rộng rãi: một điểm cuối duy nhất nhận tham số action. Các hành động tiêu chuẩn đều được triển khai, vì vậy công cụ bảng điều khiển hiện có hoạt động với nó: services để liệt kê những gì có sẵn, add để đặt hàng, status để kiểm tra một đơn, balance, refill và cancel. Trên cơ sở đó, nó thêm các hành động mà quy ước không định nghĩa: categories và subcategory_info để điều hướng phân loại, products và shops, allowcancel, inventory để kiểm tra kho và một bộ hành động xác minh SMS đầy đủ bao gồm dự án, quốc gia, đặt số và thăm dò mã. Hãy coi nó như quy ước tiêu chuẩn cộng với các phần mở rộng, thay vì một bản sao thay thế trực tiếp; các cuộc gọi tiêu chuẩn sẽ hoạt động không thay đổi và các phần mở rộng là nơi chứa khả năng dành riêng cho nền tảng.

Bề mặt dành cho người bán là một REST API thông thường bao gồm sản phẩm, đơn hàng, vé và thanh toán. Trong đó có một sự khác biệt quyết định liệu tích hợp của bạn có đúng hay không và rất dễ mắc lỗi vì cả hai điểm cuối đều trả về đơn hàng.

• Liệt kê đơn hàng là một thao tác đọc. Nó không xác nhận gì cả. Hai worker thăm dò nó đều nhận được cùng một đơn hàng và cả hai sẽ cố gắng giao hàng.
• Kéo đơn hàng là một thao tác xác nhận. Nó chuyển từng đơn hàng từ đang chờ xử lý sang đang xử lý bằng một ghi có điều kiện và chỉ trả về các đơn hàng mà ghi đó thực sự thắng. Nếu hai worker kéo đồng thời, mỗi cái nhận được một tập hợp rời nhau.

Bất cứ thứ gì hoàn thành tự động nên kéo, không nên liệt kê. Sử dụng thao tác đọc cho bảng điều khiển và đối soát, nơi việc thấy cùng một đơn hàng hai lần là vô hại.

Ba chi tiết nữa giúp tiết kiệm một buổi chiều. Kéo chỉ trả về các dòng hoàn thành thủ công, vì vậy hàng tồn kho tự động và dựa trên kho sẽ không bao giờ xuất hiện ở đó. Lô mặc định là một trăm đơn hàng và trần là năm trăm. Và một đơn hàng được kéo sẽ không được đề xuất lại trong khoảng nửa giờ, đây là một biên độ an toàn có chủ đích: nếu worker của bạn sập sau khi kéo, đơn hàng sẽ tự quay lại, nhưng không phải ngay lập tức.

Tài liệu tham khảo đầy đủ cho cả hai bề mặt nằm tại tài liệu API người mua và tài liệu API người bán.

Thanh toán và số dư

Nền tảng chạy một số dư nội bộ mà hầu hết hoạt động chảy qua. Người mua nạp tiền và chi tiêu từ đó, hoàn tiền được ghi có vào đó và đó là nơi phần lớn đơn hàng thực sự được thanh toán. Cả kênh tiền điện tử và thanh toán thông thường đều được hỗ trợ để nạp tiền, một số thanh toán trực tiếp và một số khác thông qua bộ xử lý thanh toán.

Người bán yêu cầu thanh toán dựa trên giá trị đơn hàng đã thanh toán và được giải phóng. Một mức tối thiểu được áp dụng, đặt trên toàn nền tảng với các mức tối thiểu bổ sung theo phương thức và thanh toán mang phí phần trăm. Không có hoa hồng theo đơn hàng nào được lấy từ người bán, vì vậy phí thanh toán là nơi phần cắt của nền tảng nằm thay vì trong chính việc bán hàng.

Hỗ trợ và tranh chấp

Hỗ trợ chạy qua hệ thống vé được chia sẻ bởi cả ba vai trò, vì vậy người mua, người bán và bộ phận hỗ trợ có thể ở trong một luồng thay vì ba cuộc trò chuyện không bao giờ gặp nhau. Vé mang phân loại vấn đề và người bán có thể giải quyết bằng cách thay thế mặt hàng đã giao, hoàn tiền hoặc từ chối yêu cầu.

Tranh chấp là tuyến nặng hơn và cố tình hẹp hơn: chúng yêu cầu đơn hàng phải hoàn thành và nằm trong cửa sổ bảo hành, ít nhất một ảnh chụp màn hình và lựa chọn từ danh sách vấn đề hai cấp. Chúng kết thúc với việc tiền đi đến người bán hoặc trở lại người mua. Thay thế không phải là kết quả của tranh chấp, đó là lý do tại sao tuyến vé giải quyết phần lớn các vấn đề thực tế và tại sao mở vé trước thường là con đường nhanh hơn.

Những gì chạy theo lịch trình

Một số điều xảy ra mà không ai kích hoạt chúng và việc tích hợp dễ suy luận hơn khi biết chúng tồn tại: tiền tự xác nhận và giải phóng sau độ trễ bậc của người bán; một tranh chấp bị bỏ mặc sau khi tất cả vé của nó được đóng sẽ được giải quyết có lợi cho người bán sau một số ngày cố định; vị trí nổi bật hết hạn trên một công việc hàng ngày; các chia sẻ quảng cáo đã được phê duyệt được kiểm tra lại hàng tuần; và văn bản danh sách được quét theo lô theo các quy tắc liên hệ ngoài nền tảng.

Không có điều nào trong số này tự thông báo cho API. Nếu đối soát của bạn thấy một đơn hàng thay đổi trạng thái mà không có cuộc gọi nào từ bạn, một trong số chúng thường là lý do.

Bắt đầu

1. Đăng ký, sau đó yêu cầu phê duyệt người bán nếu bạn định bán. Phê duyệt chặn cả API lẫn giao diện.
2. Tạo danh sách hoặc nhập dịch vụ tăng trưởng từ nhà cung cấp ngược dòng đã cấu hình theo lô thay vì từng cái một.
3. Tạo khóa API và xác nhận vai trò của bạn bằng cách gọi điểm cuối hồ sơ trước bất cứ điều gì khác.
4. Nếu bạn hoàn thành thủ công, hãy xây dựng dựa trên điểm cuối kéo ngay từ đầu. Chuyển từ liệt kê sang kéo sau khi bạn đã giao hàng trùng lặp là một ngày tồi tệ hơn việc đọc đoạn này.
5. Đặt giờ bảo hành cho từng danh sách một cách có chủ đích. Đó là chiếc đồng hồ mà mọi biện pháp bảo vệ người mua trên nền tảng chạy theo và nó bắt đầu từ thời điểm giao hàng.