HstockPlus 플랫폼: 주문, 주문 처리, 그리고 API가 실제로 어떻게 맞물려 작동하는지

이 페이지는 마켓플레이스가 하나의 시스템으로 어떻게 작동하는지 설명합니다: 어떤 역할이 있고, 주문이 어떤 경로를 거치며, API가 무엇을 노출하는지. 이 페이지에서는 아무것도 판매되지 않습니다.

하나가 아닌 두 개의 카탈로그

플랫폼은 두 종류의 재고를 보유하며, 이 둘은 충분히 다르게 작동해서 하나로 취급하면 문제가 생깁니다.

상품 리스팅은 판매자의 인벤토리에서 단위로 판매되는 디지털 상품입니다: 계정, 메일박스, 프록시, 키. 구매자에게는 언제든 약 1만 7천 개가 보이며, 이는 초안, 승인 대기 중인 리스팅, 판매자가 비활성화한 리스팅을 포함한 더 큰 카탈로그에서 가져옵니다. 이들은 카테고리와 하위 카테고리로 그룹화되고, 필터링을 위해 태그가 붙으며, 리스팅별이 아닌 변형별로 가격이 책정되어, 단일 리스팅이 서로 다른 가격의 여러 구매 가능한 옵션을 가질 수 있습니다.

성장 서비스는 수량 기반입니다: 링크에 대해 팔로워, 조회수, 댓글 수를 주문합니다. 약 3만 개가 활성 상태입니다. 이들은 자체 분류 체계와 자체 태그 어휘를 사용하며, 판매자의 상품 리스팅 한도에 포함되지 않습니다.

판매자는 활성 카탈로그 기준으로 수백 명 미만이며, 약 1,500개의 판매자 역할 계정이 약 560개 상점에 분포해 있습니다.

역할과 각 역할이 접근할 수 있는 것

세 가지 역할이 있으며, 이들은 배타적이지 않고 추가적이므로 한 계정이 구매자이면서 동시에 판매자가 될 수 있습니다.

• 구매자는 탐색, 주문, 사이트 잔액 보유, 주문 추적, 지원 티켓 열기가 가능합니다.
• 판매자는 리스팅과 인벤토리 관리, 주문 처리, 쿠폰 구성, 출금 요청을 합니다. 판매자 프로필은 공개적으로 표시되도록 설정할 수 있어 구매자가 한 곳에서 해당 판매자가 제공하는 모든 것을 탐색할 수 있습니다.
• 관리자는 판매자와 리스팅을 승인하고, 분쟁을 해결하며, 플랫폼의 대부분 동작이 참조하는 설정을 보유합니다.

판매자 승인은 현재 필수이며, API와 인터페이스 모두를 제한합니다: 승인되지 않은 판매자 계정은 빈 카탈로그 대신 명시적인 승인 대기 응답을 받습니다. 이는 통합이 아무것도 반환하지 않을 때 구분하는 데 유용한 사항입니다.

판매자는 지난 12개월간 귀속 매출에서 파생된 5개 등급 중 하나에 속합니다. 등급은 장식이 아닙니다. 자금을 자동으로 해제하기 전에 플랫폼이 기다리는 시간을 결정하며, 리스팅 한도 계산에도 영향을 줍니다.

주문이 어떻게 진행되는지

주문 상태와 결제 상태는 별도로 추적되며, API를 읽을 때 둘 다 중요합니다.

주문 자체의 상태는 대기, 처리 중, 완료를 거쳐 환불 가능성이 있으며, 취소와 오류가 종료 지점입니다. 결제 상태는 별도의 필드로 자체 값을 가집니다: 완료, 부분, 환불됨, 실패, 대기, 처리 중. 필터를 작성하는 경우 주의할 점이 하나 있습니다: "결제됨" 결제 상태는 없습니다. 이에 대한 쿼리는 아무것도 반환하지 않으며, 이는 쿼리 오류가 아니라 빈 결과처럼 보입니다.

이행은 리스팅 유형에 따라 다릅니다. 자동 및 인벤토리 기반 리스팅은 플랫폼이 이미 보유한 재고를 전달합니다. 수동 리스팅은 판매자나 판매자의 소프트웨어가 조치를 취해야 하는 것이며, 이것이 이행 API의 용도입니다.

구매자가 주문한 것을 받으면 보증 기간이 시작됩니다. 이는 시간 단위로 측정되며 결제가 아닌 배송 시점부터 진행되며, 사이트 전체 최소 시간과 그 위에 판매자별 설정이 있습니다. 이 기간 내에 구매자는 티켓이나 분쟁을 열 수 있고, 기간 외에는 분쟁 경로가 거부됩니다. 자금은 구매자가 확인하거나 해당 판매자 등급의 자동 확인 타이머가 만료될 때 중 먼저 도래하는 시점에 판매자에게 해제되며, 진행 중인 분쟁은 해제를 보류합니다.

API와 가장 중요한 하나의 구분

두 개의 API 표면이 있으며, 둘 다 키로 인증됩니다.

구매자 대상 표면은 널리 사용되는 패널 규약을 따릅니다: action 매개변수를 취하는 단일 엔드포인트. 표준 작업이 모두 구현되어 있어 기존 패널 도구가 그대로 작동합니다: services는 사용 가능한 것을 나열하고, add는 주문을 넣고, status는 확인하고, balance, refill, cancel이 있습니다. 그 위에 규약이 정의하지 않은 작업을 추가합니다: categories와 subcategory_info는 분류 탐색용, products와 shops, allowcancel, inventory는 재고 확인용, 그리고 프로젝트, 국가, 번호 주문, 코드 폴링을 포함한 전체 SMS 인증 작업 세트가 있습니다. 이를 드롭인 클론이 아닌 표준 규약과 확장으로 취급하십시오; 표준 호출은 변경 없이 작동하며, 확장이 플랫폼 고유 기능이 있는 곳입니다.

판매자 대상 표면은 제품, 주문, 티켓, 결제를 다루는 일반적인 REST API입니다. 그 안에 통합의 정확성을 결정하는 하나의 구분이 있으며, 두 엔드포인트 모두 주문을 반환하기 때문에 잘못 이해하기 쉽습니다.

• 주문 나열은 읽기입니다. 아무것도 주장하지 않습니다. 두 작업자가 폴링하면 둘 다 동일한 주문을 받고, 둘 다 배송하려고 시도합니다.
• 주문 가져오기는 주장입니다. 조건부 쓰기로 각 주문을 대기에서 처리 중으로 이동시키고, 쓰기가 실제로 성공한 주문만 반환합니다. 두 작업자가 동시에 가져오면 각각 서로 겹치지 않는 세트를 받습니다.

자동으로 이행하는 모든 것은 나열이 아닌 가져오기를 사용해야 합니다. 동일한 주문을 두 번 보는 것이 무해한 대시보드와 조정에는 읽기를 사용하십시오.

세 가지 추가 세부 사항이 시간을 절약해 줍니다. 가져오기는 수동 이행 항목만 반환하므로 자동 및 인벤토리 기반 재고는 절대 나타나지 않습니다. 기본 배치는 100개 주문이고 상한은 500개입니다. 그리고 가져온 주문은 약 30분 동안 다시 제공되지 않으며, 이는 의도적인 안전 여유입니다: 작업자가 가져온 후 충돌하면 주문이 자체적으로 돌아오지만 즉시는 아닙니다.

두 표면의 전체 참조는 구매자 API 문서와 판매자 API 문서에 있습니다.

결제와 잔액

플랫폼은 대부분의 활동이 흐르는 내부 잔액을 운영합니다. 구매자는 이를 충전하고 사용하며, 환불은 여기에 적립되고, 대부분의 주문이 실제로 여기서 결제됩니다. 충전에는 암호화폐와 일반 결제 채널이 모두 지원되며, 일부는 직접 정산되고 다른 일부는 결제 처리업체를 통해 정산됩니다.

판매자는 정산되고 해제된 주문 금액에 대해 출금을 요청합니다. 플랫폼 전체에 설정된 최소 금액이 적용되고 그 위에 방법별 추가 최소 금액이 있으며, 출금에는 백분율 수수료가 부과됩니다. 판매자에게 주문별 수수료는 없으므로 출금 수수료가 판매 자체가 아닌 플랫폼의 수익이 있는 곳입니다.

지원과 분쟁

지원은 세 역할 모두가 공유하는 티켓 시스템을 통해 운영되므로 구매자, 판매자, 지원팀이 서로 만나지 않는 세 개의 대화가 아닌 하나의 스레드에 있을 수 있습니다. 티켓에는 문제 분류가 있으며, 판매자는 배송된 항목을 교체하거나 환불하거나 청구를 거부하여 해결할 수 있습니다.

분쟁은 더 무거운 경로이며 의도적으로 더 좁습니다: 주문이 완료되고 보증 기간 내에 있어야 하며, 최소 하나의 스크린샷과 2단계 문제 목록에서 선택이 필요합니다. 분쟁은 자금이 판매자에게 가거나 구매자에게 돌아가는 것으로 끝납니다. 교체는 분쟁 결과가 아니므로, 티켓 경로가 실제 문제의 대다수를 해결하고 티켓을 먼저 여는 것이 일반적으로 더 빠른 경로입니다.

자동으로 실행되는 것

누군가가 트리거하지 않아도 여러 가지가 발생하며, 이들이 존재한다는 것을 알면 통합을 더 쉽게 추론할 수 있습니다: 자금은 판매자 등급 지연 후 자동 확인 및 해제되고, 모든 티켓이 닫힌 후 방치된 분쟁은 고정된 일수 후 판매자에게 유리하게 해결되며, 추천 배치는 일일 작업으로 만료되고, 승인된 프로모션 공유는 주간으로 재확인되며, 리스팅 텍스트는 플랫폼 외 연락처 규칙에 대해 배치로 스캔됩니다.

이 중 어느 것도 API에 스스로 알리지 않습니다. 조정에서 사용자의 호출 없이 주문 상태가 변경되는 것을 보면, 대개 그 중 하나가 이유입니다.

시작하기

1. 등록한 후 판매하려면 판매자 승인을 요청하십시오. 승인은 인터페이스뿐만 아니라 API도 제한합니다.
2. 리스팅을 만들거나, 구성된 업스트림 공급자에서 성장 서비스를 하나씩이 아닌 대량으로 가져오십시오.
3. API 키를 생성하고 다른 것보다 먼저 프로필 엔드포인트를 호출하여 역할을 확인하십시오.
4. 수동으로 이행한다면 처음부터 가져오기 엔드포인트를 기준으로 구축하십시오. 중복 배송을 한 후 나열에서 가져오기로 전환하는 것은 이 문단을 읽는 것보다 더 나쁜 날입니다.
5. 리스팅별 보증 시간을 의도적으로 설정하십시오. 이는 플랫폼의 모든 구매자 보호가 작동하는 시계이며, 배송 시점부터 시작됩니다.