환불과 차지백: 금액과 건별 상태를 통제하는 법

고객의 문의 하나가 취소, 환불, 카드사 이의제기(차지백)로 이어질 수 있습니다. 고객 지원팀은 대화 내용만, 재무팀은 출금 내역만 본다면 각 팀이 따로 새로운 자금 이동으로 '문제를 해결'할 수 있습니다. 보호는 원결제, 고객에게 한 약속, 모든 금전 작업이 연결되어 있되 뒤섞이지 않은 공통 사건 카드에서 시작됩니다.

부분 환불의 가상 사례

구매자가 200 화폐 단위의 주문을 결제했습니다. 판매자는 50의 부분 환불에 합의하고 이를 생성해 처리 확인을 받았습니다. 나중에 원금 200 전체에 대한 분쟁이 접수됩니다. 팀 입장에서는 서로 연결된 기록이 세 개입니다. 결제 200, 환불 50, 분쟁 200입니다. 이를 '잔액 150'이라는 한 줄로 바꿔 이력을 잃어서는 안 됩니다.

환불 상태, 금액, 분쟁 사유를 확인하고, 증빙을 모으고, PG사가 정한 대응 절차를 파악해야 합니다. 고객에게 별도로 직접 송금하면 이중 보상이 생길 수 있습니다. 200 − 50 = 150이라는 계산은 점검할 질문을 보는 데 도움이 되지만, 그 자체로 분쟁의 결과나 당사자의 의무를 정하지는 않습니다.

원거래의 상태부터 확인하라

카드 거래라면 승인만 되었는지, capture가 실행되었는지, 환불이 생성되었는지, 진행 중인 분쟁이 있는지 확인하십시오. 여기서 capture는 승인 후 판매자가 대금 청구를 확정하는 것을 말합니다. 고객이 '돈이 빠져나갔다'고 말한 것만으로 결론 내리지 마십시오. 은행 앱에 거래가 표시되는 것이 PG사 쪽 상태를 대신하지는 않습니다. 계좌 이체나 다른 결제수단은 그 수단 고유의 수명 주기를 따르십시오.

Adyen은 승인되었지만 아직 매입되지 않은 결제의 취소를 설명합니다. 이미 매입이 이루어졌다면 환불 절차가 필요합니다. 결제수단과 연동 방식마다 제약이 있으므로 작업 전에 확인해야 합니다. 출처: Adyen, Cancel.

내부 화면에서는 작업 이름을 결과 기준으로 붙이는 것이 좋습니다. '매입 전 결제 취소' 또는 '완료된 결제에 대한 환불 생성'처럼요. 너무 포괄적인 버튼은 직원에게 판단을 떠넘기는데, 시스템은 확인된 상태를 바탕으로 이를 안내해 줄 수 있는 경우가 많습니다. 상태가 불확실하다면 먼저 거래 결과를 확인하십시오.

reversal이라는 단어가 어디서나 같은 뜻은 아니다

Adyen에서 reversal 작업은 매입 여부에 따라 취소 또는 환불을 선택하며, 문서는 제약 사항을 따로 나열합니다. 따라서 API 메서드 이름을 모든 시스템에서 자동으로 '승인 취소'로 번역해서는 안 됩니다. 출처: Adyen, Reversal.

Stripe는 일부 조기 환불이 reversal로 표시된다고 설명합니다. 원거래가 명세서에서 사라지고, 별도의 입금 내역은 생기지 않습니다. 고객이 새로운 입금 내역을 찾고 있을 때 고객 지원팀이 알아야 할 중요한 점입니다. 출처: Stripe, Refund and reversal.

문의 카드에는 PG사의 용어와, 고객에게 일어난 결과에 대한 알기 쉬운 설명을 따로 저장하십시오. 예를 들어 '원거래 취소를 요청함'이 '이미 입금되었습니다'라는 약속보다 정확합니다. 소요 기간을 안내할 때는 해당 결제수단의 최신 조건과 확인된 상태를 사용하십시오. 어느 나라, 어느 은행에나 같은 일수를 약속하면 불필요한 문의만 늘어납니다.

분쟁과 차지백은 별도의 대기열이 필요하다

분쟁은 결제에 대한 이의제기를 뜻하고, 차지백(chargeback)은 흔히 그와 관련해 카드 네트워크를 통해 이루어지는 대금 회수를 가리킵니다. 화면마다 용어는 조금씩 다릅니다. Stripe가 설명하는 카드 프로세스에서는 분쟁이 열리면 금액이 차감되며, 분쟁 절차 밖의 일반 환불은 할 수 없습니다. 답변 기한과 증빙 제출 가능 여부는 건마다 다릅니다. 출처: Stripe, How disputes work.

따라서 카드사에서 온 요청은 기한, 담당자, 원거래 링크를 갖춘 별도 작업으로 만들어야 합니다. 고객 지원팀의 '고객 동의함' 메모가 이 작업을 자동으로 종결하지는 않습니다. 공식 상태와 필요한 조치를 확인하십시오. 이전에 환불한 적이 있다면, 두 시스템이 알아서 기록을 맞춰 줄 거라 가정하지 말고 허용된 절차로 증빙을 첨부하십시오.

아직 진행 중인 환불도 계산에 넣어라

원결제가 200이라고 합시다. 50 환불은 이미 완료되었고, 120 환불이 하나 더 전송되어 결과를 기다리고 있습니다. 추가 임의 환불을 내부적으로 통제하려면 두 금액을 모두 임시로 반영하는 것이 유용합니다. 200 − 50 − 120 = 30입니다. 이는 동시 작업을 막기 위한 제안이지, 당사자의 권리를 정하거나 API의 보편적인 공식이 아닙니다.

최종 확인만 기다린다면 두 번째 운영자는 '50 환불됨'을 보고 150을 또 승인할 수 있습니다. 그러므로 생성되었거나 대기 중인 요청을 완료된 요청과 나란히 보여 주십시오. 실패 후 내부 한도를 풀어 주는 것은 확인된 결과가 있을 때만이어야 하며, 직원이 오래 답을 받지 못했다는 이유로 풀어서는 안 됩니다.

진행 중인 분쟁은 별도의 제약을 더합니다. 먼저 PG사가 설명하는 분쟁 처리 규칙을 적용하십시오. 환불 금액과 분쟁 금액을 두 개의 확정 손실로 자동 합산하지 말고, 서로 상계되었다고 보지도 마십시오. 대사 전까지는 식별자별 상태와 실제 자금 이동이 중요합니다.

하나의 문의에 두 가지 종결

고객 측 처리가 재무 처리보다 먼저 끝날 수 있습니다. 구매자에게 결과를 설명했지만, PG사 기록과 리포트를 아직 대조해야 하는 경우입니다. 반대도 있습니다. 자금 이동은 확인되었는데, 거래가 다르게 표시된 탓에 고객이 별도 입금 내역을 계속 찾는 경우입니다. '해결됨' 스위치 하나 대신 두 가지 종결 표시를 두십시오.

재무 종결에는 금액, 확인 출처, 원결제와의 연결이 있어야 합니다. 고객 종결에는 실제로 수행된 조치에 대한 명확한 안내와, 문의가 있을 때 가능한 다음 단계가 있어야 합니다. 환불 전송만 확인되었다면 구매자가 이미 돈을 확인할 수 있다고 약속하지 마십시오.

분쟁 기한은 시간대와 담당자를 포함해 따로 관리하십시오. 내부 준비 기한은 승인과 증빙 업로드 절차에 필요한 만큼 외부 마감보다 앞당겨 정합니다. 고객이 분쟁을 철회했다고 말하면 그 메시지를 저장하되 공식 상태를 확인하십시오. 고객이 약속한 행동과 PG사에서 확인된 결과는 이력에 서로 다른 표시로 남겨야 합니다.

환불은 정확히 어디서 지연되는가

환불 승인부터 전송까지의 시간, 정리되지 않은 상태의 비율, 한 건에 대한 반복 문의 수를 측정하면 유용합니다. 분쟁은 기한 준수와 증빙의 완결성을 따로 집계하십시오. 모든 것을 하나의 환불 속도 지표로 합치지 마십시오. 직원이 통제할 수 있는 단계와 외부 참여자를 기다리는 단계는 서로 다른 개선이 필요합니다.

이 지도는 업무를 조직하는 데 도움이 되지만, 구매자나 판매자의 보편적인 권리를 정하지는 않습니다. 근거, 기한, 절차는 결제수단, 계약, 적용 규정에 따라 정해집니다. 건마다 검증 가능한 이력이 있으면 이를 구체적으로 논의할 수 있고, 자금이 이중으로 움직일 위험도 줄어듭니다.