연동하기
플랫폼·다중 가맹점
여러 판매자의 결제를 중개하는 SaaS·마켓플레이스의 구조 설계 원칙입니다.
먼저 정할 것 — 누가 실제 판매자인가
| 모델 | 실제 판매자 | 구조 | 정산 |
|---|---|---|---|
| A. 자사 서비스 | 솔루션사 자체 | PLATFORM 1 : STORE 1 | 자사 가맹점 계좌 |
| B. 다중 가맹점 SaaS | 솔루션을 쓰는 각 업체 | PLATFORM 1 : STORE N | 각 가맹점 계좌 |
| C. 마켓플레이스 | 판매자·중개자 구조에 따라 | 거래 유형별 검토 | 자금 배분 구조 별도 심사 |
- 판매자·정산계좌 명의·환불 책임·영수증 발급 주체가 한 STORE에서 일치해야 합니다.
- 여러 판매자 매출을 플랫폼의 STORE 하나로 모으는 우산 가맹점은 허용하지 않습니다.
- 카리페이는 결제대금을 보관·배분하지 않습니다. C 모델은 법무 검토 후 설계합니다.
구현
- 판매자 온보딩 — 판매자별 사업자 서류를 접수해 카리페이가 STORE를 등록하고
STORE_CODE를 발급합니다(영업일 2~5일). - 매핑 — 귀사 DB에
판매자 ↔ STORE_CODE를 저장합니다.PLATFORM_CODE·API_KEY는 플랫폼 하나입니다. - 결제 생성 — 주문의 판매자에 해당하는
STORE_CODE로requestPayment를 호출합니다. 서명에도 그STORE_CODE가 들어갑니다.
JavaScript
const pay = new CariPay({ platformCode, storeCode: seller.storeCode, apiKey, mode: "live" });
await pay.createPayment({ /* ... */ });- 조회·취소도 결제를 만든
STORE_CODE로 호출합니다. 다른 STORE로 조회하면4003 결제요청 정보가 없습니다가 납니다. - 대사 — 판매자별로 승인·취소 합계를 일 단위로 맞춥니다.
청구서 API를 쓰는 플랫폼
청구서 API는 가맹점 계정 단위입니다. 판매자마다 콘솔 계정·포인트가 분리되며, 플랫폼이 대신 발송하려면 판매자 계정의 토큰을 판매자 동의 하에 보관해야 합니다. 다른 판매자의 토큰을 공유해 쓰지 마세요.
온보딩 게이트
- 사업자·판매자·정산 명의 확정
- VAN 가맹 승인
- STORE 연결(온라인) · CAT 연결(단말)
BASE_URL·플랫폼·STORE·API Key 발급- 생성·조회·취소·중복 콜백 UAT
- 장애 연락망·대사·환불 책임 확정
문서에 없는 내용이나 오류는 bellight@goatheaven.com 또는 지원 문의로 알려주세요.