결제연동 · 수입금 대사 · 환불 운영을
하나로 묶었습니다
앱과 서버는 공통 결제 API 하나만 호출합니다. 결제사가 바뀌어도 앱은 바뀌지 않습니다. 바뀌는 것은 Connector 하나입니다.
데모 환경 · 테스트 데이터로 운영 중 · 결제사 테스트 상점(실결제 없음)
01 지금의 문제
결제사마다 서버가 하나씩, 정산은 엑셀로
채널이 늘수록 장애 지점과 수작업이 함께 늘어납니다.
지금의 절차
결제·제휴 채널마다 연동 서버(브릿지)를 따로 만들고 따로 운영합니다.
결제사가 보내 준 정산 파일을 사람이 받아 엑셀로 거래와 대조합니다.
환불은 전화·메일로 접수하고, 승인 근거는 담당자 메일함에 남습니다.
채널 N개 = 변경·장애 지점 N개
결제사 규격이 바뀌면 서버마다 다시 고칩니다.
누락·중복 승인을 다음 날 알게 됩니다
정산 때가 되어서야 차이를 발견합니다.
마감이 늦어지고 원인 추적이 어렵습니다
차액이 나면 거래 단위로 거슬러 올라가기 힘듭니다.
환불 승인 근거가 흩어집니다
감사 때 다시 모아야 합니다.
02 제품 소개
앱·서버는 공통 결제 API 하나만 호출합니다
모듈 6개와 Connector Pack 으로 구성됩니다. 가운데에 모든 거래의 기준이 되는 원장(Transaction Ledger)이 있습니다.
Core Runtime
결제 요청을 받고, 서버가 금액을 대조해 확정하고, 취소·미확정 거래까지 끝까지 책임집니다.
Gateway & Connector Hub
앱·서버가 부르는 공통 결제 API 하나. 결제사별 차이는 연결 규격(Adapter Contract) 뒤로 숨깁니다.
Transaction Ledger
모든 거래에 공통 거래번호를 붙이고 상태 이력과 결제사 원본 응답을 보관합니다.
Operations Console
거래 통합 조회, 예외·환불 승인, 권한 3종과 감사 기록을 한 화면에서 다룹니다.
Reconciliation Hub
정산 자료를 자동으로 모아 3자 대사(원장·결제사·정산)하고 일 마감합니다.
Refund Operations
환불 규정을 적용해 신청·검토·승인하고 계좌 환불 이체 파일까지 만듭니다.
Connector Pack — 채널별 연결 모듈. 데모는 토스페이먼츠로 끝까지(요청 → 확정 → 취소 → 조회) 동작하며, 그 외 채널은 도입 시 Connector 하나를 더 만드는 일입니다.
03 이용 흐름
결제 요청에서 환불까지, 서버가 기준입니다
결제창이 돌려준 값은 그대로 믿지 않습니다. 금액 대조 · 중복 승인 방지 · 통지 재검증이 기본 동작입니다.
구매자 경로
결제 요청 등록 → 결제창(결제사) → 서버 기준 확정 → 결과 화면
운영자 경로
거래 상세 · 상태 이력 → 취소(전체·부분) → 대사 결과 · 예외 → 환불 승인
금액 대조
결제창이 돌려준 금액·주문번호를 원장과 대조해 다르면 거부합니다(변조 차단).
승인은 한 번
같은 요청을 다시 보내도 승인은 1건. 재전송에는 처음과 같은 응답을 돌려줍니다.
통지 재검증
결제사 통지는 본문을 믿지 않고 결제사에 다시 조회해 확인한 뒤 반영합니다.
04 솔루션 구성
이번 데모에서 보이는 것, 도입하며 만드는 것
데모 주소에서 직접 눌러 볼 수 있는 것과, 코드·설계·절차 문서로 보이는 것, 도입 계약 뒤 개발하는 것을 구분해 적습니다.
| 모듈 | 데모에서 확인 | 문서로 증빙 | 로드맵(도입 시 개발) |
|---|---|---|---|
| Core Runtime | 결제 요청 등록 · 서버 기준 확정 · 전체/부분 취소 · 조회 · 재전송 시 승인 1건 · 미확정 거래 자동 재조회 | 상태 전이 규칙 · 멱등 처리 규칙 | 정기 결제 · 예약 결제 |
| Gateway & Connector Hub | 공통 결제 API(OpenAPI 3.0) · API 키 인증과 IP 제한 · 토스페이먼츠 Connector · 모의 결제사 Connector | 연결 규격(Adapter Contract) · 카카오페이 Connector 코드 | 페이코 · 네이버페이 · 제로페이 · 티머니 · 쏘카 · 디스커버서울패스 · H.Point · 쿠폰 등 |
| Transaction Ledger | 공통 거래번호 · 상태 이력 · 결제사 원본 응답 보관 · 거래 조회·상세 | 월 파티션 · 데이터 사전 | 보존·파기 정책 · 현행 데이터 이관 |
| Operations Console | 로그인 · 권한 3종 · 계정 관리 · 접속·감사 기록 · 대시보드 · 거래 조회·상세·취소 · 웹훅 수신 로그 · 채널 설정 · 보고서 CSV · 결제 샘플 화면 | 화면 설계 · 운영 매뉴얼 · 데모 이용 안내서 | 2단계 인증 · 다기관(중앙) 콘솔 |
| Reconciliation Hub | 정산 자료 수집(CSV · 결제사 API · 샘플) · 3자 대사 · 예외 대기열(사유코드 5종) · 일 마감과 재오픈 · 보고서 CSV | 대사 규칙·샘플 데이터 설계 · Spring Batch 잡 | 정산 파일 자동 수신(SFTP) · 다채널 동시 대사 · 회계 연계 |
| Refund Operations | 환불 신청(규정 적용) · 검토 · 승인(검토자와 다른 사람) · 결제사 취소 자동 실행 · 계좌 환불 이체 파일 | 환불 규정 v1 · 승인 기록 | 은행 펌뱅킹 연계 · 기관별 규정 세분화 |
| Connector Pack | 토스페이먼츠(테스트 상점 승인·취소·조회·통지) | 수단 10종 조사·분류 | 그 외 채널 전부 도입 시 개발 |
데모에서 확인 = 데모 주소에서 직접 동작문서로 증빙 = 코드·설계·절차 문서로드맵 = 도입 계약 뒤 개발
05 도입 방식
기관 환경에 설치해 드리고, 운영까지 함께합니다
설치형 소프트웨어입니다. 컨테이너로 만들어 어디에나 같은 방식으로 설치합니다.
기관 PaaS(쿠버네티스)
Helm 차트 한 번으로 설치합니다. 설치 시험을 마쳤습니다.
공공 클라우드
같은 컨테이너 이미지(OCI)를 그대로 올립니다.
단일 서버(도커)
실행 단위 6종과 PostgreSQL 을 도커로 띄웁니다.
포함 서비스
설치·초기 설정, 운영자 교육, 운영 매뉴얼, 기술지원 창구, 보안 패치·업데이트, 하자보수.
추가 개발
채널 Connector 추가, 기관 시스템 연계, 현행 데이터 이관(별도 견적).
전자정부 표준프레임워크 5.0 위에서 동작하므로 기관 표준 환경과 같은 방식으로 운영·점검할 수 있습니다. 구성·가격은 문의해 주세요.
06 보안·표준
카드정보는 저장하지 않고, 표준 위에서 동작합니다
결제 보안의 기본을 설계부터 넣었습니다. 저장하지 않고, 검증하고, 기록합니다.
카드정보 미저장
카드번호·CVC 를 받지도 저장하지도 않습니다. 원장에는 결제사가 마스킹한 값만 남습니다.
서버 기준 검증
금액 대조로 변조를 거부하고, 같은 요청은 승인 1건, 결제사 통지는 재조회로 확인한 뒤 반영합니다.
인증정보 분리
결제사 비밀 키는 서버에만 두고 화면·브라우저에는 내려보내지 않습니다. 저장은 암호화하고 교체 이력을 남깁니다.
권한·기록
관리자·검토자·지급자 권한 분리, 계정 잠금, 접속 기록, 감사 기록 조회.
표준·배포
전자정부 표준프레임워크 5.0(Spring Boot 3.5), OCI 컨테이너 이미지, SBOM(소프트웨어 구성 명세) 생성.
연계 표준
OpenAPI 3.0 명세, API 키 인증과 IP 제한, 전송 구간 TLS.
개발보안 항목 진단과 검증필 암호모듈 연동은 공급 계약 단계에서 기관 절차에 맞춰 진행합니다.
문의
데모와 자료를 요청하세요
데모 이용 안내서(계정 3종, 15분 시나리오)와 제품 소개서, OpenAPI 명세를 요청 시 제공합니다.
데모
demo.ixpay.co.kr · 테스트 데이터로 운영 중