1
00:00:00,050 --> 00:00:06,771
결제 화면에 실패라고 나와 다시 눌렀는데 계좌에서 돈이 중복으로 나간 것 같습니다.

2
00:00:06,771 --> 00:00:13,555
판매자는 주문을 받지 못했다고 하고, 결제 서비스에는 처리 중이라고 표시됩니다.

3
00:00:13,555 --> 00:00:20,521
오늘은 이런 상황에서 거래 기록을 모아 확인하고 오류 정정을 요청하는 순서를 배웁니다.

4
00:00:20,521 --> 00:00:28,385
실패 표시만으로 결제가 없었다고 단정하거나 알림 개수만큼 돈이 빠졌다고 계산하지 않습니다.

5
00:00:28,385 --> 00:00:31,484
주문과 승인 기록을 확인합니다.

6
00:00:31,484 --> 00:00:36,641
청구 내역부터 실제 출금과 반환까지 연결해 보겠습니다.

7
00:00:36,641 --> 00:00:43,581
목표는 처리 결과를 직접 확인할 수 있는 거래 대조표와 요청 문장을 만드는 것입니다.

8
00:00:43,706 --> 00:00:47,940
같은 잘못된 이체라도 원인이 다를 수 있습니다.

9
00:00:47,940 --> 00:00:56,716
내가 수취인 계좌를 잘못 입력한 거래, 본인이 지시하지 않은 거래, 정상 지시가 다르게 처리된 거래를 구분합니다.

10
00:00:56,716 --> 00:01:05,700
공개 전자금융 약관에서 오류는 이용자의 고의나 과실 없이 계약이나 거래지시대로 이행되지 않은 경우를 뜻합니다.

11
00:01:05,700 --> 00:01:11,937
내 입력 실수까지 모두 같은 오류 정정 절차로 해결된다고 보면 안 됩니다.

12
00:01:11,937 --> 00:01:16,495
착오송금과 도용 의심은 별도 대응이 필요합니다.

13
00:01:16,495 --> 00:01:23,786
오늘은 정상적으로 지시한 거래의 실패 표시, 중복 처리, 기록 불일치가 중심입니다.

14
00:01:23,786 --> 00:01:29,515
원인을 아직 모른다면 미확인이라고 적고 거래 사실부터 확인하세요.

15
00:01:29,642 --> 00:01:37,444
처리 결과가 보이지 않을 때 같은 버튼을 여러 차례 누르면 원래 거래와 추가 거래가 섞일 수 있습니다.

16
00:01:37,444 --> 00:01:45,295
먼저 오류 문구와 발생 시각을 보관하고, 앱이나 금융회사 공식 경로에서 거래 내역을 확인하세요.

17
00:01:45,295 --> 00:01:50,985
재시도 여부는 서비스의 안내와 확인된 상태를 토대로 판단합니다.

18
00:01:50,985 --> 00:01:59,149
급한 결제라면 판매자에게 기존 주문과 결제 상태를 확인하고 대체 결제가 필요한지도 협의합니다.

19
00:01:59,149 --> 00:02:05,803
결과를 모르는 채 반복하여 내역을 더 복잡하게 만들지 않으려는 것입니다.

20
00:02:05,803 --> 00:02:12,144
추가로 결제했다면 그 거래의 시각과 수단도 빠뜨리지 않고 기록해야 합니다.

21
00:02:12,266 --> 00:02:17,333
쇼핑몰의 주문 화면은 상품 주문의 접수 상태를 보여 줍니다.

22
00:02:17,333 --> 00:02:27,099
결제 서비스 화면은 결제 요청과 처리 상태를, 카드사나 은행 내역은 승인이나 청구, 출금 상태를 보여 줄 수 있습니다.

23
00:02:27,099 --> 00:02:34,221
화면마다 사용하는 말과 반영 시점이 다를 수 있으므로 완료라는 단어만 비교해서는 부족합니다.

24
00:02:34,221 --> 00:02:37,828
무엇이 완료되었다는 것인지 확인하세요.

25
00:02:37,828 --> 00:02:43,036
오늘 대조표에는 화면의 이름과 조회한 시각을 함께 적습니다.

26
00:02:43,036 --> 00:02:50,823
주문이 없는데 출금이 보이는 경우와 주문은 정상인데 알림만 중복된 경우는 필요한 확인이 다릅니다.

27
00:02:50,930 --> 00:02:57,078
같은 금액의 결제가 여러 개라면 금액만으로 어느 거래인지 찾기 어렵습니다.

28
00:02:57,078 --> 00:03:02,976
주문번호, 승인번호나 거래번호, 결제일시를 함께 적으세요.

29
00:03:02,976 --> 00:03:10,489
서비스마다 번호 체계가 다르므로 번호가 다르다는 이유만으로 별개 거래라고 단정하지 않습니다.

30
00:03:10,489 --> 00:03:16,492
주문번호와 결제번호가 어떻게 연결되는지 담당 창구에 확인합니다.

31
00:03:16,492 --> 00:03:22,482
반대로 같은 가게와 같은 금액이라고 모두 중복 결제인 것도 아닙니다.

32
00:03:22,482 --> 00:03:29,044
실제 주문이 여러 개였는지, 추가 구매나 분할 처리가 있었는지도 확인해야 합니다.

33
00:03:29,044 --> 00:03:37,104
자료를 보낼 때에는 필요한 거래 식별정보만 제공하고 비밀번호나 인증번호를 기록표에 적지 않습니다.

34
00:03:37,226 --> 00:03:43,530
카드 승인 알림은 계좌에서 같은 시각에 현금이 출금되었다는 뜻과 다릅니다.

35
00:03:43,530 --> 00:03:48,582
계좌이체와 선불잔액 차감도 각각 기록을 확인해야 합니다.

36
00:03:48,582 --> 00:03:56,798
간편결제 앱 안에서 카드를 썼는지, 충전잔액을 썼는지, 계좌에서 직접 빠졌는지를 구분하세요.

37
00:03:56,798 --> 00:04:06,707
충전을 위해 계좌에서 돈이 나간 내역과 그 충전잔액으로 상품을 산 내역을 합치면 같은 돈을 지출로 중복 계산할 수 있습니다.

38
00:04:06,707 --> 00:04:12,137
오늘은 결제수단과 상태를 먼저 표시한 뒤 금액을 합산합니다.

39
00:04:12,137 --> 00:04:16,903
연결 계좌의 출금과 앱 잔액의 변화를 함께 보세요.

40
00:04:17,018 --> 00:04:21,955
가상으로 45,000원 결제 알림이 2개 왔다고 해 보겠습니다.

41
00:04:21,955 --> 00:04:27,775
이 사실만으로 실제로 90,000원이 지급되었다고 확정할 수는 없습니다.

42
00:04:27,775 --> 00:04:34,950
같은 거래의 알림이 반복되었을 수도 있고, 실제 거래가 별도로 처리되었을 수도 있습니다.

43
00:04:34,950 --> 00:04:40,692
거래번호와 승인 상태, 계좌의 실제 출금 내역을 대조해야 합니다.

44
00:04:40,692 --> 00:04:45,015
카드라면 취소 여부와 청구 내역까지 확인하세요.

45
00:04:45,015 --> 00:04:52,463
대조표에서는 알림 2개라는 사실을 적되, 실제 출금 칸에는 확인된 금액만 넣습니다.

46
00:04:52,463 --> 00:05:01,239
숫자가 같아 보여도 증거의 종류가 다르다는 점을 기억하면 중복 지급을 놓치거나 잘못 주장하는 일을 줄일 수 있습니다.

47
00:05:01,346 --> 00:05:10,658
오류 화면을 보관할 때에는 잘린 문구만 남기기보다 거래를 식별할 수 있는 날짜와 금액, 서비스 이름이 보이도록 합니다.

48
00:05:10,658 --> 00:05:18,444
개인정보가 과도하게 노출되지 않는 범위에서 원본을 안전하게 보관하고 제출용 사본을 만드세요.

49
00:05:18,444 --> 00:05:24,408
나중에 화면이 정상으로 바뀌면 당시 오류를 설명하기 어려울 수 있습니다.

50
00:05:24,408 --> 00:05:30,072
실제로 발생한 내역과 공식 공지, 접수 기록을 모으면 됩니다.

51
00:05:30,072 --> 00:05:39,773
파일 이름에 발생일과 서비스, 자료 종류를 적어 두면 여러 회사에 문의할 때 같은 자료를 정확히 찾아 제출할 수 있습니다.

52
00:05:39,890 --> 00:05:50,751
이번에는 가상 계좌에서 45,000원이 실제로 출금되고, 같은 주문과 관련하여 다시 45,000원이 출금된 사실을 확인했다고 가정합니다.

53
00:05:50,751 --> 00:05:54,215
확인된 출금 합계는 90,000원입니다.

54
00:05:54,215 --> 00:06:00,491
이 단계에서도 각각의 거래번호와 수령인, 관련 주문을 연결해야 합니다.

55
00:06:00,491 --> 00:06:06,259
숫자만 같은 다른 거래를 포함하면 합계가 맞아도 주장이 틀립니다.

56
00:06:06,259 --> 00:06:11,806
중복 처리로 의심되는 이유와 내가 지시한 거래 횟수도 기록하세요.

57
00:06:11,806 --> 00:06:16,077
이 예시는 카드 승인만 있는 상황과 구별됩니다.

58
00:06:16,077 --> 00:06:25,478
실제 출금이 확인된 가상 계좌의 산식이며, 모든 알림이나 청구 화면을 그대로 현금 출금으로 바꾸어 계산하지 않습니다.

59
00:06:25,586 --> 00:06:32,489
앞의 가상 거래에서 취소와 관련된 입금 45,000원이 계좌에 실제로 들어왔습니다.

60
00:06:32,489 --> 00:06:39,599
출금 합계 90,000원에서 확인된 반환 45,000원을 빼면 순출금은 45,000원입니다.

61
00:06:39,599 --> 00:06:46,200
정상 주문대금이 45,000원이라는 가정과 비교하면 금액상 차이는 없어집니다.

62
00:06:46,200 --> 00:06:53,062
그래도 주문이 정상 처리되었는지, 다른 거래가 취소된 것은 아닌지 확인해야 합니다.

63
00:06:53,062 --> 00:07:00,328
입금액이 같다는 사실만으로 연결을 끝내지 말고 취소된 거래번호와 원래 거래를 대조하세요.

64
00:07:00,328 --> 00:07:06,929
실습표의 기존 출금 기록을 그대로 두고, 돌려받은 금액을 별도로 추가합니다.

65
00:07:06,929 --> 00:07:12,854
그래야 어떤 과정으로 차이가 해소되었는지 나중에도 설명할 수 있습니다.

66
00:07:12,962 --> 00:07:19,605
취소하겠다는 문자만 왔고 아직 반환 내역은 확인되지 않았다고 가정해 보겠습니다.

67
00:07:19,605 --> 00:07:24,774
이때 앞의 계산표에 45,000원이 돌아왔다고 넣으면 안 됩니다.

68
00:07:24,774 --> 00:07:30,659
확인된 출금은 90,000원이고 확인된 반환은 아직 0원으로 표시합니다.

69
00:07:30,659 --> 00:07:35,060
취소 예정 금액은 별도의 메모 칸에 적습니다.

70
00:07:35,060 --> 00:07:45,764
카드 결제라면 취소가 계좌 입금 대신 청구액에서 차감되는 등 처리 형태가 다를 수 있으므로 자신의 결제 단계에 맞는 내역을 확인해야 합니다.

71
00:07:45,764 --> 00:07:53,537
이 예시의 0원은 환급받을 권리가 없다는 뜻이 아니라 아직 실제 반영을 확인하지 못했다는 뜻입니다.

72
00:07:53,537 --> 00:07:57,235
예정과 완료의 표시를 분명히 나누세요.

73
00:07:57,338 --> 00:08:03,460
판매자에게는 주문이 접수되었는지, 어떤 주문을 취소했는지 확인합니다.

74
00:08:03,460 --> 00:08:10,322
결제 서비스에는 거래지시와 처리 상태, 원거래와 취소거래의 연결을 묻습니다.

75
00:08:10,322 --> 00:08:16,038
카드사나 은행에는 실제 승인·청구·출금·반환 상태를 확인합니다.

76
00:08:16,038 --> 00:08:23,369
관련 회사가 여러 곳이라고 같은 질문을 반복하기보다 각자가 확인할 수 있는 자료를 요청하세요.

77
00:08:23,369 --> 00:08:30,869
다른 회사에 문의하라는 답을 받으면 어느 항목을 어느 담당 창구에서 확인해야 하는지도 적습니다.

78
00:08:30,869 --> 00:08:36,168
책임을 미리 특정하지 않고 거래의 연결을 밝히는 과정입니다.

79
00:08:36,290 --> 00:08:44,925
전자금융거래 이용약관에는 오류가 있음을 알게 된 이용자가 회사에 정정을 요구할 수 있는 절차가 마련되어 있습니다.

80
00:08:44,925 --> 00:08:51,539
직접 확인한 공개 약관도 이러한 요청과 조사, 결과 통지를 규정합니다.

81
00:08:51,539 --> 00:08:58,935
단순히 돈이 이상하다고 말하기보다 어떤 거래에서 내 지시와 다른 결과가 보이는지 설명하세요.

82
00:08:58,935 --> 00:09:06,396
오류를 발견한 때와 요청한 때를 구분하고 공식 고객센터나 정해진 접수창구를 이용합니다.

83
00:09:06,396 --> 00:09:11,058
아직 원인을 모른다고 요청을 미룰 필요는 없습니다.

84
00:09:11,058 --> 00:09:15,888
확인한 사실과 의심되는 차이를 나누어 전달하면 됩니다.

85
00:09:15,888 --> 00:09:23,232
다만 자신의 계약에 적용되는 약관과 접수 방법은 해당 서비스에서 다시 확인해야 합니다.

86
00:09:23,354 --> 00:09:26,872
가상 요청 문장을 만들어 보겠습니다.

87
00:09:26,872 --> 00:09:36,481
특정 주문에 대해 45,000원을 결제했는데 실패 표시가 나타났고, 계좌에서 같은 금액의 출금이 추가로 확인되었습니다.

88
00:09:36,481 --> 00:09:44,867
첨부한 거래번호별 처리 상태와 중복 여부를 조사하여 오류가 있다면 정정하고 원인과 처리 결과를 알려 주세요.

89
00:09:44,867 --> 00:09:49,033
이렇게 거래와 차이, 요청을 연결합니다.

90
00:09:49,033 --> 00:09:56,130
추가로 다시 결제한 사실이 있다면 숨기지 않고 그 시각과 거래번호도 적어야 합니다.

91
00:09:56,130 --> 00:10:02,080
내가 실제로 한 지시를 정확하게 설명해야 원인을 구분할 수 있기 때문입니다.

92
00:10:02,080 --> 00:10:08,005
요구금액을 임의로 부풀리지 않고 확인된 내역을 중심으로 작성합니다.

93
00:10:08,114 --> 00:10:20,577
직접 확인한 공개 전자금융 약관은 정정 요구를 받으면 즉시 조사하여 처리한 뒤, 요구를 받은 날부터 2주 이내에 오류의 원인과 처리 결과를 알리도록 정합니다.

94
00:10:20,577 --> 00:10:25,916
회사가 스스로 오류를 안 경우에는 그 사실을 안 날이 기준입니다.

95
00:10:25,916 --> 00:10:32,947
여기서 2주는 아무런 조건 없이 요구금액 전부를 환급해 준다는 약속으로 해석하지 않습니다.

96
00:10:32,947 --> 00:10:41,931
오류가 확인되었는지, 어떤 조치를 했는지, 반환이나 청구 정정이 어디에 반영되는지를 회신에서 확인해야 합니다.

97
00:10:41,931 --> 00:10:49,991
접수일과 회신일을 기록하고 요청에 답하지 않은 항목이 남아 있다면 구체적으로 추가 설명을 요구하세요.

98
00:10:50,114 --> 00:10:56,431
거래내용을 서면으로 받아 보는 요청과 오류를 정정해 달라는 요청은 구별됩니다.

99
00:10:56,431 --> 00:11:03,632
공개 약관에는 거래내용의 서면교부도 요청을 받은 날부터 2주 이내로 정하고 있습니다.

100
00:11:03,632 --> 00:11:14,725
시행령은 운영장애 등으로 거래내용을 제공할 수 없을 때 이용자에게 즉시 알리고, 제공할 수 없는 기간을 서면교부 기간에 넣지 않는 규정을 둡니다.

101
00:11:14,725 --> 00:11:20,806
이를 오류 정정의 모든 기한이 자동으로 늘어난다는 뜻으로 옮기면 안 됩니다.

102
00:11:20,806 --> 00:11:25,754
무엇을 언제 요청했는지 접수 항목을 나누어 적으세요.

103
00:11:25,754 --> 00:11:32,746
자료 제공과 원인 조사, 금액 정정은 연결되지만 각각 확인할 결과가 다릅니다.

104
00:11:32,858 --> 00:11:39,839
고객센터에 전화했더라도 어떤 거래에 관해 무엇을 요청했는지 남겨 두는 것이 좋습니다.

105
00:11:39,839 --> 00:11:47,769
접수번호와 접수일, 담당 창구, 회신 방법을 기록하고 제출한 파일 목록도 적습니다.

106
00:11:47,769 --> 00:11:54,579
단순 문의로 접수되었는지 오류 정정 요구로 접수되었는지 불명확하면 확인하세요.

107
00:11:54,579 --> 00:12:00,165
여러 차례 연락했을 때에는 이전 접수와 이어지는 건인지도 묻습니다.

108
00:12:00,165 --> 00:12:06,558
요청한 내용과 회신 내용을 나란히 두면 답변이 충분했는지도 판단할 수 있습니다.

109
00:12:06,558 --> 00:12:12,248
제출 자료의 원본은 안전하게 보관하고 필요한 사본만 전달하세요.

110
00:12:12,362 --> 00:12:18,276
회신에 처리 완료라고만 적혀 있다면 무엇이 완료되었는지 확인해야 합니다.

111
00:12:18,276 --> 00:12:28,171
조사만 끝난 것인지, 원거래를 취소한 것인지, 청구액을 정정한 것인지, 실제 반환까지 반영된 것인지 구별하세요.

112
00:12:28,171 --> 00:12:34,213
오류가 아니라고 답했다면 어떤 기록을 근거로 판단했는지도 확인합니다.

113
00:12:34,213 --> 00:12:40,528
거래번호별 결과와 원인을 설명받으면 내 대조표와 비교하기가 쉽습니다.

114
00:12:40,528 --> 00:12:47,911
실제 금액 반영에 별도 시간이 필요하다고 안내받았다면 확인할 날짜와 내역을 적어 둡니다.

115
00:12:47,911 --> 00:12:56,947
단순히 기다리라는 답으로 끝내지 않고 어떤 변화가 보이면 마무리할 수 있는지를 구체적으로 확인하는 것이 중요합니다.

116
00:12:57,050 --> 00:13:03,602
내가 정상적으로 지시한 이체를 마음이 바뀌어 멈추려는 경우는 처리 오류와 다릅니다.

117
00:13:03,602 --> 00:13:14,357
공개 약관은 지급의 효력이 발생하기 전에는 정해진 방법으로 거래지시를 철회할 수 있도록 하되, 수단별 효력발생 시점과 절차를 구분합니다.

118
00:13:14,357 --> 00:13:21,948
이미 지급 효력이 발생했다면 단순히 버튼을 눌러 언제나 되돌릴 수 있는 것으로 생각하면 안 됩니다.

119
00:13:21,948 --> 00:13:27,013
자신의 거래 상태와 적용 절차를 공식 창구에서 확인하세요.

120
00:13:27,013 --> 00:13:32,703
오늘 강의는 완료된 모든 이체를 취소할 수 있다고 약속하지 않습니다.

121
00:13:32,703 --> 00:13:39,760
정상 지시의 철회인지, 지시와 다른 처리의 정정인지부터 정확히 나누는 연습입니다.

122
00:13:39,866 --> 00:13:47,108
물건을 사고 싶지 않아 취소하는 일과 결제가 중복 처리되어 바로잡는 일은 다른 문제입니다.

123
00:13:47,108 --> 00:13:57,707
구매 취소는 판매계약과 관련 법령, 판매자의 절차를 확인해야 하고 금융거래 오류는 실제 거래지시와 처리 결과를 대조해야 합니다.

124
00:13:57,707 --> 00:14:04,751
판매자가 주문을 취소했다고 결제의 모든 기록이 즉시 정리된 것으로 보지는 않습니다.

125
00:14:04,751 --> 00:14:10,285
원거래와 취소 요청, 금융회사 반영 결과를 연결하세요.

126
00:14:10,285 --> 00:14:17,108
반대로 결제를 정정했다고 상품 주문도 자동으로 취소되었다고 판단하면 안 됩니다.

127
00:14:17,108 --> 00:14:25,884
어떤 계약을 유지하고 어떤 거래를 취소하려는지 내가 원하는 결과를 분명히 설명해야 혼선을 줄일 수 있습니다.

128
00:14:25,994 --> 00:14:33,184
실패 화면을 보고 다른 카드로 다시 결제했다면 최초 거래와 추가 거래를 나누어 기록합니다.

129
00:14:33,184 --> 00:14:41,686
같은 주문을 결제한 것인지 새 주문이 생긴 것인지, 각 거래가 승인과 청구까지 진행되었는지 확인하세요.

130
00:14:41,686 --> 00:14:51,283
최초 거래가 뒤늦게 완료되었다면 어떤 거래를 정상 결제로 남기고 어떤 거래를 정리할지 관련 창구와 확인해야 합니다.

131
00:14:51,283 --> 00:14:58,548
이 과정에서 내가 결제 버튼을 누른 횟수나 추가 시도를 빠뜨리면 원인 조사가 어려워집니다.

132
00:14:58,548 --> 00:15:03,691
의도와 실제 처리를 구분하되 사실은 정확히 전달합니다.

133
00:15:03,691 --> 00:15:10,254
표에는 거래수단별 번호와 시각, 요청한 취소 대상을 명확하게 표시하세요.

134
00:15:10,370 --> 00:15:16,544
회사에서 정상 처리라는 답변을 받았지만 내 기록과 맞지 않을 수 있습니다.

135
00:15:16,544 --> 00:15:26,440
어떤 거래지시가 확인되었는지, 어느 주문이나 수취인과 연결되는지, 내가 제시한 중복 내역을 각각 검토했는지 질문하세요.

136
00:15:26,440 --> 00:15:34,890
정상이라는 단어를 보고 모든 의문이 해소된 것으로 끝내거나 곧바로 거짓 답변이라고 단정하지 않습니다.

137
00:15:34,890 --> 00:15:39,864
담당자가 다른 거래를 보고 있을 가능성도 있기 때문입니다.

138
00:15:39,864 --> 00:15:46,297
대조표에서 아직 설명되지 않은 줄에 표시하고 관련 자료만 다시 제출합니다.

139
00:15:46,418 --> 00:15:57,149
전자금융거래법은 거래지시의 전자적 전송이나 처리 과정에서 발생한 사고 등으로 이용자에게 손해가 발생한 경우 금융회사 등의 책임을 정합니다.

140
00:15:57,149 --> 00:16:04,936
다만 이용자의 고의나 중대한 과실에 관한 요건과 약정 등 법이 정한 예외도 함께 확인해야 합니다.

141
00:16:04,936 --> 00:16:12,735
화면에 오류 문구가 있었다는 이유만으로 내가 주장하는 모든 손해가 자동으로 배상되는 것은 아닙니다.

142
00:16:12,735 --> 00:16:19,597
반대로 회사가 이용자 실수라고 말했다는 이유만으로 법적 판단이 끝나는 것도 아닙니다.

143
00:16:19,597 --> 00:16:26,889
사고의 경위, 지시 내용, 실제 손해, 책임 제한의 근거를 나누어 검토합니다.

144
00:16:26,889 --> 00:16:30,886
구체적인 분쟁은 자료를 갖추어 상담하세요.

145
00:16:31,010 --> 00:16:37,549
손해가 생겼다고 생각하면 실제 출금이나 추가 비용이 확인되는 자료를 남깁니다.

146
00:16:37,549 --> 00:16:42,536
거래 오류 때문에 발생했다고 보는 이유와 시점도 적으세요.

147
00:16:42,536 --> 00:16:49,424
단순히 불편했다는 설명과 구체적인 금전손해 주장은 필요한 자료가 다를 수 있습니다.

148
00:16:49,424 --> 00:16:54,593
아직 발생하지 않은 예상액을 확정 손해처럼 합산하지 않습니다.

149
00:16:54,593 --> 00:17:02,614
수수료가 청구되었다면 어떤 거래의 수수료인지, 반환 과정에서 별도로 정리되었는지 대조합니다.

150
00:17:02,614 --> 00:17:09,241
오늘은 증권 주문장애의 가격 손실이나 복잡한 영업손해를 계산하지 않습니다.

151
00:17:09,241 --> 00:17:15,895
생활 결제의 실제 차액과 확인된 비용을 정확하게 정리하는 범위에서 실습합니다.

152
00:17:16,010 --> 00:17:25,088
오류를 문의한 뒤 환급을 도와주겠다는 낯선 연락이 오면 기존 접수와 실제로 연결되는지 공식 창구에서 확인하세요.

153
00:17:25,088 --> 00:17:32,757
환급을 위해 먼저 돈을 보내라거나 원격제어 앱을 설치하라는 요구를 그대로 따르지 않습니다.

154
00:17:32,757 --> 00:17:38,030
계좌 비밀번호와 인증번호를 상대방에게 알려 주어서도 안 됩니다.

155
00:17:38,030 --> 00:17:45,400
정상적인 본인확인이 필요할 수는 있지만 누가 어떤 공식 절차에서 요구하는지 확인해야 합니다.

156
00:17:45,400 --> 00:17:50,504
오늘 만든 대조표에는 비밀 인증정보가 필요하지 않습니다.

157
00:17:50,504 --> 00:18:00,726
오류 정정 과정에서 새로운 피해가 생기지 않도록, 연락에 적힌 링크보다 평소 이용하던 공식 앱이나 홈페이지로 직접 들어가 확인합니다.

158
00:18:00,842 --> 00:18:10,258
다른 사람에게 도움을 구하려고 거래 화면을 공개 게시판에 올리면 계좌번호나 거래번호, 이름이 함께 노출될 수 있습니다.

159
00:18:10,258 --> 00:18:17,472
공식 담당 창구에 필요한 자료를 제출하는 것과 불특정 다수에게 공개하는 것은 다릅니다.

160
00:18:17,472 --> 00:18:24,321
공개 상담에는 개인정보를 가린 사본을 사용하고, 원본은 안전한 곳에 보관하세요.

161
00:18:24,321 --> 00:18:31,091
같은 화면을 여러 기기로 옮겼다면 불필요한 공유본이 남지 않았는지도 확인합니다.

162
00:18:31,091 --> 00:18:36,808
다만 원본 증거를 임의로 바꾸거나 중요한 문맥을 삭제하지는 않습니다.

163
00:18:36,808 --> 00:18:42,289
자료의 정확성을 유지하면서 전달 범위를 제한하는 것이 좋습니다.

164
00:18:42,289 --> 00:18:46,352
기록표에는 제출처와 제출일도 남겨 두세요.

165
00:18:46,466 --> 00:18:53,786
회사 답변으로 해결되지 않으면 해당 서비스의 분쟁처리 절차와 외부 조정 경로를 확인합니다.

166
00:18:53,786 --> 00:19:02,054
직접 열람한 공개 약관에는 금융감독원이나 한국소비자원의 관련 분쟁조정 절차가 안내되어 있습니다.

167
00:19:02,054 --> 00:19:08,590
실제로 어느 창구가 적합한지는 거래와 당사자, 쟁점에 따라 확인해야 합니다.

168
00:19:08,590 --> 00:19:14,762
오늘은 접수하면 언제나 환급되거나 책임이 확정된다고 말하지 않습니다.

169
00:19:14,762 --> 00:19:22,367
정정 요구와 회신, 남은 금액 차이, 원하는 해결 내용을 묶어 제출할 자료를 정리합니다.

170
00:19:22,367 --> 00:19:29,541
같은 사건을 설명할 때 날짜와 금액이 바뀌지 않도록 대조표의 기준일을 명확히 표시하세요.

171
00:19:29,666 --> 00:19:34,902
분쟁이 길어지면 모든 내용을 처음부터 반복하기 쉽습니다.

172
00:19:34,902 --> 00:19:40,202
표에서 이미 확인된 사실과 아직 다투는 부분을 구분해 보세요.

173
00:19:40,202 --> 00:19:50,879
주문은 확인되었지만 특정 출금의 원거래 연결이 안 되는 것인지, 취소는 확인되었지만 청구 정정이 안 된 것인지에 따라 질문이 달라집니다.

174
00:19:50,879 --> 00:19:54,837
각 쟁점 옆에 필요한 추가 자료를 적습니다.

175
00:19:54,837 --> 00:20:00,918
담당자가 안내한 확인일이 지났는데 변화가 없다면 그 점도 명시하세요.

176
00:20:00,918 --> 00:20:07,533
대조표를 갱신할 때에는 이전 자료를 지우지 않고 새 상태와 날짜를 추가합니다.

177
00:20:07,533 --> 00:20:14,056
문제의 범위가 줄어드는지 확인할 수 있어야 해결이 진행되고 있는지도 알 수 있습니다.

178
00:20:14,162 --> 00:20:20,102
가상 주문금액은 45,000원이고 실제 출금 합계는 90,000원입니다.

179
00:20:20,102 --> 00:20:27,263
회사가 45,000원을 취소할 예정이라고 안내했지만 아직 반영 내역은 확인되지 않았습니다.

180
00:20:27,263 --> 00:20:30,909
대조표의 확인된 반환액은 얼마일까요.

181
00:20:30,909 --> 00:20:34,216
현재 확인 기준으로는 0원입니다.

182
00:20:34,216 --> 00:20:38,409
예정 금액 45,000원은 메모 칸에 적습니다.

183
00:20:38,409 --> 00:20:45,935
이후 실제 반환이 확인되면 해당 거래번호와 날짜를 추가하고 순출금을 다시 계산합니다.

184
00:20:45,935 --> 00:20:53,904
이 실습의 목적은 회사를 의심하거나 환급을 단정하는 것이 아니라 확인된 상태를 정확히 표현하는 것입니다.

185
00:20:53,904 --> 00:21:00,167
확인 날짜가 달라지면 표의 결과도 달라질 수 있다는 점을 함께 기록하세요.

186
00:21:00,290 --> 00:21:10,878
원거래와 취소거래가 연결되고, 실제 출금이나 청구액과 반환 내역이 설명되며, 유지하거나 취소하려던 주문 상태도 맞아야 합니다.

187
00:21:10,878 --> 00:21:16,112
비용이나 잔액에 남은 차이가 있으면 그 이유까지 확인합니다.

188
00:21:16,112 --> 00:21:21,998
안내 문자를 받았다는 사실만으로 모든 칸을 완료로 바꾸지 않습니다.

189
00:21:21,998 --> 00:21:31,269
반대로 카드 청구액에서 적절하게 차감된 거래를 계좌에 입금되지 않았다는 이유만으로 계속 미처리라고 표시하지도 않습니다.

190
00:21:31,269 --> 00:21:34,888
결제수단에 맞는 확인 자료가 중요합니다.

191
00:21:34,888 --> 00:21:40,500
완료된 날짜와 최종 회신을 함께 보관하며 사건을 마무리하세요.

192
00:21:40,610 --> 00:21:49,219
평소 사용하는 앱에서 거래내역과 취소내역을 어디에서 확인하는지 찾아 두면 문제가 생겼을 때 덜 당황합니다.

193
00:21:49,219 --> 00:21:53,984
오류 정정 요청 창구와 약관의 위치도 확인해 보세요.

194
00:21:53,984 --> 00:21:58,203
이것은 테스트 결제를 새로 하라는 뜻이 아닙니다.

195
00:21:58,203 --> 00:22:03,359
이미 있는 내역과 안내 화면을 살펴보는 연습이면 충분합니다.

196
00:22:03,359 --> 00:22:11,016
여러 결제수단을 연결했다면 실제로 어느 수단을 사용했는지 쉽게 확인할 수 있는지도 봅니다.

197
00:22:11,016 --> 00:22:17,305
증빙을 보관할 폴더와 필요한 항목을 정해 두면 나중에 빠르게 기록할 수 있습니다.

198
00:22:17,305 --> 00:22:24,662
예방의 핵심은 복잡한 기술 지식보다 거래의 상태와 공식 문의 경로를 알아 두는 데 있습니다.

199
00:22:24,770 --> 00:22:28,496
실습지의 6개 점검을 마무리합니다.

200
00:22:28,496 --> 00:22:46,335
주문과 거래번호를 연결했는지, 결제수단과 상태를 구분했는지, 실제 출금과 반환을 대조했는지, 정정 요구의 내용과 접수를 남겼는지, 원인과 처리 결과를 확인했는지, 최종 반영과 미해결 항목을 정리했는지 살펴보세요.

201
00:22:46,335 --> 00:22:51,256
오류를 발견했다고 원인을 혼자 단정할 필요는 없습니다.

202
00:22:51,256 --> 00:22:58,079
확인된 사실을 정확하게 전달하고 설명되지 않은 차이를 구체적으로 질문하면 됩니다.

203
00:22:58,079 --> 00:23:06,009
실패 화면부터 최종 내역까지 연결된 기록이 있어야 정정이 제대로 되었는지도 판단할 수 있습니다.