티스토리 뷰
오늘은 이전 '결제 프로세스 및 사업자별 역할' 포스팅한 학습내용을 바탕으로 간단한 결제 서비스를 구현을 해보기 이전에 구현 과정에서 필요한 결제 API 분석과 요구사항 정의 및 엔티티 구성 내용을 정리해보았습니다.
1. 결제 API 분석
이번 결제 서비스를 구축하기 위해 선정한 외부 API는 '포트원' 입니다. 포트원을 선정한 이유는 레퍼런스가 많고, 구현을 위해 제공되는 공식문서가 잘 정리되어 있다는 점이 가장 큰 메리트로 판단되었기 때문입니다. (참고로 포트원은 기존 import에서 변경된 명칭입니다.)
포트원은 GitBook을 활용하여 개발가이드를 제공해 주고 있으며, 대표적인 결제방식으로는 인증 결제 방식과 비 인증 결제 방식을 지원하고있습니다.
인증 결제
인증 결제란 고객이 신용카드 결제를 요청할 경우 가맹점은 PG사에 결제에 대한 인증을 요청하고, 요청한 결제의 키를 받아 실제 결제를 요청하는 방식입니다.
인증결제는 일반적으로 위와 같은 flow로 이루어 지며, 대표적 인증 방식은 ISP 결제와 MPI 결제 2가지 방식이 있습니다.
포트원을 통해 결제연동을 진행할 경우 일반결제 방식과 달리 한 번의 요청으로 결제처리가 이루어지기 때문에
복잡한 백엔드 개발 과정이 축약되는 이점이 있습니다.
ISP (Internet Secure Payment) 결제
공개키 기반의 전자인증서를 통해 사전에 등록된 카드정보를 인증하는 방식으로 신용카드번호,비밀번호 등 개인정보 유출 및 카드 도용방지에 용의하며, ISP 인증번호를 통해 결제함으로 간편하다는 장점이 있습니다.
MPI(Merchant Plug-In) 결제
카드번호, CVC, 안심클릭 비밀번호를 입력하여 카드정보를 인증하는 방식으로 일반 결제에서 사용되는 인증방식입니다.
'인증'과 '인가'의 차이가 무엇인가요?
인증 : 인증이란 사용자의 신원을 검증하는 프로세스로 외부 API에 요청하기전 인증키를 발급 받기 위한 절차를 의미합니다.
인가 : 인가란 사용자의 권한을 검증하는 프로세스로 사용자가 특정 request를 실행할 권한이 있는지를 확인하는 절차를 의미합니다.
위의 내용은 얼마전 면접에서 받은 질문입니다.
저는 이전 프로젝트에서 결제 서비스를 외부 API를 이용하여 구현했음에도 불구하고 사전 지식이 없어 제대로 답변하지 못하였습니다.
조금 뜬금 없지만 이 글을 읽으시는 분들은 꼭 참고하시면 좋을 듯하여 작성해보았습니다.
비 인증 결제
카드 정보를 미리 등록해두고 원하는 때에 고객의 별도 인증 없이 결제를 요청하는 방식입니다. 결제 요청인의 인증 없이도 결제를 진행할 수 있어 간편하다는 장점을 가지고 있지만 인증 과정이 생략되어 보안상 이슈가 발생될 확률이 높습니다. 이러한 특징으로 인해 PG 가입시 입점 심사가 까다롭게 진행되는 편이라고 합니다.
비 인증 결제 방식은 빌링키 결제와 키인 결제가 방식이 있으며 자세한 방식은 아래와 같습니다.
빌링키(biling key) 결제
주로 구독형 정기 결제, 종량제 과금결제 등에서 많이 사용되는 방식으로 최초 등록된 결제 정보로 반복적인 결제가 이루어지는 방식입니다. 요청한 사람이 원하는 시점에 결제를 진행할 수 있도록 카드사로부터 해당 카드에 대응하는 빌링키를 발급 받아 저장하고 원하는 시점에 해당 빌링키로 결제를 청구할 수 있다는 특징이 있습니다.
키인(key in) 결제
키인 결제는 신용카드 번호 및 카드 정보를 수기로 입력하여 구매자 인증 없이 카드번호 입력만으로 결제는 방식입니다. 해당 방식은 인증절차가 없기 때문에 일회성 결제만 가능하며 일부 카드사는 허용하지 않는 다는 특징이 있습니다.
위와 같은 결제 방식을 포트원에서 지원하는 연동 서비스를 통해 구현이 가능하며,
조금 더 자세한 사항은 포트원 개발 가이드를 통해 확인하실 수 있습니다.
2. 요구사항 정의 및 엔티티 도출
요구사항 정의
결제 서비스를 개발하기 위해 스스로가 PM이 되었다 생각하고 간단하게 요구사항을 정의 해보았습니다. 작은 규모의 프로젝트이기에 복잡한 요구사항이 아닌 결제에 해당하는 기본이라 판단되는 사항만 작성한 점 참고 부탁드립니다.
| 서비스 | 기능명 | 상세설명 |
| 결제 | 결제 요청 | 구매자 결제 정보 정상 확인 후 결제 창 호출 및 결제 요청. 결제 정상 처리 내용 알림 |
| 결제 취소 - 전체 취소 | 구매자 결제 금액 전체 취소 요청시 정상 취소 가능 여부 확인 후 결제 취소 처리 요청 | |
| 결제 취소 - 부분 취소 | 구매자 결제 금액 부분 취소 요청시 정상 취소 가능여부 확인 후 결제 취소 처리 요청 |
위와 같은 요구사항을 정의 후 필요한 엔티티를 구성해보았으며, 결제시 필요한 핵심 엔티티로 아래와 같습니다.
엔티티 도출
1. 결제를 요청할 '회원'
2. 회원이 주문할 '상품'
3. 상품 구매 요청을 위한 '주문'
4. 주문을 통해 발생할 데이터를 담을 '결제'
핵심 엔티티를 바탕으로 커머스 서비스에서 보편적으로 사용하는 '포인트' 와 '쿠폰'을 서브 엔티티로 추가하여 엔티티 구성을 마무리했습니다.
마무리
지금까지 결제 서비스 구축을 위한 기본적인 과정에대해 정리해보았습니다.
다음 포스팅에서는 위와 같은 요구사항과 엔티티 구성을 바탕으로 결제 서비스 ERD 설계 과정 및 기본 백엔드 서버 구축 과정에 대해 정리해보도록 하겠습니다.
참고자료 출처 = {
}
연관된 포스팅 = {
}
'Study' 카테고리의 다른 글
| [CS] 데이크스트라 알고리즘(Dijkstra algorithm) 분석 (0) | 2023.04.23 |
|---|---|
| [Service] 결제 프로세스 및 사업자별 역할 (0) | 2023.04.02 |
| Vanilla coding _ Number Baseball Ga (0) | 2022.06.02 |
- Total
- Today
- Yesterday