クイズ: 清算・決済とカード承認

T+2 결제일 계산기를 달력 기준 이틀 더하기로 짜면 사고가 언제 드러나는가?

• 배포 직후 첫 거래일. 계산이 즉시 어긋나기 때문에
• 월말 마감. 집계가 한 번에 몰리기 때문에
• 주말이나 공휴일이 끼는 주. 평일 한복판에서는 몇 달이고 맞기 때문에
• 분기 결산. 감사에서만 확인되기 때문에

체결 1,200건에 결제 1,152건이다. 이 48건 차이에 대한 올바른 해석은?

• 48건이 어긋난 것이므로 그 48건을 찾아 처리하면 된다
• 결제 없는 체결 60건과 체결 없는 결제 12건이 서로를 지운 결과일 수 있어, 양방향으로 따로 세야 한다
• 결제 표에 상계가 반영돼 건수가 줄어든 정상 결과다
• 결제일이 아직 오지 않은 48건이 빠진 것이다

미결제(fail)를 셀 때 결제일 조건을 빼먹으면 무슨 일이 생기는가?

• 아직 결제일이 오지 않은 건까지 섞여 잔고가 부풀고, 그 숫자로 증거금을 다시 계산하면 멀쩡한 계좌가 묶인다
• 이미 결제가 끝난 건까지 다시 세어져 미결제 금액이 두 배가 되고, 건수는 맞는데 금액만 어긋나 원인을 찾기 어려워진다
• 상대 기관 파일에 결제 기록이 없는 건이 통째로 빠져서 미결제 잔고가 실제보다 작게 나온다
• 훑는 행이 늘어 집계 시간만 길어질 뿐, 결제일이 지난 건만 미결제로 잡히므로 결과 자체는 달라지지 않는다

미결제를 '기록 없음 / pending / failed' 로 갈라 보고해야 하는 실무적 이유는?

• 금액 단위가 달라 합산이 불가능하기 때문에
• 규정이 사유별 보고를 요구하기 때문에
• 셋의 원인 위치와 담당 부서가 달라, 합쳐 보고하면 아무도 자기 일로 받지 않기 때문에
• pending 은 시간이 지나면 저절로 해소되므로 제외해야 하기 때문에

승인은 났는데 매입이 한 번도 없는 건을 유효기간이 지나기 전에 찾아야 하는 이유는?

• 유효기간이 지나면 승인이 자동으로 풀리고, 그 뒤 매입은 거절돼 되돌릴 방법이 없기 때문에
• 유효기간이 지나면 승인 기록이 로그에서 삭제되기 때문에
• 유효기간이 지나면 자동으로 매입 처리되어 이중 청구가 되기 때문에
• 유효기간이 지나면 수수료율이 올라가기 때문에

같은 결제가 두 번 청구된 건을 찾을 때 auth_id 로 아무것도 나오지 않는 이유는?

• 재시도된 요청은 승인 로그에 남지 않기 때문에
• 두 번째 승인은 첫 번째의 auth_id 를 그대로 쓰기 때문에
• 재시도로 생긴 두 승인은 서로 다른 auth_id 를 받고, 같은 것을 두 번 했다는 사실은 멱등키에만 남기 때문에
• 이중 청구는 매입 로그에만 남고 승인 로그에는 남지 않기 때문에

결제 요청 타임아웃으로 이중 승인이 나는 문제에 대한 근본 조치는?

• 클라이언트 타임아웃을 넉넉히 늘려 재시도가 일어나지 않게 한다
• 재시도 횟수를 1회로 제한한다
• 서버가 멱등키를 저장하고 같은 키에는 같은 응답을 돌려준다
• 승인 직후 매입을 즉시 실행해 창을 없앤다

5만원 승인에 3만원만 매입한 뒤 승인 취소를 내지 않으면 생기는 일은?

• 차액 2만원이 고객 한도에 계속 묶여, 쓰지도 않은 금액 때문에 다음 결제가 거절될 수 있다
• 차액 2만원이 다음 결제에 자동으로 이월된다
• 매입 금액이 승인 금액으로 자동 보정되어 5만원이 청구된다
• 가맹점이 차액만큼 수수료를 더 부담한다