결제 레일 비교: 승인 확인부터 환불까지

구매자 화면에는 이미 "결제 완료"가 떠 있습니다. 가맹점은 아직 확인을 기다립니다. 시스템 참가자 간 정산은 끝났지만, 판매자 지급은 나중으로 잡혀 있습니다. 네 가지 진술이 모두 같은 결제 한 건에 해당할 수 있습니다. 그래서 결제수단 비교는 버튼 위의 로고가 아니라 타임라인과 의무에서 시작합니다.

이 질문들은 서로 연결되어 있지만 서로를 대신하지는 않습니다. 수수료와 전환율을 비교하기 전에, 각 경로에서 결제가 어떤 단계를 거치는지 살펴보세요. 화면의 같은 초록색 체크 표시라도 연동 방식에 따라 다른 의미일 수 있습니다.

네 가지 이벤트를 분리하라

구매자의 결제 시작, PG사의 승인 확인, 해당 결제 시스템 내의 정산, 가맹점 계좌로의 지급을 각각 따로 부르세요. 각 상태값이 어떤 이벤트를 뜻하는지 확인하세요. "성공"이라는 표시는 팀이 정확히 무엇이 끝났는지 이해할 때만 도움이 됩니다.

정산의 완결성에는 명확한 의미가 있습니다. CPMI-IOSCO 원칙은 최종 정산 시점과, 그 이후로는 지시를 철회할 수 없는 시점을 명확히 정의하도록 요구합니다. 그렇다고 모든 결제 방식의 환불이나 이의 제기 규칙이 같다는 뜻은 아닙니다. PFMI 원칙 8.

국내 계좌이체: 매칭에 주목하라

계좌이체라면 구체적으로 어떤 국가 시스템인지, 입금 수취 구조와 확인 방식은 무엇인지 정하세요. "국내"라는 단어만으로는 속도, 비용, 운영 시간이 정해지지 않습니다. 입금이 주문과 어떻게 연결되는지, 금액이나 입금자명이 틀리면 어떻게 되는지 물어보세요.

예를 들어 Stripe 문서는 계좌이체 대사와 고객 잔액 처리를 따로 설명합니다. 돈을 받는 것과 그 돈을 구매에 연결하는 것이 서로 다른 운영 과제라는 점을 보여 줍니다. 세부 사항은 해당 PG사에 한정됩니다. Stripe 계좌이체 문서.

티켓 판매 서비스라면, 좌석이 예약된 채로 직원이 입금자를 손으로 찾아야 할 때 낮은 수수료의 매력은 사라집니다. 화면에 계좌 정보를 띄우는 것만이 아니라, 확인되지 않은 입금을 처리하는 절차가 필요합니다.

실시간 결제는 업무 흐름을 바꾼다

빠른 정산은 구체적인 시스템별로 확인해야 합니다. ECB는 TIPS를 중앙은행 화폐로 24시간 최종적이고 철회 불가능한 정산을 하는 시스템으로 설명합니다. 이것은 TIPS의 특성이지, 어떤 중개 기관을 거치든 모든 가맹점에 특정 지급 일정을 약속하는 것은 아닙니다. ECB의 TIPS 개요.

실무에서 빠른 경로는 정확한 계좌 정보, 신뢰할 수 있는 상태 처리, 신속한 고객지원의 중요성을 높입니다. 착오 송금에 대한 반환 요청 절차가 있는지, 어떻게 처리되는지, 누가 참여해야 하는지 확인하세요. 정산의 완결성을 어떤 반환이나 보상도 불가능하다는 일반론으로 바꾸지 마세요.

성공 데모만이 아니라 완료되지 않은 시나리오도 보여 달라고 요청하세요. 승인 확인 지연은 누가 보게 됩니까? 주문은 어떤 상태에 머뭅니까? 구매자는 무엇을 받습니까? 이 답은 문의가 들어올 때마다 개발자가 나서지 않아도 운영팀이 볼 수 있어야 합니다.

카드: 구매 이후 단계를 고려하라

카드 거래는 나중에 분쟁이 생길 수 있습니다. Stripe는 카드 소지자가 카드사에 결제 이의를 제기하고 가맹점이 증빙을 제출하는 과정을 설명합니다. Stripe의 카드 분쟁 수명 주기.

그래서 일은 결제 화면에서 끝나지 않습니다. 알기 쉬운 영수증, 주문 이행 정보, 문의 담당자, 기한 관리가 필요합니다. 초기 수수료만 비교하면 이런 비용을 놓칩니다. 그렇다고 분쟁이 생겼다는 사실이 곧 돈을 잃는다는 뜻은 아닙니다. 적용되는 절차와 증빙이 중요합니다.

지갑: 화면 아래에 무엇이 있는지 확인하라

지갑이 항상 별도의 정산 시스템인 것은 아닙니다. 일부 모바일 지갑은 카드 정보와 결제 토큰을 사용합니다. EMVCo는 토큰화를 카드 번호를 사용 범위가 제한된 대체 값으로 바꾸는 것이라고 설명합니다. EMVCo 토큰화 개요.

자금 출처와 선택한 상품의 규칙을 확인하세요. "지갑"이라는 단어가 붙은 모든 서비스에 같은 수수료, 환불 절차, 정산 완결성을 가정해서는 안 됩니다. 구매자에게 익숙한 화면 뒤에 대사와 고객지원 측면의 큰 차이가 숨어 있을 수 있습니다.

주말이 전체 흐름을 검증한다

정산 시스템이 24시간 돌아간다고 해서, 중개 기관에서 밤에 예외 건을 누가 처리하는지에 대한 답이 되지는 않습니다. 탁상 시나리오를 돌려 보세요. 결제는 토요일에 확인되었고, 티켓은 한 시간 뒤에 필요하며, 금액이 주문과 매칭되지 않았습니다. 검증된 기록에 누가 접근할 수 있고, 누가 이행 여부를 결정할 권한이 있으며, 다음 에스컬레이션은 언제 가능합니까? 이것은 시스템 전체의 특성이 아니라 여러분의 서비스 체인에 대한 점검입니다.

공급사가 "즉시"를 약속한다면 측정의 시작과 끝을 정의해 달라고 하세요. 앱에서의 승인 확인부터 가맹점 입금까지입니까? 은행의 송금부터 참가자 간 정산까지입니까? 지급 가능 잔액이 생긴 시점부터 은행 지급까지입니까? 서로 다른 시계를 설명 없이 한 열에서 비교할 수는 없습니다. 경로마다 계약 내용을 운영 구성도와 함께 보관하세요.

돈이 돌아가는 길은 따로 설계한다

구매자는 한 가지 방식으로 결제했는데, 고객지원은 다른 방식으로 보상을 제안할 수 있습니다. 이런 변경에는 허용 여부, 수취인, 권한에 대한 확인이 필요합니다. 직원에게 편하다고 해서 아무 송금이나 원거래의 환불이 되지는 않습니다. 상품이 어떤 환불 시나리오를 지원하는지, 그것이 대사에 어떻게 반영되는지 미리 확인하세요.

두 레일을 비교할 때는 같은 의무 세트를 기준으로 평가하는 것이 좋습니다. 결제, 이행, 오류 정정, 환불, 고객 문의, 재무 마감입니다. 한 경로가 진입 비용은 싸지만 확인되지 않은 입금을 수작업으로 처리해야 한다면, 그 작업을 모델에 더하세요. 비용은 요금표만으로 바뀌지 않습니다. 레일의 동작 방식이 여러분의 제품에 얼마나 맞는지에 달려 있습니다.

주문 하나를 모든 경로에 통과시켜 보라

비교용으로 가상의 티켓 구매를 사용하세요. 정상 완료, 응답 지연, 재시도, 부분 환불, 고객 불만입니다. 티켓을 발권하는 기준이 되는 이벤트와, 재무팀이 이후 은행 거래 내역과 대조할 데이터를 기록하세요.

• 어떤 구매자와 은행이 이 경로를 쓸 수 있는가?
• 무엇이 주문을 확인하고, 무엇이 정산을 확인하는가?
• 중복 건과 확인되지 않은 입금은 어떻게 처리하는가?
• 전체 수수료와 지급 조건은 무엇인가?
• 업무 시간 외에 완료되지 않은 건은 누가 책임지는가?

운영상의 동작이 여러분의 제품에 맞는 경로를 고르세요. 익숙한 로고와 빠른 결제 화면은 평가의 시작일 뿐이며, 결정은 돈이 움직이는 전체 경로와 그에 따른 의무를 모두 고려해야 합니다.