결제 라이프사이클: 승인부터 정산까지

결제 라이프사이클은 결제가 승인된 순간부터 가맹점 계좌에 자금이 입금되기까지 거치는 고정된 순서로, 승인, 캡처, 클리어링, 정산, 지급으로 이루어집니다. 각 단계는 정확히 하나의 일을 하며, 단계를 지날 때마다 돈의 상태가 달라집니다. 대부분 카드 결제를 탭하는 순간의 단일 이벤트로 생각하지만, 실제로는 여러 단계가 이어진 체인입니다. 결제에서 일어나는 거의 모든 성공과 문제는 이 단계들이 동시에 일어나지 않고 분리되어 있기 때문에 발생합니다.

이 체인을 이해하면 스스로 대사되는 결제와 고객 문의 티켓으로 남는 결제가 갈립니다. 처음부터 끝까지 순서대로 한 번 따라가 보겠습니다.

승인: 이체가 아닌 보류

승인은 자금 이동이 아니라 질의입니다. 카드를 탭하면 요청이 발급사로 전달되고, 발급사는 계좌가 존재하는지, 정상 상태인지, 해당 금액만큼 잔액이나 한도가 있는지 확인합니다. 문제가 없으면 같은 돈이 두 번 쓰이지 않도록 해당 금액을 묶어 두는 보류를 걸고 승인 코드를 반환합니다. 이 시점에 돈은 움직이지 않았습니다. 가맹점은 자금이 유효하다는 약속을 받은 것이며, 이 약속은 카드 브랜드가 정한 기간 동안 유효합니다. 승인은 아무것도 청구되기 전이라면 취소(void)할 수 있고, 사용되지 않으면 저절로 만료됩니다. 결제하는 즉시 카드 잔액은 줄어드는데 명세서 내역은 나중에 확정되는 이유가 이것입니다. 줄어든 것은 청구가 아니라 보류 금액입니다. 승인은 잔액 부족, 사기 방지 규칙, 카드 만료 등으로 거절될 수도 있습니다. 좋은 gateway는 재시도할 가치가 있는 소프트 디클라인과 재시도하면 안 되는 하드 디클라인을 구분합니다. 보류는 돈이 유효하다는 발급사의 약속이므로, 가맹점은 고객 계좌에서 단 한 푼도 빠져나가기 전에 승인 코드만 믿고 상품을 넘겨도 안전합니다.

캡처: 보류를 청구로 전환

캡처는 가맹점이 “지금 수취하라”고 요청하는 단계입니다. 보류를 실제 대금 청구 요청으로 바꿉니다. 캡처는 전액, 부분(승인 금액보다 적은 최종 금액, 예를 들어 사전 승인보다 저렴한 상품이 배송된 경우), 지연(주문 시 승인하고 출고 시 캡처)으로 나뉩니다. 오프라인 매장 결제는 승인과 캡처를 한 번에 처리하는 것이 기본입니다. 호텔, 주유소, 마켓플레이스는 카드를 제시하는 시점에 최종 금액을 알 수 없으므로 승인만 먼저 하고 캡처는 나중에 합니다. 승인과 캡처 사이의 간격은 의도적으로 마련된 유용한 틈으로, 가맹점이 실제로 얼마를 청구할지 결정하는 구간입니다.

클리어링: 대사를 위한 일괄 처리

캡처된 결제는 실시간으로 하나씩 정산되지 않습니다. 파일로 모여 가맹점의 매입사와 카드 브랜드 사이에서 일괄로 교환되는데, 이것이 클리어링입니다. 이 단계에서 거래를 대조하고, 금액을 상계하고, 브랜드 수수료와 인터체인지를 적용하여 누가 누구에게 얼마를 줄지 모두가 합의합니다. 클리어링은 자금 이동이 아니라 대사 작업이며, 다음 단계가 실행할 합의된 총액을 산출합니다. 구조적으로 배치 프로세스이기도 한데, 계산대에서는 즉시 끝난 것 같던 결제가 현금으로 들어오기까지 며칠이 걸리는 진짜 이유입니다. 배치는 컴퓨터의 한계 때문이 아닙니다. 수천 개 기관이 서로의 채권과 채무를 효율적으로 상계하도록 설계된 방식으로, 커피 한 잔마다 이체하지 않고 한 주기에 한 번 합의된 총액을 교환합니다.

승인은 약속이고, 캡처는 청구이며, 실제로 돈이 움직이는 단계는 정산뿐입니다. 이 셋을 혼동하면 아직 받지 못한 돈을 매출로 잡게 됩니다.

정산: 돈이 실제로 이동하는 단계

정산은 은행 간에 자금이 실제로 오가는 단계입니다. 브랜드는 클리어링에서 상계한 총액을 토대로 발급사에서 매입사로 돈을 이동시키며, 각 기관은 개별 거래가 아니라 순포지션을 기준으로 정산합니다. 정산은 자금을 실제로 사용할 수 있는 날인 결제일(value date)에 맞춰 이루어지므로 결제에는 T+1, T+2 같은 리듬이 있습니다. 돈은 실재하지만 고객의 시계가 아니라 브랜드의 달력에 따라 도착합니다. 이전 단계까지는 모두 장부 처리였고, 이 단계에서 원장 기록이 비로소 사용 가능한 잔액이 됩니다. 순액 기준으로 지급할 기관은 내고 받을 기관은 받습니다. 순액 방식이라 은행 간에 실제로 이동하는 금액은 하루 결제 총액의 일부에 불과하며, 수백만 건을 처리하는 브랜드 네트워크가 관리 가능한 수준의 정산 건수로 운영되는 이유가 여기에 있습니다.

지급: 매입사에서 내 계좌로

정산으로 매입사에 돈이 도착하면, 지급은 이를 가맹점에 전달합니다. 매입사는 일별, 주별 또는 요청 시 일정에 따라 가맹점의 누적 잔액에서 처리 수수료와 환불·분쟁에 대비한 유보금을 제외하고 가맹점 은행 계좌로 입금합니다. 사업자가 실제로 보는 금액이 바로 이것이며, 대사가 잘 되느냐 고통스러우냐가 갈리는 지점입니다. 지급액은 여러 거래를 합친 순액이므로, 이를 개별 주문과 맞추는 일은 그 자체로 하나의 작업입니다. 각 주문의 식별 정보를 끝까지 유지하는 gateway라면 이 작업이 간단하지만, 그렇지 않으면 지급 건마다 스프레드시트가 필요해집니다. 저희 gateway의 흐름(/products/gateway)은 지급액을 구성한 주문들과 대사할 수 있도록 설계되어 있습니다.

크립토가 브리지를 더하는 지점

크립토나 스테이블코인 결제는 이 체인을 대체하지 않고, 앞부분에 전환 구간 하나를 추가할 뿐입니다. 발급사의 승인 보류 대신 결제가 온체인에서 확인됩니다. 고객이 이체에 서명하고, 은행이 보류를 승인하는 대신 네트워크가 컨펌을 쌓아 가면서 최종성이 확보됩니다. 확인이 끝나면 오프램프가 크립토를 법정화폐로 전환하고, 이후에는 다른 모든 결제와 같은 클리어링, 정산, 지급 경로로 돌아옵니다. 새로운 요소는 첫 구간에만 있고, 뒷부분은 의도적으로 평범하게 유지됩니다. 정산은 평범하게 두고 새로운 메커니즘은 꼭 필요한 곳에만 넣는다는 것이 설계 원칙입니다. 하류의 재무, 대사, 감사 담당자가 결제가 어떻게 시작되었는지 알 수 없어야 하기 때문입니다. 몇 번의 컨펌을 최종으로 볼지는 체인의 법칙이 아니라 정책 선택입니다. 기준이 높을수록 속도를 내주고 리오그에 대한 확실성을 얻으며, 오프램프는 리스크 선호도가 정한 깊이까지 기다린 뒤에 법정화폐를 정산 경로로 내보냅니다.

단계 구분이 운영에서 중요한 이유

환불, 취소, 분쟁은 각각 특정 단계에 연결되어 있으며, 올바른 단계를 짚는 것이 핵심입니다. 캡처 전에 취소하면 승인을 void하는 것이므로 돈은 한 번도 움직이지 않았고 돌려줄 것도 없습니다. 정산 후에 취소하면 환불을 발행하게 되며, 이는 반대 방향의 새로운 결제로서 고유한 라이프사이클을 가집니다. 차지백은 클리어링까지 거슬러 올라가 이미 정산된 금액을 회수합니다. 이를 구분 없이 하나의 “취소”로 다루면 원장이 어긋나고, 각각 별개 단계에 대한 작업으로 다루면 모든 사례에 올바르고 감사 가능한 처리가 생깁니다. 승인, 캡처, 클리어링, 정산, 결제일 등의 용어는 /glossary에 정리되어 있습니다.

기억할 핵심은 하나입니다. 결제는 이벤트가 아니라 상태의 체인입니다. 승인은 확보하고, 캡처는 청구하고, 클리어링은 합의하고, 정산은 이동하고, 지급은 전달하며, 크립토 구간은 맨 앞에 전환 단계를 붙일 뿐입니다. 돈은 정산 전까지는 약속이고 정산 후에는 사실입니다. 사실이 되기 전에 매출로 잡는 사업자는 아직 갖지 못한 돈을 세고 있는 것입니다. 결제가 어떤 상태인지 알면 나머지 결제 운영은 더 이상 어렵지 않습니다.