한국 결제: 가상계좌, 계좌이체, 카카오페이·토스 버튼의 차이

한국 결제 화면의 버튼 하나 뒤에는 성격이 전혀 다른 의무가 숨어 있을 수 있습니다. 계좌이체, 주문 결제용 가상계좌, 카카오페이나 토스페이 같은 간편결제를 "현지 P2P"라는 한 범주로 묶어서는 안 됩니다. 시작, 승인, 환불 방식이 모두 다릅니다. 프로세싱 입장에서 이는 무엇보다 결제 라이프사이클의 문제입니다.

또 하나 유용한 구분이 있습니다. 소비자 서비스인 토스페이와 PG인 토스페이먼츠는 같은 결제수단 이름이 아닙니다. PG API에는 TRANSFER, VIRTUAL_ACCOUNT, EASY_PAY가 따로 있습니다. "토스"라는 단어만으로는 구매자가 은행 계좌를 썼는지, 편리한 인터페이스 안에서 카드를 썼는지, 아니면 다른 합의된 수단을 썼는지 알 수 없습니다.

가상계좌: 정보가 먼저, 돈은 나중

토스페이먼츠 가상계좌 연동에서 승인 호출은 계좌를 발급할 뿐 결제를 완료하지 않습니다. 입금 전에는 WAITING_FOR_DEPOSIT 상태가 유지되고, 정확한 금액이 들어오면 DONE이 됩니다. 이는 해당 상품의 문서화된 특성입니다. 개발자가 일반 카드 결제 로직을 그대로 가져와 API 성공 응답 직후 상품을 내주면, 아직 입금되지 않은 계좌 정보만 보고 상품을 넘기게 될 수 있습니다.

paymentKey와 orderId는 따로 저장해야 합니다. virtualAccount에는 accountNumber, bankCode, customerName, dueDate가 있고, refundStatus와 settlementStatus는 별도로 정의되어 있습니다. 그래서 paid 플래그 하나로는 전체 사이클을 표현할 수 없습니다. 확정된 구매, 처리 중인 환불, 아직 끝나지 않은 가맹점 정산이 한 주문에 동시에 걸려 있을 수 있습니다.

내부 원장은 발급된 계좌를 정확한 금액, 기한, 결제 시도와 연결해야 합니다. 야간 교대 중에 마감 시각이 어긋나지 않도록 시간은 원래 시간대와 통일된 내부 기준으로 함께 저장하는 것이 좋습니다. 입금 전에 주문이 취소되었다면 그것은 아직 환불이 아닙니다. 돌려줄 돈이 없기 때문입니다. 사용자에게는 존재하지 않는 refund 약속이 아니라 입금 안내가 취소되었다는 사실을 보여줘야 합니다.

문서 속 의외의 디테일: 상태가 되돌아갈 수 있다

토스페이먼츠는 입금 오류로 DONE이 다시 WAITING_FOR_DEPOSIT으로 바뀌는 경우를 경고합니다. 또 PAYMENT_STATUS_CHANGED와 DEPOSIT_CALLBACK을 동시에 구독하면 한 결제에 대해 이벤트가 두 번 옵니다. 이벤트 설명. "DONE을 한 번 봤으면 더는 읽지 않는다"는 식으로 처리 로직을 짜지 말아야 할 충분한 이유입니다.

운영상 결론은 현행 가이드에 따라 webhook의 진위를 검증하고, 상태 전이 이력을 저장하며, 예외적인 역방향 전이는 검토 대상으로 넘기는 것입니다. 앞뒤가 맞지 않는 이벤트 하나만 보고 구매자에게 자동으로 다시 입금하라고 요청해서는 안 됩니다. 먼저 PG에 현재 상태를 확인하고, 확인된 상황을 고객에게 설명해야 합니다. 그렇지 않으면 예외가 이중 출금과 분쟁으로 번집니다.

금액이 맞으면 구매자 이름과 입금자 이름이 달라도 가상계좌 결제가 기술적으로 거절되지 않는다는 점도 따로 문서화되어 있습니다. 그렇다고 이런 의무가 있는 사업에서 결제자 확인을 건너뛰어도 된다는 뜻은 아닙니다. 계좌와 금액으로 입금이 매칭되었다고 해서 그 돈의 출처가 등록된 고객이라는 것이 증명되지는 않습니다.

계좌 환불: 여기서는 정말 추가 정보가 필요하다

이미 입금된 가상계좌 결제를 환불할 때 토스페이먼츠는 refundReceiveAccount 정보, 즉 은행, 계좌번호, 예금주명을 요구합니다. 입금 전 취소에는 이 정보가 필요 없습니다. 문서에는 해당 인터페이스 시나리오로 refundReceiveAccount를 받을 수 있는 시간이 결제창을 연 뒤 30분으로 제한된다는 점도 나와 있습니다. 받은 정보는 합의된 개인정보 보호 요건에 따라 처리해야 합니다.

예금주명은 장식용 문자열이 아닙니다. 결제수단 가이드는 법인 계좌명 확인과 공백이 포함된 영문 이름 확인 문제를 따로 언급합니다. 따라서 환불 양식은 은행에 등록된 표기가 필요하다고 안내해야 하고, 고객 지원팀은 이름 오류, 잘못된 계좌번호, 기술 장애를 구분해야 합니다. 확인에 실패한 계좌를 다른 사람의 수취인으로 바꿔 넣어 "해결"해서는 안 됩니다.

실무 테스트는 두 개의 독립된 시나리오로 구성됩니다. 발급되었지만 입금되지 않은 계좌를 취소하는 것, 그리고 입금이 확인된 뒤 허용된 금액을 환불하는 것입니다. 그다음 리포트와 실제 결과를 확인합니다. 팀이 첫 번째 시나리오만 보여줬다면 실제 금전 환불 능력은 아직 증명되지 않은 것입니다.

카카오페이: 토큰을 받고 돌아와도 approve가 남아 있다

카카오페이 단건 결제에서는 먼저 주문 정보와 CID로 ready를 호출하고 tid를 저장합니다. 사용자 인증이 끝나면 pg_token이 오고, 서버는 이를 tid, partner_order_id, partner_user_id와 묶어 approve를 호출합니다. 응답은 결제의 tid와 개별 요청의 aid를 구분합니다. 덕분에 취소와 조사 과정에서 연결 고리를 잃지 않습니다. Single-payment API.

개발자에게 중요한 것은 happy path만이 아닙니다. 사용자는 페이지를 닫거나, 두 번째 주문을 열거나, 한참 뒤에 돌아올 수 있습니다. 토큰과 올바르게 저장된 컨텍스트의 매칭은 서버에서 이루어져야 합니다. "이 전화번호의 마지막 주문"을 고르는 방식은 안 됩니다. 기기와 세션은 화면 처리에 도움이 될 뿐, 금융 시도와 주문의 명확한 연결을 대신하지 못합니다.

사용 가능한 결제수단과 정산은 계약이 정한다

카카오페이는 가맹점 코드 발급 전에 가맹점 심사를 거친다고 설명합니다. 토스페이먼츠도 계약으로 연결된 결제수단을 확인하도록 안내합니다. 테스트 credentials와 설치된 SDK가 있다고 해서 사업자가 아무 결제수단이나 켤 권리를 얻은 것은 아닙니다. 런칭 체크리스트에는 법인, 허용 업종, MID/CID, 결제수단, 정산 계좌를 기록합니다.

webhook이 깔끔하더라도 별도의 정산 리포트가 필요합니다. 토스페이먼츠 API는 정산과 지급 정보를 제공하지만, 실제 일정과 차감 항목은 귀사 계약 기준으로 확인해야 합니다. 주문, 성공한 입금, 취소, 지급 예정 net 금액을 대사하십시오. 그래야 기술적으로 완료된 구매와 아직 은행 송금으로 이행되지 않은 PG의 의무를 구분할 수 있습니다.

한국 결제 시장은 도박에 대한 일반 허가가 아니다

대한민국 형법은 도박과 도박 장소·공간 개설을 따로 규율합니다. 가상계좌를 발급받거나 카카오페이 결제를 처리할 수 있다는 사실에서 특정 온라인 카지노의 적법성을 끌어낼 수는 없습니다. 해외 라이선스는 적용되는 국내 근거와 PG 승인을 대신하지 못하며, 업종을 위장하는 것은 허용되는 해법이 아닙니다.

좋은 한국형 checkout에 필요한 것은 더 많은 버튼이 아니라 더 적은 추측입니다. 구매자는 다음 단계를 이해하고, 운영자는 신뢰할 수 있는 상태를 보고, 회계 담당자는 정산을 찾을 수 있어야 하며, 환불은 검증된 근거로 합의된 계좌에 완료되어야 합니다. 바로 이것이 관리되는 가맹점 결제 수납과 우연히 모인 송금 묶음의 차이입니다.