PSP를 고르고 있나요? 최악의 금요일과 마지막 영업일을 보여 달라고 하세요

멋진 데모는 결제가 성공하는 장면을 보여 줍니다. PG사 선정에는 다른 장면이 더 유용합니다. 금요일, 응답이 사라지고, 환불이 멈췄고, 담당자는 휴가 중입니다. 계약을 끝내기로 한 날을 미리 짚어 보는 것은 더 유용합니다. 두 가지 점검은 긴 기능 목록보다 파트너 의존의 대가를 더 잘 보여 줍니다.

일반적인 SLA 대신 구체적인 하루를 짚어 달라고 하라

가상 시나리오입니다. 금요일에 40유로짜리 결제 500건, 총 20 000유로를 받았습니다. 저녁에 알림 일부가 지연됐고, 월요일 아침에는 환불 요청이 들어왔습니다. 후보 업체에 운영자, 개발자, 회계 담당자가 각각 무엇을 보게 되는지 보여 달라고 하세요.

어떤 이벤트가 재전송됩니까? API 응답이 사라졌을 때 거래를 어떻게 찾습니까? 실패한 지급은 어디에서 보입니까? 야간에는 누가 응대하며, 문의에 어떤 데이터가 필요합니까? 좋은 미팅의 결과물은 "고객지원이 항상 도와드립니다"라는 약속이 아니라 리포트 예시, 문서, 합의된 연락처입니다.

테스트 기록은 직접 관리하세요. 시나리오마다 기대 동작, 실제 결과, 확인 날짜, 미해결 질문을 적습니다. 성공 결제와 함께 거절, 재요청, 환불, 고객의 페이지 이탈도 점검하세요. 파일럿은 제공사와 합의해야 하며 제품의 허용된 사용 범위에 맞아야 합니다.

첫 번째 필터: 우리 사업을 정말 받아 주는가?

후보들에게 같은 설명을 보내세요. 법인, 실제 제품, 고객 국가, 통화, 평균 객단가, 예상 거래액, 이행 기간, 환불 절차입니다. P2P 플랫폼이라면 누가 판매자이고 누가 구매자인지, 받는 자금이 누구의 것인지 따로 밝히세요. 설명을 "온라인 서비스" 같은 모호한 표현으로 대신하지 마세요.

사업 모델이 허용되는지 서면 확인을 요청하세요. 누가 계약 당사자가 되는지, 각 서비스가 어느 법인을 통해 제공되는지, 그 법인이 제공사 계좌상의 지급 수취인과 같은지 확인하세요. "그런 건 연동해 드려요"라는 구두 답변만으로는 출시를 계획하기에 부족합니다.

인허가 확인 방법은 국가마다 다릅니다. 예를 들어 영국에서는 FCA가 확인하라고 권고합니다. 회사 이름뿐 아니라 필요한 서비스에 대한 인가도 보라는 것입니다. 이는 현지 절차의 한 예일 뿐, 한 나라에서 등록했다고 다른 어느 나라에서나 영업할 권리가 생긴다는 확인이 아닙니다.

모든 차감 후 남는 돈을 보여 달라고 하라

가상의 계산을 이어 가겠습니다. 거래액 20 000유로에서 수수료는 400유로, 새 리저브 유보는 1 000유로, 환불은 600유로입니다. 다른 움직임이 없다면 지급액은 18 000유로가 됩니다. 여기서 수수료는 2%이지만 즉시 지급액의 감소는 10%입니다. 서로 다른 지표이며, 모든 숫자는 예시를 위해 고른 것입니다.

후보 업체에 각 차감 항목의 산정 기준, 자금 사용 가능일, 지급 일정을 따로 알려 달라고 하세요. 위 예시에 대해 일정표를 요청하세요. 어느 날 얼마가 은행에 들어오고, 무엇이 유보로 남으며, 어떤 조건을 더 충족해야 하는지입니다. 합의한 기한 안에 들어오지 않은 지급은 누가 확인하는지도 물어보세요.

다섯 가지 요구 사항, 각각 증빙과 함께

최종 후보들을 위해 짧은 점검 카드를 준비하세요. 요구 사항 옆에 기대하는 산출물을 적습니다. 자금 대사에는 식별자가 포함된 비식별 리포트가 필요합니다. 오류 후 복구에는 문서와 테스트 결과가 필요합니다. 고객지원에는 확인된 채널과 에스컬레이션 절차가 필요합니다. 접근 관리에는 역할 점검이 필요합니다. 이탈 가능성에는 문서화된 절차와 명확한 내보내기 형식이 필요합니다.

답변마다 세 가지 상태 중 하나를 표시하세요. 확인됨, 약속됨, 미검증입니다. 멋진 프레젠테이션 뒤에 영업 담당자의 약속을 기술적 사실로 바꾸지 마세요. 후보가 아직 기능을 보여 주지 못한다면, 그 의존성과 함께 기능 부재가 출시를 막는 조건이 되는 시점을 적어 두세요. 그러면 모든 질문이 해결됐다는 착각 없이 대화를 이어 갈 수 있습니다.

절충은 보통 단일 서비스의 편리함과 그에 대한 의존 비용 사이에서 이루어집니다. 하나의 대시보드는 팀이 다룰 화면 수를 줄여 주지만, 그 대시보드 없이도 이력을 복원할 수 있는지 확인해야 합니다. 여러 제공사를 쓰면 선택지가 생기지만 대사, 고객지원, 서로 다른 상태 규칙이 늘어납니다. 두 번째 연동이 있다고 해서 바로 쓸 수 있는 예비 프로세스가 생기는 것은 아닙니다.

접근 권한과 카드 데이터: 별도의 점검

카드 데이터에 대한 책임 분담 설명을 요청하세요. PCI SSC는 처리를 외부 업체에 맡겨도 가맹점의 모든 의무가 사라지지는 않는다고 강조합니다. 인증서나 로고가 우리 연동의 경계를 이해하는 일을 대신하지는 못합니다.

연동에 꼭 필요한 권한만 줄 수 있는지도 확인하세요. Stripe는 제한된 API 키를 권장합니다. 특정 작업에 맞춘 권한입니다. 후보 업체에도 비슷한 권한 분리를 시연해 달라고 하세요. 거래 조회 권한과 지급 계좌 정보 변경 권한을 독립적으로 나눌 수 있는지도 포함합니다.

계약 전에 이탈을 미리 연습하라

가상의 주문 열 건을 고르세요. 성공한 주문, 부분 환불된 주문, 분쟁이 진행 중인 주문, 지급 대기 중인 주문입니다. 신규 판매를 중단한 뒤에도 어떤 기록에 접근할 수 있는지, 누가 환불을 마무리할 수 있는지, 거래 이력을 어떻게 받을 수 있는지 보여 달라고 하세요. 결제 데이터와 토큰의 이전은 따로 다루세요. 당사자들의 확인과 허용된 안전한 절차 없이 이전이 가능하다고 가정하지 마세요.

그다음 팀의 업무량을 평가하세요. 예외 거래 하나에 수동 다운로드 세 번과 메일로 하는 대사가 필요하다면 이를 비교에 포함하세요. 문의 100건에 4분씩 더 걸린다면, 거래당 요율이 더 낮더라도 400분의 작업이 생깁니다. 이는 업무 부담 계산이지 특정 공급업체의 품질 예측이 아닙니다.

선정 결정에서는 남은 리스크마다 담당자를 지정하세요. "출시 후에 정리하자"는 말은 구체적인 조건으로 바뀌어야 합니다. 무엇을, 어떤 거래 전까지, 누가 더 확인하는지입니다. 그렇지 않으면 미해결 질문은 프레젠테이션에서는 사라지지만 첫 야간 고객지원 대기열에 다시 나타납니다.

거짓 정밀함 없이 결정하는 법

요구 사항을 필수와 선택으로 나누세요. 허용되지 않는 사업 모델, 불분명한 계약 당사자, 자금 대사의 불가능은 편리한 화면으로 상쇄되지 않습니다. 필수 필터를 통과한 후보끼리는 총비용과 같은 테스트 묶음의 결과로 비교하세요.

선정의 최종 결과물은 출시 조건이 붙은 결정입니다. 선택한 후보, 확인된 제약, 미해결 질문, 그것이 해결되기 전에는 시작하면 안 되는 작업을 적으세요. 제품과 지역에 대한 처음의 전제도 보관하세요. 전제가 바뀌면 적합성 점검을 다시 해야 합니다.

파일럿이 성공했고 인허가를 확인했다고 해서 조건이나 제약이 절대 바뀌지 않는다는 보장은 없습니다.