{"content_id":"dtvo1yuy0p","slug":"ai-payment-feature-7-core-decisions","locale":"ko","schema_type":"TechArticle","category":"how_to","category_name":"하우투","title":"AI로 결제 기능을 만들 때 먼저 정해야 할 7가지","summary":"AI는 결제 코드를 빠르게 만들 수 있지만, 결제 기능의 안전성은 주문 상태, 환불 기한, 부분 환불, 이중 결제 방지 같은 정책 설계에 달려 있습니다. 특히 한국 전자상거래 서비스라면 청약철회와 환불 지연 이자, 환불 규정 고지, 다크패턴 회피를 개발 요구사항에 명확히 반영해야 합니다.","author":{"name":"인조이스 편집팀","url":"https://injoys.com/ko/about"},"key_points":["결제 기능은 단순한 카드 승인 기능이 아니라 주문, 정산, 환불, 고객 응대, 법적 고지가 연결된 운영 시스템입니다.","주문 상태는 결제 대기, 결제 완료, 취소, 환불 진행 중, 환불 완료처럼 고객과 운영자가 같은 의미로 이해할 수 있게 정의해야 합니다.","한국 전자상거래에서는 일반적으로 소비자의 청약철회 기간, 사업자의 환불 처리 기한, 지연 이자 규정을 고려해야 합니다.","이중 결제 방지는 버튼 비활성화만으로 부족하며, 서버 단의 멱등성 키, 주문 잠금, 결제 승인 중복 검사가 필요합니다.","환불 규정과 취소 방법을 숨기거나 해지를 어렵게 만드는 설계는 고객 신뢰를 해치고 다크패턴 규제 위험을 높입니다."],"content_markdown":"## 핵심 요약\n\nAI에게 결제 기능을 맡길 때 가장 위험한 프롬프트는 단순히 ‘결제 붙여줘’라고 요청하는 것입니다. 결제는 돈을 받는 코드가 아니라 돈의 흐름을 책임지는 운영·회계·고객지원 시스템입니다.\n\n기술적으로는 결제창 연동, 승인 API 호출, 웹훅 수신, 주문 저장을 AI가 빠르게 구현할 수 있습니다. 그러나 다음 정책이 정해져 있지 않으면 실제 서비스에서는 유령 주문, 이중 결제, 환불 지연, 고객센터 폭주, 법적 고지 누락 문제가 발생할 수 있습니다.\n\n| 결정 영역 | 미리 정해야 할 질문 | 실패 시 위험 |\n|---|---|---|\n| 주문 상태 | 주문은 어떤 상태를 순서대로 거치는가? | 결제는 됐지만 주문이 없는 유령 주문 발생 |\n| 환불 기한 | 청약철회와 환불 처리 기한을 어떻게 반영할 것인가? | 법정 기한 위반, 지연 이자, 분쟁 위험 |\n| 부분 환불 | 일부 상품 반품, 쿠폰, 배송비를 어떻게 계산할 것인가? | 운영자가 매번 수동 계산, 고객 불신 |\n| 이중 결제 | 같은 주문에 결제가 두 번 잡히지 않게 어떻게 막을 것인가? | 카드 명세서 기준 고객 불만, 신뢰 하락 |\n| 실패 안내 | 한도 초과, 잔액 부족, 인증 실패를 어떻게 안내할 것인가? | 재시도 전환율 하락, 불필요한 문의 증가 |\n| 결제 내역 | 고객이 결제와 환불 상태를 어디서 확인하는가? | 고객센터 문의 증가, 상태 불투명 |\n| 환불 고지 | 환불 규정과 취소 버튼을 어디에 배치하는가? | 다크패턴 논란, 규제 리스크 |\n\n## 1. 주문 상태 설계: 상태가 곧 운영 언어다\n\n결제 기능을 만들 때 주문 상태를 ‘주문 완료’ 하나로만 두면 안 됩니다. 실제 주문은 결제 시도, 승인, 취소, 환불, 실패, 만료 같은 여러 단계를 거칩니다.\n\n### 권장 상태 예시\n\n| 상태 코드 예시 | 고객에게 보이는 상태 | 의미 |\n|---|---|---|\n| `payment_pending` | 결제 대기 | 주문은 생성됐지만 결제가 끝나지 않음 |\n| `paid` | 결제 완료 | 결제 승인이 완료되어 주문이 유효함 |\n| `payment_failed` | 결제 실패 | 결제 시도가 실패했고 재시도 가능 여부를 판단해야 함 |\n| `cancel_requested` | 취소 요청 | 고객이 취소를 신청했고 처리 대기 중임 |\n| `cancelled` | 취소 완료 | 결제 전 주문 취소 또는 승인 취소가 완료됨 |\n| `refund_requested` | 환불 요청 | 결제 후 환불 신청이 접수됨 |\n| `refund_processing` | 환불 진행 중 | 환불 승인 또는 결제수단 환급 처리 중임 |\n| `partially_refunded` | 부분 환불 완료 | 주문 금액 중 일부만 환불됨 |\n| `refunded` | 환불 완료 | 환불 처리가 완료됨 |\n| `expired` | 주문 만료 | 결제 대기 시간이 지나 주문이 무효화됨 |\n\n### 상태 설계 원칙\n\n- 주문 상태와 결제 상태를 완전히 같은 것으로 보지 않습니다. 주문은 존재하지만 결제가 실패할 수 있고, 결제는 승인됐지만 주문 저장이 실패할 수도 있습니다.\n- 모든 상태 변경에는 발생 시각, 처리자, 사유, 결제 거래 식별자, 환불 거래 식별자를 남깁니다.\n- 고객 화면, 관리자 화면, 고객센터 응대 문구가 같은 상태 정의를 사용해야 합니다.\n- 상태 전이는 일방향으로 설계하고, 예외 복구는 별도 관리자 권한으로 기록을 남겨 처리합니다.\n\n## 2. 청약철회와 법정 환불 기한: 정책이 아니라 법적 요구사항이다\n\n한국에서 소비자 대상 전자상거래를 운영한다면 전자상거래 등에서의 소비자보호에 관한 법률을 고려해야 합니다. 일반적으로 소비자는 일정 기간 안에 청약철회를 할 수 있고, 사업자는 환불 요청 또는 반환 절차 이후 정해진 기한 안에 대금을 환급해야 합니다.\n\n실무에서 특히 중요한 기준은 다음과 같습니다.\n\n- 소비자는 원칙적으로 재화 등을 공급받은 날 등 법이 정한 기준일부터 7일 이내에 청약철회를 할 수 있습니다.\n- 사업자는 환급 사유가 발생한 뒤 법정 기한 안에 대금을 환급해야 하며, 지연되는 경우 지연 배상금 또는 지연 이자 문제가 생길 수 있습니다.\n- 디지털 콘텐츠, 맞춤 제작 상품, 사용으로 가치가 현저히 감소하는 상품 등은 예외가 될 수 있지만, 예외를 적용하려면 사전 고지와 동의 등 요건을 신중히 확인해야 합니다.\n- 실제 적용은 상품 유형, 계약 방식, 소비자에게 제공한 고지, 사용 개시 여부에 따라 달라질 수 있으므로 법무 검토가 필요합니다.\n\n### 개발 요구사항으로 바꾸는 방법\n\n법적 기준은 약관 문구에만 적어두면 부족합니다. 시스템 요구사항으로도 바꿔야 합니다.\n\n| 법·정책 요구 | 시스템 요구사항 |\n|---|---|\n| 7일 내 청약철회 가능 여부 판단 | 주문 수령일 또는 서비스 제공일 기준으로 환불 가능 기간 자동 계산 |\n| 3영업일 내 환급 처리 필요 | 관리자 화면에 환불 신청일과 처리 마감일 표시 |\n| 환급 지연 위험 | 마감 임박, 마감 초과 알림 표시 |\n| 예외 상품 고지 필요 | 결제 전 환불 제한 상품임을 명확히 표시하고 동의 로그 저장 |\n| 분쟁 대응 필요 | 약관 버전, 고지 시각, 동의 시각, 고객 IP 또는 계정 로그 보관 |\n\n## 3. 부분 환불 규칙: 쿠폰, 배송비, 세금을 미리 정의한다\n\n부분 환불은 전체 취소보다 훨씬 복잡합니다. 여러 상품을 한 번에 주문한 뒤 일부만 반품하면, 원래 적용된 할인과 배송비를 어떻게 나눌지 결정해야 합니다.\n\n### 반드시 정해야 할 항목\n\n- 상품별 결제 금액을 어떻게 배분할 것인가\n- 주문 전체 쿠폰을 상품별로 비례 배분할 것인가\n- 특정 상품 쿠폰은 해당 상품에만 적용할 것인가\n- 무료배송 조건이 깨졌을 때 배송비를 차감할 것인가\n- 단순 변심 반품 배송비와 상품 하자 반품 배송비를 어떻게 구분할 것인가\n- 포인트, 적립금, 기프트카드 결제분을 어떤 순서로 환급할 것인가\n- 부분 환불 후 세금계산서, 현금영수증, 영수증 표기를 어떻게 바꿀 것인가\n\n### 부분 환불 계산 예시\n\n| 항목 | 금액 |\n|---|---:|\n| A 상품 | 30,000원 |\n| B 상품 | 70,000원 |\n| 주문 전체 쿠폰 | -10,000원 |\n| 실제 결제 금액 | 90,000원 |\n\n쿠폰을 상품 금액 비율로 배분하면 A 상품에는 3,000원, B 상품에는 7,000원의 할인이 배분됩니다. 이때 A 상품만 환불하면 환불 기준 금액은 30,000원이 아니라 27,000원입니다. 무료배송 조건, 반품 배송비, 결제수단별 환급 제한이 있다면 최종 환불액은 더 달라질 수 있습니다.\n\n정답은 하나가 아닙니다. 중요한 것은 일관된 규칙을 사전에 정하고, 고객이 결제 전 또는 환불 신청 전에 이해할 수 있게 고지하는 것입니다.\n\n## 4. 이중 결제 방지: 버튼 비활성화만으로는 부족하다\n\n이중 결제는 고객이 가장 빠르게 발견하는 결제 사고입니다. 고객은 서비스 내부 주문 상태보다 카드 승인 문자와 카드 명세서를 먼저 봅니다. 같은 주문이 두 번 결제되면 신뢰가 크게 떨어집니다.\n\n### 발생 원인\n\n- 고객이 결제 버튼을 연속 클릭함\n- 결제 직후 새로고침하거나 뒤로 가기를 누름\n- 모바일 네트워크 지연으로 같은 요청이 재전송됨\n- 결제 승인 응답은 성공했지만 서비스 서버 저장이 실패함\n- 웹훅과 클라이언트 리다이렉트가 동시에 주문 상태를 변경함\n\n### 방어 설계\n\n| 방어 장치 | 설명 |\n|---|---|\n| 클라이언트 버튼 잠금 | 결제 버튼 클릭 후 재클릭을 막지만 보조 수단으로만 사용 |\n| 서버 단 주문 잠금 | 같은 주문 ID에 대해 동시에 결제 승인 요청이 실행되지 않게 처리 |\n| 멱등성 키 | 같은 결제 요청을 여러 번 보내도 결과가 한 번만 생성되게 하는 식별자 사용 |\n| 고유 거래번호 | 주문 번호와 결제 거래번호의 중복 저장을 데이터베이스 제약조건으로 방지 |\n| 상태 기반 검증 | 이미 `paid`인 주문에는 추가 승인 요청을 막음 |\n| 웹훅 중복 처리 | 같은 웹훅 이벤트가 여러 번 와도 상태 변경이 한 번만 일어나게 처리 |\n\nAI에게 결제 코드를 요청할 때는 ‘중복 클릭 방지’가 아니라 ‘동일 주문에 대해 결제 승인과 결제 완료 처리는 멱등하게 동작해야 한다’고 명시하는 것이 좋습니다.\n\n## 5. 결제 실패 안내 문구: 실패는 사고가 아니라 정상 흐름이다\n\n결제 실패는 매일 발생하는 정상 상황입니다. 한도 초과, 잔액 부족, 카드 인증 실패, 비밀번호 오류, 3D Secure 인증 실패, 간편결제 앱 미응답, 네트워크 오류는 모두 흔한 케이스입니다.\n\n나쁜 안내는 ‘오류가 발생했습니다’로 끝나는 문구입니다. 고객은 결제가 된 것인지, 다시 눌러도 되는지, 주문이 사라지는지 알 수 없습니다.\n\n### 안내 문구 예시\n\n| 상황 | 권장 안내 |\n|---|---|\n| 잔액 부족 | 결제수단의 잔액이 부족해 결제가 완료되지 않았습니다. 다른 결제수단을 선택하거나 잔액을 확인한 뒤 다시 시도해 주세요. |\n| 한도 초과 | 카드 한도 또는 1회 결제 한도를 초과해 결제가 실패했습니다. 카드사 앱에서 한도를 확인하거나 다른 카드로 결제해 주세요. |\n| 인증 실패 | 결제 인증이 완료되지 않아 주문이 결제 대기 상태로 유지됩니다. 30분 안에 다시 결제할 수 있습니다. |\n| 네트워크 오류 | 결제 결과 확인이 지연되고 있습니다. 중복 결제를 막기 위해 잠시 후 결제 내역을 확인해 주세요. |\n| 주문 만료 | 결제 대기 시간이 지나 주문이 만료되었습니다. 상품을 다시 선택해 주문해 주세요. |\n\n### 실패 안내의 핵심 요소\n\n- 결제가 실제로 완료되지 않았는지 명확히 말합니다.\n- 주문이 유지되는 시간을 알려줍니다.\n- 다시 시도해도 되는지, 다른 결제수단을 써야 하는지 안내합니다.\n- 고객센터에 문의할 때 필요한 주문번호를 보여줍니다.\n- 결제 결과가 불확실한 경우 무조건 재결제를 유도하지 말고 확인 중 상태를 제공합니다.\n\n## 6. 결제 내역 페이지: 고객센터를 줄이는 핵심 화면이다\n\n결제 내역 페이지가 없으면 고객은 결제, 취소, 환불 상태를 확인하기 위해 고객센터에 문의합니다. 결제 내역은 단순한 영수증 화면이 아니라 고객이 자기 돈의 현재 상태를 확인하는 신뢰 장치입니다.\n\n### 결제 내역 페이지에 포함할 정보\n\n- 주문번호\n- 주문일시와 결제일시\n- 상품명, 수량, 옵션\n- 결제수단과 승인번호 또는 거래 식별자\n- 상품 금액, 할인, 배송비, 포인트 사용액, 최종 결제액\n- 현재 주문 상태와 환불 상태\n- 환불 신청일, 환불 승인일, 환불 완료 예정일\n- 취소 또는 환불 가능 여부\n- 영수증, 거래명세서, 현금영수증 확인 링크\n- 고객센터 문의 시 필요한 정보\n\n### 운영자 화면과의 연결\n\n고객 화면과 관리자 화면은 같은 데이터를 봐야 합니다. 고객에게는 ‘환불 진행 중’이라고 보이는데 관리자 화면에는 ‘처리 완료’로 보이면 고객센터 응대가 꼬입니다. 상태명은 다르게 표현할 수 있지만, 내부 상태 코드와 전이 규칙은 하나여야 합니다.\n\n## 7. 환불 규정 고지 위치: 숨기면 정책이 아니라 위험이 된다\n\n환불 규정은 약관 페이지 구석에만 두면 부족합니다. 고객이 결제 결정을 내리는 화면에서 환불 가능 기간, 환불 제한 조건, 취소 방법을 쉽게 확인할 수 있어야 합니다.\n\n### 좋은 고지 위치\n\n- 상품 상세 페이지의 가격 또는 구매 버튼 근처\n- 장바구니 또는 주문서 화면\n- 결제 버튼 바로 위의 약관 및 환불 규정 동의 영역\n- 결제 완료 페이지\n- 마이페이지의 주문 상세 화면\n- 환불 신청 화면\n\n### 피해야 할 설계\n\n- 가입과 결제는 한 번에 되지만 해지나 환불은 고객센터 전화로만 가능하게 만드는 설계\n- 취소 버튼을 여러 단계 안쪽에 숨기는 설계\n- 환불 제한 조건을 결제 후에야 보여주는 설계\n- 고객이 오해하도록 버튼 색상, 문구, 순서를 배치하는 설계\n- 무료 체험 종료 후 자동 결제 사실을 명확히 알리지 않는 설계\n\n이런 설계는 고객 경험을 해칠 뿐 아니라 다크패턴으로 평가될 수 있습니다. 특히 취소와 해지의 난이도는 가입과 결제의 난이도와 크게 다르지 않게 설계하는 것이 안전합니다.\n\n## AI에게 줄 프롬프트에 포함할 체크리스트\n\nAI 개발 도구에 결제 기능 구현을 요청할 때는 아래처럼 정책을 먼저 전달해야 합니다.\n\n### 결제 기능 프롬프트 예시\n\n```text\n한국 소비자 대상 전자상거래 서비스의 결제 기능을 구현해 줘.\n다음 정책을 반드시 반영해.\n\n1. 주문 상태는 payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, expired를 사용한다.\n2. 결제 대기 주문은 30분 후 expired로 변경한다.\n3. 동일 주문에는 결제 승인 1건만 허용하고, 서버 단 주문 잠금과 멱등성 키를 사용한다.\n4. 결제 웹훅은 중복 수신될 수 있으므로 같은 이벤트 ID는 한 번만 처리한다.\n5. 환불 신청일, 환불 처리 마감일, 처리자, 사유, 환불 거래번호를 저장한다.\n6. 부분 환불은 상품별 실결제금액 기준으로 계산하고, 주문 전체 쿠폰은 상품 금액 비율로 배분한다.\n7. 결제 실패 시 실패 사유별 고객 안내 문구를 반환한다.\n8. 고객이 마이페이지에서 결제 내역과 환불 상태를 확인할 수 있게 한다.\n9. 결제 전 환불 규정 링크와 동의 체크박스를 표시하고, 동의 시각과 약관 버전을 저장한다.\n10. 정하지 않은 정책이 있으면 코드를 작성하기 전에 먼저 질문해 줘.\n```\n\n마지막 문장인 ‘정하지 않은 정책이 있으면 먼저 질문해 줘’는 중요합니다. 환불 자동 승인 여부, 관리자 승인 권한, 배송비 차감 방식처럼 사람이 놓치기 쉬운 정책을 AI가 되묻게 만들 수 있습니다.\n\n## 운영자 화면에 필요한 기능\n\n결제 기능은 고객 화면만으로 완성되지 않습니다. 환불과 취소는 매일 처리되는 운영 업무이므로 관리자 화면이 반드시 필요합니다.\n\n| 관리자 기능 | 필요한 이유 |\n|---|---|\n| 환불 대기 목록 | 처리해야 할 환불 건을 놓치지 않기 위해 필요 |\n| 법정 처리 기한 표시 | 환불 지연 위험을 줄이기 위해 필요 |\n| 기한 임박·초과 경고 | 3영업일 같은 내부 기준을 운영자가 즉시 인지하도록 필요 |\n| 환불 사유 선택 | 단순 변심, 상품 하자, 오배송 등 통계와 비용 배분에 필요 |\n| 부분 환불 계산 미리보기 | 운영자의 수동 계산 오류를 줄이기 위해 필요 |\n| 처리 로그 | 분쟁과 감사 대응을 위해 필요 |\n| 권한 관리 | 환불 승인과 강제 상태 변경을 제한하기 위해 필요 |\n\n## 결제 데이터 모델의 최소 구성\n\n서비스마다 데이터 구조는 다르지만, 최소한 아래 수준의 데이터는 분리해 두는 것이 좋습니다.\n\n| 테이블 또는 객체 | 핵심 필드 |\n|---|---|\n| 주문 | 주문 ID, 고객 ID, 주문 상태, 주문 금액, 할인액, 배송비, 생성일시, 만료일시 |\n| 주문 상품 | 상품 ID, 상품명, 옵션, 수량, 상품별 금액, 상품별 할인 배분액 |\n| 결제 | 결제 ID, 주문 ID, 결제수단, 승인번호, 승인금액, 결제 상태, 승인일시 |\n| 환불 | 환불 ID, 주문 ID, 환불 금액, 환불 사유, 환불 상태, 신청일시, 완료일시 |\n| 상태 이력 | 대상 ID, 이전 상태, 변경 상태, 변경자, 변경 사유, 변경일시 |\n| 약관 동의 | 약관 종류, 약관 버전, 동의 여부, 동의일시, 고객 ID |\n\n중요한 점은 결제 승인 금액, 환불 금액, 주문 총액을 덮어쓰지 않는 것입니다. 돈과 관련된 값은 가능하면 이력과 거래 단위로 보존해야 나중에 장부와 고객 응대가 맞습니다.\n\n## 출시 전 점검 목록\n\n- 같은 주문에 대해 결제 버튼을 10번 눌러도 결제는 1번만 승인되는가?\n- 결제 승인 후 서버 저장이 실패하면 복구할 수 있는가?\n- 결제 웹훅이 같은 이벤트를 여러 번 보내도 중복 처리되지 않는가?\n- 고객이 결제 실패 사유와 재시도 방법을 이해할 수 있는가?\n- 결제 대기 주문이 일정 시간 후 자동 만료되는가?\n- 부분 환불 금액이 쿠폰, 포인트, 배송비 정책과 일치하는가?\n- 환불 신청일부터 처리 마감일까지 관리자 화면에 표시되는가?\n- 환불 규정이 결제 전 화면에서 쉽게 확인되는가?\n- 디지털 콘텐츠 또는 환불 제한 상품은 사전 고지와 동의 로그가 있는가?\n- 고객이 마이페이지에서 결제 내역과 환불 상태를 직접 확인할 수 있는가?\n\n## 결론\n\nAI는 결제 기능의 코드를 빠르게 만들 수 있습니다. 하지만 안전하고 합법적으로 운영되는 결제 시스템은 코드 이전의 정책 결정에서 시작됩니다.\n\n주문 상태, 법정 환불 기한, 부분 환불 계산식, 이중 결제 방지, 결제 실패 안내, 결제 내역 페이지, 환불 규정 고지 위치를 먼저 정리한 뒤 AI에게 구현을 맡기면 훨씬 안정적인 결과를 얻을 수 있습니다. 결제는 ‘돈을 받는 기능’이 아니라 ‘돈을 책임지는 기능’이라는 관점으로 설계해야 합니다.","content_html":"\u003ch2\u003e\n\u003ca href=\"#%ED%95%B5%EC%8B%AC-%EC%9A%94%EC%95%BD\" class=\"anchor\" id=\"핵심-요약\"\u003e\u003c/a\u003e핵심 요약\u003c/h2\u003e\n\u003cp\u003eAI에게 결제 기능을 맡길 때 가장 위험한 프롬프트는 단순히 ‘결제 붙여줘’라고 요청하는 것입니다. 결제는 돈을 받는 코드가 아니라 돈의 흐름을 책임지는 운영·회계·고객지원 시스템입니다.\u003c/p\u003e\n\u003cp\u003e기술적으로는 결제창 연동, 승인 API 호출, 웹훅 수신, 주문 저장을 AI가 빠르게 구현할 수 있습니다. 그러나 다음 정책이 정해져 있지 않으면 실제 서비스에서는 유령 주문, 이중 결제, 환불 지연, 고객센터 폭주, 법적 고지 누락 문제가 발생할 수 있습니다.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e결정 영역\u003c/th\u003e\n\u003cth\u003e미리 정해야 할 질문\u003c/th\u003e\n\u003cth\u003e실패 시 위험\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"결정 영역\"\u003e주문 상태\u003c/td\u003e\n\u003ctd data-label=\"미리 정해야 할 질문\"\u003e주문은 어떤 상태를 순서대로 거치는가?\u003c/td\u003e\n\u003ctd data-label=\"실패 시 위험\"\u003e결제는 됐지만 주문이 없는 유령 주문 발생\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"결정 영역\"\u003e환불 기한\u003c/td\u003e\n\u003ctd data-label=\"미리 정해야 할 질문\"\u003e청약철회와 환불 처리 기한을 어떻게 반영할 것인가?\u003c/td\u003e\n\u003ctd data-label=\"실패 시 위험\"\u003e법정 기한 위반, 지연 이자, 분쟁 위험\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"결정 영역\"\u003e부분 환불\u003c/td\u003e\n\u003ctd data-label=\"미리 정해야 할 질문\"\u003e일부 상품 반품, 쿠폰, 배송비를 어떻게 계산할 것인가?\u003c/td\u003e\n\u003ctd data-label=\"실패 시 위험\"\u003e운영자가 매번 수동 계산, 고객 불신\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"결정 영역\"\u003e이중 결제\u003c/td\u003e\n\u003ctd data-label=\"미리 정해야 할 질문\"\u003e같은 주문에 결제가 두 번 잡히지 않게 어떻게 막을 것인가?\u003c/td\u003e\n\u003ctd data-label=\"실패 시 위험\"\u003e카드 명세서 기준 고객 불만, 신뢰 하락\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"결정 영역\"\u003e실패 안내\u003c/td\u003e\n\u003ctd data-label=\"미리 정해야 할 질문\"\u003e한도 초과, 잔액 부족, 인증 실패를 어떻게 안내할 것인가?\u003c/td\u003e\n\u003ctd data-label=\"실패 시 위험\"\u003e재시도 전환율 하락, 불필요한 문의 증가\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"결정 영역\"\u003e결제 내역\u003c/td\u003e\n\u003ctd data-label=\"미리 정해야 할 질문\"\u003e고객이 결제와 환불 상태를 어디서 확인하는가?\u003c/td\u003e\n\u003ctd data-label=\"실패 시 위험\"\u003e고객센터 문의 증가, 상태 불투명\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"결정 영역\"\u003e환불 고지\u003c/td\u003e\n\u003ctd data-label=\"미리 정해야 할 질문\"\u003e환불 규정과 취소 버튼을 어디에 배치하는가?\u003c/td\u003e\n\u003ctd data-label=\"실패 시 위험\"\u003e다크패턴 논란, 규제 리스크\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#1-%EC%A3%BC%EB%AC%B8-%EC%83%81%ED%83%9C-%EC%84%A4%EA%B3%84-%EC%83%81%ED%83%9C%EA%B0%80-%EA%B3%A7-%EC%9A%B4%EC%98%81-%EC%96%B8%EC%96%B4%EB%8B%A4\" class=\"anchor\" id=\"1-주문-상태-설계-상태가-곧-운영-언어다\"\u003e\u003c/a\u003e1. 주문 상태 설계: 상태가 곧 운영 언어다\u003c/h2\u003e\n\u003cp\u003e결제 기능을 만들 때 주문 상태를 ‘주문 완료’ 하나로만 두면 안 됩니다. 실제 주문은 결제 시도, 승인, 취소, 환불, 실패, 만료 같은 여러 단계를 거칩니다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EA%B6%8C%EC%9E%A5-%EC%83%81%ED%83%9C-%EC%98%88%EC%8B%9C\" class=\"anchor\" id=\"권장-상태-예시\"\u003e\u003c/a\u003e권장 상태 예시\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e상태 코드 예시\u003c/th\u003e\n\u003cth\u003e고객에게 보이는 상태\u003c/th\u003e\n\u003cth\u003e의미\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상태 코드 예시\"\u003e\u003ccode\u003epayment_pending\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"고객에게 보이는 상태\"\u003e결제 대기\u003c/td\u003e\n\u003ctd data-label=\"의미\"\u003e주문은 생성됐지만 결제가 끝나지 않음\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상태 코드 예시\"\u003e\u003ccode\u003epaid\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"고객에게 보이는 상태\"\u003e결제 완료\u003c/td\u003e\n\u003ctd data-label=\"의미\"\u003e결제 승인이 완료되어 주문이 유효함\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상태 코드 예시\"\u003e\u003ccode\u003epayment_failed\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"고객에게 보이는 상태\"\u003e결제 실패\u003c/td\u003e\n\u003ctd data-label=\"의미\"\u003e결제 시도가 실패했고 재시도 가능 여부를 판단해야 함\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상태 코드 예시\"\u003e\u003ccode\u003ecancel_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"고객에게 보이는 상태\"\u003e취소 요청\u003c/td\u003e\n\u003ctd data-label=\"의미\"\u003e고객이 취소를 신청했고 처리 대기 중임\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상태 코드 예시\"\u003e\u003ccode\u003ecancelled\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"고객에게 보이는 상태\"\u003e취소 완료\u003c/td\u003e\n\u003ctd data-label=\"의미\"\u003e결제 전 주문 취소 또는 승인 취소가 완료됨\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상태 코드 예시\"\u003e\u003ccode\u003erefund_requested\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"고객에게 보이는 상태\"\u003e환불 요청\u003c/td\u003e\n\u003ctd data-label=\"의미\"\u003e결제 후 환불 신청이 접수됨\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상태 코드 예시\"\u003e\u003ccode\u003erefund_processing\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"고객에게 보이는 상태\"\u003e환불 진행 중\u003c/td\u003e\n\u003ctd data-label=\"의미\"\u003e환불 승인 또는 결제수단 환급 처리 중임\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상태 코드 예시\"\u003e\u003ccode\u003epartially_refunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"고객에게 보이는 상태\"\u003e부분 환불 완료\u003c/td\u003e\n\u003ctd data-label=\"의미\"\u003e주문 금액 중 일부만 환불됨\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상태 코드 예시\"\u003e\u003ccode\u003erefunded\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"고객에게 보이는 상태\"\u003e환불 완료\u003c/td\u003e\n\u003ctd data-label=\"의미\"\u003e환불 처리가 완료됨\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상태 코드 예시\"\u003e\u003ccode\u003eexpired\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"고객에게 보이는 상태\"\u003e주문 만료\u003c/td\u003e\n\u003ctd data-label=\"의미\"\u003e결제 대기 시간이 지나 주문이 무효화됨\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EC%83%81%ED%83%9C-%EC%84%A4%EA%B3%84-%EC%9B%90%EC%B9%99\" class=\"anchor\" id=\"상태-설계-원칙\"\u003e\u003c/a\u003e상태 설계 원칙\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e주문 상태와 결제 상태를 완전히 같은 것으로 보지 않습니다. 주문은 존재하지만 결제가 실패할 수 있고, 결제는 승인됐지만 주문 저장이 실패할 수도 있습니다.\u003c/li\u003e\n\u003cli\u003e모든 상태 변경에는 발생 시각, 처리자, 사유, 결제 거래 식별자, 환불 거래 식별자를 남깁니다.\u003c/li\u003e\n\u003cli\u003e고객 화면, 관리자 화면, 고객센터 응대 문구가 같은 상태 정의를 사용해야 합니다.\u003c/li\u003e\n\u003cli\u003e상태 전이는 일방향으로 설계하고, 예외 복구는 별도 관리자 권한으로 기록을 남겨 처리합니다.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#2-%EC%B2%AD%EC%95%BD%EC%B2%A0%ED%9A%8C%EC%99%80-%EB%B2%95%EC%A0%95-%ED%99%98%EB%B6%88-%EA%B8%B0%ED%95%9C-%EC%A0%95%EC%B1%85%EC%9D%B4-%EC%95%84%EB%8B%88%EB%9D%BC-%EB%B2%95%EC%A0%81-%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD%EC%9D%B4%EB%8B%A4\" class=\"anchor\" id=\"2-청약철회와-법정-환불-기한-정책이-아니라-법적-요구사항이다\"\u003e\u003c/a\u003e2. 청약철회와 법정 환불 기한: 정책이 아니라 법적 요구사항이다\u003c/h2\u003e\n\u003cp\u003e한국에서 소비자 대상 전자상거래를 운영한다면 전자상거래 등에서의 소비자보호에 관한 법률을 고려해야 합니다. 일반적으로 소비자는 일정 기간 안에 청약철회를 할 수 있고, 사업자는 환불 요청 또는 반환 절차 이후 정해진 기한 안에 대금을 환급해야 합니다.\u003c/p\u003e\n\u003cp\u003e실무에서 특히 중요한 기준은 다음과 같습니다.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e소비자는 원칙적으로 재화 등을 공급받은 날 등 법이 정한 기준일부터 7일 이내에 청약철회를 할 수 있습니다.\u003c/li\u003e\n\u003cli\u003e사업자는 환급 사유가 발생한 뒤 법정 기한 안에 대금을 환급해야 하며, 지연되는 경우 지연 배상금 또는 지연 이자 문제가 생길 수 있습니다.\u003c/li\u003e\n\u003cli\u003e디지털 콘텐츠, 맞춤 제작 상품, 사용으로 가치가 현저히 감소하는 상품 등은 예외가 될 수 있지만, 예외를 적용하려면 사전 고지와 동의 등 요건을 신중히 확인해야 합니다.\u003c/li\u003e\n\u003cli\u003e실제 적용은 상품 유형, 계약 방식, 소비자에게 제공한 고지, 사용 개시 여부에 따라 달라질 수 있으므로 법무 검토가 필요합니다.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EA%B0%9C%EB%B0%9C-%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD%EC%9C%BC%EB%A1%9C-%EB%B0%94%EA%BE%B8%EB%8A%94-%EB%B0%A9%EB%B2%95\" class=\"anchor\" id=\"개발-요구사항으로-바꾸는-방법\"\u003e\u003c/a\u003e개발 요구사항으로 바꾸는 방법\u003c/h3\u003e\n\u003cp\u003e법적 기준은 약관 문구에만 적어두면 부족합니다. 시스템 요구사항으로도 바꿔야 합니다.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e법·정책 요구\u003c/th\u003e\n\u003cth\u003e시스템 요구사항\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"법·정책 요구\"\u003e7일 내 청약철회 가능 여부 판단\u003c/td\u003e\n\u003ctd data-label=\"시스템 요구사항\"\u003e주문 수령일 또는 서비스 제공일 기준으로 환불 가능 기간 자동 계산\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"법·정책 요구\"\u003e3영업일 내 환급 처리 필요\u003c/td\u003e\n\u003ctd data-label=\"시스템 요구사항\"\u003e관리자 화면에 환불 신청일과 처리 마감일 표시\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"법·정책 요구\"\u003e환급 지연 위험\u003c/td\u003e\n\u003ctd data-label=\"시스템 요구사항\"\u003e마감 임박, 마감 초과 알림 표시\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"법·정책 요구\"\u003e예외 상품 고지 필요\u003c/td\u003e\n\u003ctd data-label=\"시스템 요구사항\"\u003e결제 전 환불 제한 상품임을 명확히 표시하고 동의 로그 저장\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"법·정책 요구\"\u003e분쟁 대응 필요\u003c/td\u003e\n\u003ctd data-label=\"시스템 요구사항\"\u003e약관 버전, 고지 시각, 동의 시각, 고객 IP 또는 계정 로그 보관\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#3-%EB%B6%80%EB%B6%84-%ED%99%98%EB%B6%88-%EA%B7%9C%EC%B9%99-%EC%BF%A0%ED%8F%B0-%EB%B0%B0%EC%86%A1%EB%B9%84-%EC%84%B8%EA%B8%88%EC%9D%84-%EB%AF%B8%EB%A6%AC-%EC%A0%95%EC%9D%98%ED%95%9C%EB%8B%A4\" class=\"anchor\" id=\"3-부분-환불-규칙-쿠폰-배송비-세금을-미리-정의한다\"\u003e\u003c/a\u003e3. 부분 환불 규칙: 쿠폰, 배송비, 세금을 미리 정의한다\u003c/h2\u003e\n\u003cp\u003e부분 환불은 전체 취소보다 훨씬 복잡합니다. 여러 상품을 한 번에 주문한 뒤 일부만 반품하면, 원래 적용된 할인과 배송비를 어떻게 나눌지 결정해야 합니다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EB%B0%98%EB%93%9C%EC%8B%9C-%EC%A0%95%ED%95%B4%EC%95%BC-%ED%95%A0-%ED%95%AD%EB%AA%A9\" class=\"anchor\" id=\"반드시-정해야-할-항목\"\u003e\u003c/a\u003e반드시 정해야 할 항목\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e상품별 결제 금액을 어떻게 배분할 것인가\u003c/li\u003e\n\u003cli\u003e주문 전체 쿠폰을 상품별로 비례 배분할 것인가\u003c/li\u003e\n\u003cli\u003e특정 상품 쿠폰은 해당 상품에만 적용할 것인가\u003c/li\u003e\n\u003cli\u003e무료배송 조건이 깨졌을 때 배송비를 차감할 것인가\u003c/li\u003e\n\u003cli\u003e단순 변심 반품 배송비와 상품 하자 반품 배송비를 어떻게 구분할 것인가\u003c/li\u003e\n\u003cli\u003e포인트, 적립금, 기프트카드 결제분을 어떤 순서로 환급할 것인가\u003c/li\u003e\n\u003cli\u003e부분 환불 후 세금계산서, 현금영수증, 영수증 표기를 어떻게 바꿀 것인가\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EB%B6%80%EB%B6%84-%ED%99%98%EB%B6%88-%EA%B3%84%EC%82%B0-%EC%98%88%EC%8B%9C\" class=\"anchor\" id=\"부분-환불-계산-예시\"\u003e\u003c/a\u003e부분 환불 계산 예시\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e항목\u003c/th\u003e\n\u003cth\u003e금액\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"항목\"\u003eA 상품\u003c/td\u003e\n\u003ctd data-label=\"금액\"\u003e30,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"항목\"\u003eB 상품\u003c/td\u003e\n\u003ctd data-label=\"금액\"\u003e70,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"항목\"\u003e주문 전체 쿠폰\u003c/td\u003e\n\u003ctd data-label=\"금액\"\u003e-10,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"항목\"\u003e실제 결제 금액\u003c/td\u003e\n\u003ctd data-label=\"금액\"\u003e90,000원\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e쿠폰을 상품 금액 비율로 배분하면 A 상품에는 3,000원, B 상품에는 7,000원의 할인이 배분됩니다. 이때 A 상품만 환불하면 환불 기준 금액은 30,000원이 아니라 27,000원입니다. 무료배송 조건, 반품 배송비, 결제수단별 환급 제한이 있다면 최종 환불액은 더 달라질 수 있습니다.\u003c/p\u003e\n\u003cp\u003e정답은 하나가 아닙니다. 중요한 것은 일관된 규칙을 사전에 정하고, 고객이 결제 전 또는 환불 신청 전에 이해할 수 있게 고지하는 것입니다.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#4-%EC%9D%B4%EC%A4%91-%EA%B2%B0%EC%A0%9C-%EB%B0%A9%EC%A7%80-%EB%B2%84%ED%8A%BC-%EB%B9%84%ED%99%9C%EC%84%B1%ED%99%94%EB%A7%8C%EC%9C%BC%EB%A1%9C%EB%8A%94-%EB%B6%80%EC%A1%B1%ED%95%98%EB%8B%A4\" class=\"anchor\" id=\"4-이중-결제-방지-버튼-비활성화만으로는-부족하다\"\u003e\u003c/a\u003e4. 이중 결제 방지: 버튼 비활성화만으로는 부족하다\u003c/h2\u003e\n\u003cp\u003e이중 결제는 고객이 가장 빠르게 발견하는 결제 사고입니다. 고객은 서비스 내부 주문 상태보다 카드 승인 문자와 카드 명세서를 먼저 봅니다. 같은 주문이 두 번 결제되면 신뢰가 크게 떨어집니다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EB%B0%9C%EC%83%9D-%EC%9B%90%EC%9D%B8\" class=\"anchor\" id=\"발생-원인\"\u003e\u003c/a\u003e발생 원인\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e고객이 결제 버튼을 연속 클릭함\u003c/li\u003e\n\u003cli\u003e결제 직후 새로고침하거나 뒤로 가기를 누름\u003c/li\u003e\n\u003cli\u003e모바일 네트워크 지연으로 같은 요청이 재전송됨\u003c/li\u003e\n\u003cli\u003e결제 승인 응답은 성공했지만 서비스 서버 저장이 실패함\u003c/li\u003e\n\u003cli\u003e웹훅과 클라이언트 리다이렉트가 동시에 주문 상태를 변경함\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EB%B0%A9%EC%96%B4-%EC%84%A4%EA%B3%84\" class=\"anchor\" id=\"방어-설계\"\u003e\u003c/a\u003e방어 설계\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e방어 장치\u003c/th\u003e\n\u003cth\u003e설명\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"방어 장치\"\u003e클라이언트 버튼 잠금\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e결제 버튼 클릭 후 재클릭을 막지만 보조 수단으로만 사용\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"방어 장치\"\u003e서버 단 주문 잠금\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e같은 주문 ID에 대해 동시에 결제 승인 요청이 실행되지 않게 처리\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"방어 장치\"\u003e멱등성 키\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e같은 결제 요청을 여러 번 보내도 결과가 한 번만 생성되게 하는 식별자 사용\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"방어 장치\"\u003e고유 거래번호\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e주문 번호와 결제 거래번호의 중복 저장을 데이터베이스 제약조건으로 방지\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"방어 장치\"\u003e상태 기반 검증\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e이미 \u003ccode\u003epaid\u003c/code\u003e인 주문에는 추가 승인 요청을 막음\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"방어 장치\"\u003e웹훅 중복 처리\u003c/td\u003e\n\u003ctd data-label=\"설명\"\u003e같은 웹훅 이벤트가 여러 번 와도 상태 변경이 한 번만 일어나게 처리\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eAI에게 결제 코드를 요청할 때는 ‘중복 클릭 방지’가 아니라 ‘동일 주문에 대해 결제 승인과 결제 완료 처리는 멱등하게 동작해야 한다’고 명시하는 것이 좋습니다.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#5-%EA%B2%B0%EC%A0%9C-%EC%8B%A4%ED%8C%A8-%EC%95%88%EB%82%B4-%EB%AC%B8%EA%B5%AC-%EC%8B%A4%ED%8C%A8%EB%8A%94-%EC%82%AC%EA%B3%A0%EA%B0%80-%EC%95%84%EB%8B%88%EB%9D%BC-%EC%A0%95%EC%83%81-%ED%9D%90%EB%A6%84%EC%9D%B4%EB%8B%A4\" class=\"anchor\" id=\"5-결제-실패-안내-문구-실패는-사고가-아니라-정상-흐름이다\"\u003e\u003c/a\u003e5. 결제 실패 안내 문구: 실패는 사고가 아니라 정상 흐름이다\u003c/h2\u003e\n\u003cp\u003e결제 실패는 매일 발생하는 정상 상황입니다. 한도 초과, 잔액 부족, 카드 인증 실패, 비밀번호 오류, 3D Secure 인증 실패, 간편결제 앱 미응답, 네트워크 오류는 모두 흔한 케이스입니다.\u003c/p\u003e\n\u003cp\u003e나쁜 안내는 ‘오류가 발생했습니다’로 끝나는 문구입니다. 고객은 결제가 된 것인지, 다시 눌러도 되는지, 주문이 사라지는지 알 수 없습니다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EC%95%88%EB%82%B4-%EB%AC%B8%EA%B5%AC-%EC%98%88%EC%8B%9C\" class=\"anchor\" id=\"안내-문구-예시\"\u003e\u003c/a\u003e안내 문구 예시\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e상황\u003c/th\u003e\n\u003cth\u003e권장 안내\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상황\"\u003e잔액 부족\u003c/td\u003e\n\u003ctd data-label=\"권장 안내\"\u003e결제수단의 잔액이 부족해 결제가 완료되지 않았습니다. 다른 결제수단을 선택하거나 잔액을 확인한 뒤 다시 시도해 주세요.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상황\"\u003e한도 초과\u003c/td\u003e\n\u003ctd data-label=\"권장 안내\"\u003e카드 한도 또는 1회 결제 한도를 초과해 결제가 실패했습니다. 카드사 앱에서 한도를 확인하거나 다른 카드로 결제해 주세요.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상황\"\u003e인증 실패\u003c/td\u003e\n\u003ctd data-label=\"권장 안내\"\u003e결제 인증이 완료되지 않아 주문이 결제 대기 상태로 유지됩니다. 30분 안에 다시 결제할 수 있습니다.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상황\"\u003e네트워크 오류\u003c/td\u003e\n\u003ctd data-label=\"권장 안내\"\u003e결제 결과 확인이 지연되고 있습니다. 중복 결제를 막기 위해 잠시 후 결제 내역을 확인해 주세요.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"상황\"\u003e주문 만료\u003c/td\u003e\n\u003ctd data-label=\"권장 안내\"\u003e결제 대기 시간이 지나 주문이 만료되었습니다. 상품을 다시 선택해 주문해 주세요.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EC%8B%A4%ED%8C%A8-%EC%95%88%EB%82%B4%EC%9D%98-%ED%95%B5%EC%8B%AC-%EC%9A%94%EC%86%8C\" class=\"anchor\" id=\"실패-안내의-핵심-요소\"\u003e\u003c/a\u003e실패 안내의 핵심 요소\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e결제가 실제로 완료되지 않았는지 명확히 말합니다.\u003c/li\u003e\n\u003cli\u003e주문이 유지되는 시간을 알려줍니다.\u003c/li\u003e\n\u003cli\u003e다시 시도해도 되는지, 다른 결제수단을 써야 하는지 안내합니다.\u003c/li\u003e\n\u003cli\u003e고객센터에 문의할 때 필요한 주문번호를 보여줍니다.\u003c/li\u003e\n\u003cli\u003e결제 결과가 불확실한 경우 무조건 재결제를 유도하지 말고 확인 중 상태를 제공합니다.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#6-%EA%B2%B0%EC%A0%9C-%EB%82%B4%EC%97%AD-%ED%8E%98%EC%9D%B4%EC%A7%80-%EA%B3%A0%EA%B0%9D%EC%84%BC%ED%84%B0%EB%A5%BC-%EC%A4%84%EC%9D%B4%EB%8A%94-%ED%95%B5%EC%8B%AC-%ED%99%94%EB%A9%B4%EC%9D%B4%EB%8B%A4\" class=\"anchor\" id=\"6-결제-내역-페이지-고객센터를-줄이는-핵심-화면이다\"\u003e\u003c/a\u003e6. 결제 내역 페이지: 고객센터를 줄이는 핵심 화면이다\u003c/h2\u003e\n\u003cp\u003e결제 내역 페이지가 없으면 고객은 결제, 취소, 환불 상태를 확인하기 위해 고객센터에 문의합니다. 결제 내역은 단순한 영수증 화면이 아니라 고객이 자기 돈의 현재 상태를 확인하는 신뢰 장치입니다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EA%B2%B0%EC%A0%9C-%EB%82%B4%EC%97%AD-%ED%8E%98%EC%9D%B4%EC%A7%80%EC%97%90-%ED%8F%AC%ED%95%A8%ED%95%A0-%EC%A0%95%EB%B3%B4\" class=\"anchor\" id=\"결제-내역-페이지에-포함할-정보\"\u003e\u003c/a\u003e결제 내역 페이지에 포함할 정보\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e주문번호\u003c/li\u003e\n\u003cli\u003e주문일시와 결제일시\u003c/li\u003e\n\u003cli\u003e상품명, 수량, 옵션\u003c/li\u003e\n\u003cli\u003e결제수단과 승인번호 또는 거래 식별자\u003c/li\u003e\n\u003cli\u003e상품 금액, 할인, 배송비, 포인트 사용액, 최종 결제액\u003c/li\u003e\n\u003cli\u003e현재 주문 상태와 환불 상태\u003c/li\u003e\n\u003cli\u003e환불 신청일, 환불 승인일, 환불 완료 예정일\u003c/li\u003e\n\u003cli\u003e취소 또는 환불 가능 여부\u003c/li\u003e\n\u003cli\u003e영수증, 거래명세서, 현금영수증 확인 링크\u003c/li\u003e\n\u003cli\u003e고객센터 문의 시 필요한 정보\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EC%9A%B4%EC%98%81%EC%9E%90-%ED%99%94%EB%A9%B4%EA%B3%BC%EC%9D%98-%EC%97%B0%EA%B2%B0\" class=\"anchor\" id=\"운영자-화면과의-연결\"\u003e\u003c/a\u003e운영자 화면과의 연결\u003c/h3\u003e\n\u003cp\u003e고객 화면과 관리자 화면은 같은 데이터를 봐야 합니다. 고객에게는 ‘환불 진행 중’이라고 보이는데 관리자 화면에는 ‘처리 완료’로 보이면 고객센터 응대가 꼬입니다. 상태명은 다르게 표현할 수 있지만, 내부 상태 코드와 전이 규칙은 하나여야 합니다.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#7-%ED%99%98%EB%B6%88-%EA%B7%9C%EC%A0%95-%EA%B3%A0%EC%A7%80-%EC%9C%84%EC%B9%98-%EC%88%A8%EA%B8%B0%EB%A9%B4-%EC%A0%95%EC%B1%85%EC%9D%B4-%EC%95%84%EB%8B%88%EB%9D%BC-%EC%9C%84%ED%97%98%EC%9D%B4-%EB%90%9C%EB%8B%A4\" class=\"anchor\" id=\"7-환불-규정-고지-위치-숨기면-정책이-아니라-위험이-된다\"\u003e\u003c/a\u003e7. 환불 규정 고지 위치: 숨기면 정책이 아니라 위험이 된다\u003c/h2\u003e\n\u003cp\u003e환불 규정은 약관 페이지 구석에만 두면 부족합니다. 고객이 결제 결정을 내리는 화면에서 환불 가능 기간, 환불 제한 조건, 취소 방법을 쉽게 확인할 수 있어야 합니다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EC%A2%8B%EC%9D%80-%EA%B3%A0%EC%A7%80-%EC%9C%84%EC%B9%98\" class=\"anchor\" id=\"좋은-고지-위치\"\u003e\u003c/a\u003e좋은 고지 위치\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e상품 상세 페이지의 가격 또는 구매 버튼 근처\u003c/li\u003e\n\u003cli\u003e장바구니 또는 주문서 화면\u003c/li\u003e\n\u003cli\u003e결제 버튼 바로 위의 약관 및 환불 규정 동의 영역\u003c/li\u003e\n\u003cli\u003e결제 완료 페이지\u003c/li\u003e\n\u003cli\u003e마이페이지의 주문 상세 화면\u003c/li\u003e\n\u003cli\u003e환불 신청 화면\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#%ED%94%BC%ED%95%B4%EC%95%BC-%ED%95%A0-%EC%84%A4%EA%B3%84\" class=\"anchor\" id=\"피해야-할-설계\"\u003e\u003c/a\u003e피해야 할 설계\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e가입과 결제는 한 번에 되지만 해지나 환불은 고객센터 전화로만 가능하게 만드는 설계\u003c/li\u003e\n\u003cli\u003e취소 버튼을 여러 단계 안쪽에 숨기는 설계\u003c/li\u003e\n\u003cli\u003e환불 제한 조건을 결제 후에야 보여주는 설계\u003c/li\u003e\n\u003cli\u003e고객이 오해하도록 버튼 색상, 문구, 순서를 배치하는 설계\u003c/li\u003e\n\u003cli\u003e무료 체험 종료 후 자동 결제 사실을 명확히 알리지 않는 설계\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e이런 설계는 고객 경험을 해칠 뿐 아니라 다크패턴으로 평가될 수 있습니다. 특히 취소와 해지의 난이도는 가입과 결제의 난이도와 크게 다르지 않게 설계하는 것이 안전합니다.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#ai%EC%97%90%EA%B2%8C-%EC%A4%84-%ED%94%84%EB%A1%AC%ED%94%84%ED%8A%B8%EC%97%90-%ED%8F%AC%ED%95%A8%ED%95%A0-%EC%B2%B4%ED%81%AC%EB%A6%AC%EC%8A%A4%ED%8A%B8\" class=\"anchor\" id=\"ai에게-줄-프롬프트에-포함할-체크리스트\"\u003e\u003c/a\u003eAI에게 줄 프롬프트에 포함할 체크리스트\u003c/h2\u003e\n\u003cp\u003eAI 개발 도구에 결제 기능 구현을 요청할 때는 아래처럼 정책을 먼저 전달해야 합니다.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%EA%B2%B0%EC%A0%9C-%EA%B8%B0%EB%8A%A5-%ED%94%84%EB%A1%AC%ED%94%84%ED%8A%B8-%EC%98%88%EC%8B%9C\" class=\"anchor\" id=\"결제-기능-프롬프트-예시\"\u003e\u003c/a\u003e결제 기능 프롬프트 예시\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e한국 소비자 대상 전자상거래 서비스의 결제 기능을 구현해 줘.\n\u003c/span\u003e\u003cspan\u003e다음 정책을 반드시 반영해.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. 주문 상태는 payment_pending, paid, payment_failed, cancel_requested, cancelled, refund_requested, refund_processing, partially_refunded, refunded, expired를 사용한다.\n\u003c/span\u003e\u003cspan\u003e2. 결제 대기 주문은 30분 후 expired로 변경한다.\n\u003c/span\u003e\u003cspan\u003e3. 동일 주문에는 결제 승인 1건만 허용하고, 서버 단 주문 잠금과 멱등성 키를 사용한다.\n\u003c/span\u003e\u003cspan\u003e4. 결제 웹훅은 중복 수신될 수 있으므로 같은 이벤트 ID는 한 번만 처리한다.\n\u003c/span\u003e\u003cspan\u003e5. 환불 신청일, 환불 처리 마감일, 처리자, 사유, 환불 거래번호를 저장한다.\n\u003c/span\u003e\u003cspan\u003e6. 부분 환불은 상품별 실결제금액 기준으로 계산하고, 주문 전체 쿠폰은 상품 금액 비율로 배분한다.\n\u003c/span\u003e\u003cspan\u003e7. 결제 실패 시 실패 사유별 고객 안내 문구를 반환한다.\n\u003c/span\u003e\u003cspan\u003e8. 고객이 마이페이지에서 결제 내역과 환불 상태를 확인할 수 있게 한다.\n\u003c/span\u003e\u003cspan\u003e9. 결제 전 환불 규정 링크와 동의 체크박스를 표시하고, 동의 시각과 약관 버전을 저장한다.\n\u003c/span\u003e\u003cspan\u003e10. 정하지 않은 정책이 있으면 코드를 작성하기 전에 먼저 질문해 줘.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e마지막 문장인 ‘정하지 않은 정책이 있으면 먼저 질문해 줘’는 중요합니다. 환불 자동 승인 여부, 관리자 승인 권한, 배송비 차감 방식처럼 사람이 놓치기 쉬운 정책을 AI가 되묻게 만들 수 있습니다.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EC%9A%B4%EC%98%81%EC%9E%90-%ED%99%94%EB%A9%B4%EC%97%90-%ED%95%84%EC%9A%94%ED%95%9C-%EA%B8%B0%EB%8A%A5\" class=\"anchor\" id=\"운영자-화면에-필요한-기능\"\u003e\u003c/a\u003e운영자 화면에 필요한 기능\u003c/h2\u003e\n\u003cp\u003e결제 기능은 고객 화면만으로 완성되지 않습니다. 환불과 취소는 매일 처리되는 운영 업무이므로 관리자 화면이 반드시 필요합니다.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e관리자 기능\u003c/th\u003e\n\u003cth\u003e필요한 이유\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"관리자 기능\"\u003e환불 대기 목록\u003c/td\u003e\n\u003ctd data-label=\"필요한 이유\"\u003e처리해야 할 환불 건을 놓치지 않기 위해 필요\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"관리자 기능\"\u003e법정 처리 기한 표시\u003c/td\u003e\n\u003ctd data-label=\"필요한 이유\"\u003e환불 지연 위험을 줄이기 위해 필요\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"관리자 기능\"\u003e기한 임박·초과 경고\u003c/td\u003e\n\u003ctd data-label=\"필요한 이유\"\u003e3영업일 같은 내부 기준을 운영자가 즉시 인지하도록 필요\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"관리자 기능\"\u003e환불 사유 선택\u003c/td\u003e\n\u003ctd data-label=\"필요한 이유\"\u003e단순 변심, 상품 하자, 오배송 등 통계와 비용 배분에 필요\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"관리자 기능\"\u003e부분 환불 계산 미리보기\u003c/td\u003e\n\u003ctd data-label=\"필요한 이유\"\u003e운영자의 수동 계산 오류를 줄이기 위해 필요\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"관리자 기능\"\u003e처리 로그\u003c/td\u003e\n\u003ctd data-label=\"필요한 이유\"\u003e분쟁과 감사 대응을 위해 필요\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"관리자 기능\"\u003e권한 관리\u003c/td\u003e\n\u003ctd data-label=\"필요한 이유\"\u003e환불 승인과 강제 상태 변경을 제한하기 위해 필요\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EA%B2%B0%EC%A0%9C-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EC%9D%98-%EC%B5%9C%EC%86%8C-%EA%B5%AC%EC%84%B1\" class=\"anchor\" id=\"결제-데이터-모델의-최소-구성\"\u003e\u003c/a\u003e결제 데이터 모델의 최소 구성\u003c/h2\u003e\n\u003cp\u003e서비스마다 데이터 구조는 다르지만, 최소한 아래 수준의 데이터는 분리해 두는 것이 좋습니다.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003e테이블 또는 객체\u003c/th\u003e\n\u003cth\u003e핵심 필드\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"테이블 또는 객체\"\u003e주문\u003c/td\u003e\n\u003ctd data-label=\"핵심 필드\"\u003e주문 ID, 고객 ID, 주문 상태, 주문 금액, 할인액, 배송비, 생성일시, 만료일시\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"테이블 또는 객체\"\u003e주문 상품\u003c/td\u003e\n\u003ctd data-label=\"핵심 필드\"\u003e상품 ID, 상품명, 옵션, 수량, 상품별 금액, 상품별 할인 배분액\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"테이블 또는 객체\"\u003e결제\u003c/td\u003e\n\u003ctd data-label=\"핵심 필드\"\u003e결제 ID, 주문 ID, 결제수단, 승인번호, 승인금액, 결제 상태, 승인일시\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"테이블 또는 객체\"\u003e환불\u003c/td\u003e\n\u003ctd data-label=\"핵심 필드\"\u003e환불 ID, 주문 ID, 환불 금액, 환불 사유, 환불 상태, 신청일시, 완료일시\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"테이블 또는 객체\"\u003e상태 이력\u003c/td\u003e\n\u003ctd data-label=\"핵심 필드\"\u003e대상 ID, 이전 상태, 변경 상태, 변경자, 변경 사유, 변경일시\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"테이블 또는 객체\"\u003e약관 동의\u003c/td\u003e\n\u003ctd data-label=\"핵심 필드\"\u003e약관 종류, 약관 버전, 동의 여부, 동의일시, 고객 ID\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e중요한 점은 결제 승인 금액, 환불 금액, 주문 총액을 덮어쓰지 않는 것입니다. 돈과 관련된 값은 가능하면 이력과 거래 단위로 보존해야 나중에 장부와 고객 응대가 맞습니다.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EC%B6%9C%EC%8B%9C-%EC%A0%84-%EC%A0%90%EA%B2%80-%EB%AA%A9%EB%A1%9D\" class=\"anchor\" id=\"출시-전-점검-목록\"\u003e\u003c/a\u003e출시 전 점검 목록\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e같은 주문에 대해 결제 버튼을 10번 눌러도 결제는 1번만 승인되는가?\u003c/li\u003e\n\u003cli\u003e결제 승인 후 서버 저장이 실패하면 복구할 수 있는가?\u003c/li\u003e\n\u003cli\u003e결제 웹훅이 같은 이벤트를 여러 번 보내도 중복 처리되지 않는가?\u003c/li\u003e\n\u003cli\u003e고객이 결제 실패 사유와 재시도 방법을 이해할 수 있는가?\u003c/li\u003e\n\u003cli\u003e결제 대기 주문이 일정 시간 후 자동 만료되는가?\u003c/li\u003e\n\u003cli\u003e부분 환불 금액이 쿠폰, 포인트, 배송비 정책과 일치하는가?\u003c/li\u003e\n\u003cli\u003e환불 신청일부터 처리 마감일까지 관리자 화면에 표시되는가?\u003c/li\u003e\n\u003cli\u003e환불 규정이 결제 전 화면에서 쉽게 확인되는가?\u003c/li\u003e\n\u003cli\u003e디지털 콘텐츠 또는 환불 제한 상품은 사전 고지와 동의 로그가 있는가?\u003c/li\u003e\n\u003cli\u003e고객이 마이페이지에서 결제 내역과 환불 상태를 직접 확인할 수 있는가?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#%EA%B2%B0%EB%A1%A0\" class=\"anchor\" id=\"결론\"\u003e\u003c/a\u003e결론\u003c/h2\u003e\n\u003cp\u003eAI는 결제 기능의 코드를 빠르게 만들 수 있습니다. 하지만 안전하고 합법적으로 운영되는 결제 시스템은 코드 이전의 정책 결정에서 시작됩니다.\u003c/p\u003e\n\u003cp\u003e주문 상태, 법정 환불 기한, 부분 환불 계산식, 이중 결제 방지, 결제 실패 안내, 결제 내역 페이지, 환불 규정 고지 위치를 먼저 정리한 뒤 AI에게 구현을 맡기면 훨씬 안정적인 결과를 얻을 수 있습니다. 결제는 ‘돈을 받는 기능’이 아니라 ‘돈을 책임지는 기능’이라는 관점으로 설계해야 합니다.\u003c/p\u003e\n","tags":["AI 개발","결제 시스템","환불 정책","전자상거래법","다크패턴"],"faqs":[{"question":"AI에게 결제 기능을 만들라고 할 때 가장 먼저 정해야 하는 것은 무엇인가요?","answer":"가장 먼저 주문 상태와 결제 상태의 흐름을 정해야 합니다. 결제 대기, 결제 완료, 결제 실패, 취소 요청, 환불 진행 중, 환불 완료 같은 상태가 정의되어야 AI가 안전한 데이터 구조와 화면 흐름을 만들 수 있습니다."},{"question":"주문 상태를 단순히 주문 완료 하나로 두면 왜 위험한가요?","answer":"실제 결제는 실패, 취소, 환불, 만료 같은 예외 흐름이 많기 때문입니다. 상태가 단순하면 결제는 됐지만 주문 내역이 없거나, 환불은 끝났지만 고객 화면에는 결제 완료로 남는 문제가 생길 수 있습니다."},{"question":"한국 전자상거래에서 청약철회 7일 규정은 항상 적용되나요?","answer":"일반적으로 소비자는 법이 정한 기준일부터 7일 이내에 청약철회를 할 수 있습니다. 다만 디지털 콘텐츠, 맞춤 제작 상품, 사용으로 가치가 감소하는 상품 등은 예외가 될 수 있으므로 사전 고지와 동의 요건을 포함해 개별 검토가 필요합니다."},{"question":"환불은 언제까지 처리해야 하나요?","answer":"한국 전자상거래에서는 사업자가 환급 사유가 발생한 뒤 법정 기한 안에 대금을 환급해야 하며, 실무에서는 3영업일 기준을 관리자 화면과 알림에 반영하는 것이 안전합니다. 지연될 경우 지연 배상금 문제가 생길 수 있으므로 자동 경고 기능을 두는 것이 좋습니다."},{"question":"부분 환불에서 가장 자주 문제가 되는 항목은 무엇인가요?","answer":"주문 전체 쿠폰, 무료배송 조건, 반품 배송비, 포인트 사용액, 상품별 할인 배분이 자주 문제가 됩니다. 환불 요청이 들어온 뒤 운영자가 매번 판단하지 않도록 상품별 실결제금액 기준이나 비례 배분 방식 같은 규칙을 미리 정해야 합니다."},{"question":"이중 결제는 프론트엔드에서 버튼만 비활성화하면 막을 수 있나요?","answer":"버튼 비활성화는 도움이 되지만 충분하지 않습니다. 네트워크 재시도, 새로고침, 웹훅 중복 수신이 발생할 수 있으므로 서버 단 주문 잠금, 멱등성 키, 고유 거래번호 제약조건, 상태 기반 검증이 함께 필요합니다."},{"question":"결제 실패 안내 문구에는 무엇이 들어가야 하나요?","answer":"결제가 완료되지 않았는지, 실패 사유가 무엇인지, 다시 시도해도 되는지, 주문이 얼마나 유지되는지, 문의 시 필요한 주문번호가 무엇인지가 들어가야 합니다. 단순히 오류가 발생했다는 문구만 보여주면 고객 이탈과 문의가 늘어납니다."},{"question":"결제 내역 페이지는 왜 필수인가요?","answer":"고객이 언제 얼마를 결제했고 환불이 어디까지 진행됐는지 직접 확인할 수 있어야 하기 때문입니다. 결제 내역 페이지가 없으면 모든 확인 요청이 고객센터로 몰리고, 고객은 서비스가 돈의 흐름을 제대로 관리하지 못한다고 느낄 수 있습니다."},{"question":"환불 규정은 약관 페이지에만 있으면 충분한가요?","answer":"충분하지 않습니다. 고객이 구매를 결정하는 상품 상세, 주문서, 결제 버튼 근처에서 환불 가능 기간과 제한 조건을 쉽게 확인할 수 있어야 합니다. 환불 규정을 숨기거나 취소 버튼을 찾기 어렵게 만들면 다크패턴 논란이 생길 수 있습니다."},{"question":"AI 프롬프트에 꼭 넣어야 할 문장은 무엇인가요?","answer":"정하지 않은 정책이 있으면 코드를 작성하기 전에 먼저 질문해 달라는 문장을 넣는 것이 좋습니다. 이 문장은 AI가 환불 승인 방식, 배송비 차감 기준, 상태 전이 예외처럼 빠뜨리기 쉬운 정책을 되묻게 만드는 안전장치입니다."},{"question":"관리자 화면에는 어떤 환불 기능이 필요하나요?","answer":"환불 대기 목록, 신청일, 처리 마감일, 기한 임박 알림, 부분 환불 계산 미리보기, 환불 사유, 처리자 로그, 권한 관리가 필요합니다. 환불은 반복 운영 업무이므로 관리자 화면이 부실하면 법정 기한과 고객 응대 품질을 지키기 어렵습니다."},{"question":"디지털 콘텐츠 결제도 환불 규정을 똑같이 적용하면 되나요?","answer":"디지털 콘텐츠는 제공 개시 여부와 사전 고지, 고객 동의에 따라 청약철회 제한이 문제될 수 있습니다. 따라서 결제 전 화면에서 환불 제한 조건을 명확히 알리고, 동의 시각과 약관 버전을 기록하는 방식으로 구현해야 합니다."}],"sources":[{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률","title":"국가법령정보센터: 전자상거래 등에서의 소비자보호에 관한 법률","type":"source"},{"url":"https://www.law.go.kr/법령/전자상거래등에서의소비자보호에관한법률시행령","title":"국가법령정보센터: 전자상거래 등에서의 소비자보호에 관한 법률 시행령","type":"source"},{"url":"https://stripe.com/docs/idempotency","title":"Stripe Docs: Idempotent requests","type":"source"},{"url":"https://docs.tosspayments.com/guides/v2/get-started/payment-flow","title":"Toss Payments Docs: 결제 연동 흐름","type":"source"},{"url":"https://www.ftc.go.kr/","title":"공정거래위원회","type":"source"}],"images":[{"id":252,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjQ5NCwicHVyIjoiYmxvYl9pZCJ9fQ==--29af039afe5bc5fc5481b1fee11ed2dbd406a900/ai-bac80653.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"결제·배송·보안 아이콘과 연결된 중앙의 AI 두뇌 일러스트","caption":"AI 두뇌가 쇼핑, 카드 결제, 배송, 보안 등 결제 흐름의 요소와 연결되어 있다.","description":null},"en":{"alt":"Central AI brain connected to payment, shopping, delivery, security, and support icons","caption":"The illustration links an AI brain to key parts of an online payment flow.","description":null},"ja":{"alt":"決済、買い物、配送、セキュリティのアイコンにつながる中央のAI脳","caption":"AIの脳がオンライン決済フローの主要な要素につながっている。","description":null},"es":{"alt":"Cerebro de IA central conectado a iconos de pago, compras, entrega, seguridad y soporte","caption":"La ilustración conecta un cerebro de IA con partes clave del flujo de pago en línea.","description":null},"id":{"alt":"Otak AI di tengah terhubung ke ikon pembayaran, belanja, pengiriman, keamanan, dan dukungan","caption":"Ilustrasi ini menghubungkan otak AI dengan bagian penting dalam alur pembayaran online.","description":null},"pt":{"alt":"Cérebro de IA central conectado a ícones de pagamento, compras, entrega, segurança e suporte","caption":"A ilustração liga um cérebro de IA a etapas importantes do fluxo de pagamento online.","description":null},"zh-hant":{"alt":"中央 AI 大腦連接付款、購物、配送、安全與客服圖示","caption":"插圖呈現 AI 大腦與線上付款流程中的關鍵元素相連。","description":null}}},{"id":253,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjUwMCwicHVyIjoiYmxvYl9pZCJ9fQ==--a75febd0315285ecae10a5682f4409174d119e4c/ai-363d820f.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"결제 화면을 중심으로 보안, 분석, 구독, 배송, 오류 흐름이 연결된 일러스트","caption":"AI로 결제 기능을 설계할 때 고려할 핵심 요소들을 한눈에 보여준다.","description":null},"en":{"alt":"Checkout screen connected to panels for security, analytics, subscriptions, delivery, and errors","caption":"The illustration summarizes key areas to decide before building AI-powered payments.","description":null},"ja":{"alt":"決済画面を中心に、セキュリティ、分析、定期課金、配送、エラーがつながるイラスト","caption":"AIで決済機能を作る前に決めるべき要素を整理して示している。","description":null},"es":{"alt":"Pantalla de pago conectada con paneles de seguridad, análisis, suscripción, envío y errores","caption":"La ilustración resume aspectos clave antes de crear pagos con IA.","description":null},"id":{"alt":"Layar checkout terhubung ke panel keamanan, analitik, langganan, pengiriman, dan kesalahan","caption":"Ilustrasi ini merangkum hal penting sebelum membangun pembayaran dengan AI.","description":null},"pt":{"alt":"Tela de checkout conectada a painéis de segurança, análise, assinatura, entrega e erros","caption":"A ilustração resume decisões importantes antes de criar pagamentos com IA.","description":null},"zh-hant":{"alt":"結帳畫面連接安全、分析、訂閱、配送與錯誤流程面板的插圖","caption":"這張插圖概述用 AI 建立付款功能前需先決定的重點。","description":null}}},{"id":254,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MjUwNiwicHVyIjoiYmxvYl9pZCJ9fQ==--11d07f3c504aae589920f87ce4aeedee4c3f7135/ai-bb53774f.webp","is_representative":false,"generation_method":"ai_infographic","license":"ai_generated","mime_type":"image/webp","visible_locales":["ko"],"translations":{"ko":{"alt":"AI 결제 기능의 7가지 결정 사항을 단계별로 정리한 한국어 인포그래픽","caption":"주문 상태, 환불, 중복 결제 방지 등 결제 기능 설계 항목을 보여줍니다.","description":null},"en":{"alt":"Korean infographic outlining seven decisions for building an AI payment feature","caption":"The graphic summarizes key payment feature choices such as status, refunds, and duplicate prevention.","description":null},"ja":{"alt":"AI決済機能の7つの決定事項を段階別に示す韓国語インフォグラフィック","caption":"注文状態、返金、二重決済防止などの設計項目を整理しています。","description":null},"es":{"alt":"Infografía en coreano con siete decisiones para crear una función de pago con IA","caption":"El gráfico resume decisiones sobre estados, reembolsos y prevención de pagos duplicados.","description":null},"id":{"alt":"Infografik berbahasa Korea tentang tujuh keputusan untuk fitur pembayaran AI","caption":"Grafik ini merangkum status pesanan, pengembalian dana, dan pencegahan pembayaran ganda.","description":null},"pt":{"alt":"Infográfico em coreano com sete decisões para criar um recurso de pagamento com IA","caption":"O gráfico resume estados de pedido, reembolsos e prevenção de pagamentos duplicados.","description":null},"zh-hant":{"alt":"韓文資訊圖表整理 AI 付款功能的七項決策","caption":"圖表概述訂單狀態、退款與防止重複付款等設計重點。","description":null}}}],"published_at":"2026-07-22T08:42:09+09:00","updated_at":"2026-07-22T08:42:09+09:00","license":"cc_by","translation_status":"original","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/ko/articles/ai-payment-feature-7-core-decisions"}