계획된 PSP 교체: 구독 이전과 기존 의무의 마무리

새 결제 버튼은 이미 작동합니다. 마케팅팀은 PSP 이전이 끝났다고 발표했습니다. 그런데 다음 날, 한 구매자가 지난달 주문의 환불을 요청하고, 재무팀은 이전 PSP의 마지막 정산금을 기다리고 있습니다. 이전 작업은 신규 판매에 대해서만 끝나 있었던 것입니다. 기존 의무는 여전히 옛 주소에 남아 있었습니다.

결제 대행사 마이그레이션은 여러 전환으로 이루어집니다. 신규 결제 수납, 기존 거래에 대한 서비스, 허용된 데이터의 이전, 구독 관리, 정산 종료입니다. 이것들은 각자의 완료 기준을 가진 별도 흐름으로 관리하는 편이 좋습니다. 화면을 전환하는 하루로 다섯 가지가 모두 끝나지는 않습니다.

먼저 남는 것의 지도를 그려라

트래픽을 바꾸기 전에 미결 의무에 대한 허용된 목록을 추출하세요. 완료되지 않은 거래, 가능한 환불, 분쟁, 리저브, 예정된 정산금, 구독입니다. 필요한 최소한의 필드만 쓰고 보호된 저장소에 보관하세요. 범주마다 담당자, 상태 정보의 출처, 종료 조건을 지정하세요. 세부 내역 없는 "관리자 화면 잔액" 합계로는 계약이 끝난 뒤에도 남는 의무가 무엇인지 알 수 없습니다.

제안하는 라우팅 원칙은 단순합니다. 새로운 작업은 그것이 실제로 속한 프로세스가 처리합니다. 기존 결제의 환불을 예전 식별자 그대로 새 PSP에 자동으로 보낼 수는 없습니다. 지원되는 경로를 당사자들과 확인하고, 합의된 작업에 필요한 접근 권한을 유지하세요. 기존 계약이 끝난다면 이후의 서비스 제공과 가능한 제약 사항을 별도로 합의하세요.

고객지원에서는 조회가 주문 번호에서 시작해, 해당 결제를 처리한 PSP를 보여 주어야 합니다. 구매자가 여러분의 기술적 이전 날짜를 기억해야 할 의무는 없습니다. 화면에 새 시스템만 남아 있으면 직원들은 옛 주문을 위한 별도 스프레드시트를 만들기 시작하고, 오류 위험이 하나 더 생깁니다.

데이터 이전이 곧 구독 이전은 아니다

결제 토큰, 카드 데이터, 고객 프로필, 청구 일정은 서로 다른 객체입니다. 내보낸 파일에 token 행이 있다고 해서 새 PSP에서 그것을 쓸 수 있다는 증거가 되지는 않습니다. Stripe는 자사 팀이 참여하는 결제 데이터 마이그레이션 절차를 별도로 설명합니다. Stripe 마이그레이션 개요. 가능 여부와 조건은 구체적인 결제수단과 당사자별로 확인해야 합니다.

Adyen은 정기결제 데이터를 가져온 뒤 마이그레이션 결과 파일을 제공합니다. Adyen 가져오기 절차. 운영 측면의 결론은, 이전되지 못한 레코드를 포함해 기존 식별자와 새 식별자를 잇는 검증 가능한 매핑이 필요하다는 것입니다. 프로세스에서 오류가 나지 않았다는 사실을 모든 고객이 이전되었다는 증거로 여기지 마세요.

민감한 카드 데이터는 PSP 간에 합의된 보안 절차를 통해서만, 그리고 필요한 권한을 갖춘 상태에서만 전달하세요. 공유 폴더의 일반 스프레드시트나 담당 매니저에게 보내는 이메일은 프로젝트가 급하다고 해서 허용되는 전달 수단이 되지 않습니다. 이전할 수 없는 고객을 위해서는 결제 정보를 갱신할 수 있는 이해하기 쉽고 지원되는 경로를 미리 준비하세요.

청구서 하나에는 실행자가 하나여야 한다

다음 갱신일이 15일인 30유로짜리 구독을 생각해 봅시다. 이전 기간 동안 옛 스케줄러는 아직 활성 상태이고, 새 시스템은 이미 고객과 갱신일을 받았습니다. 둘 다 각자의 지시를 올바르게 수행해 청구 두 건을 만들 수 있습니다. 각 PSP 내부의 멱등성은 서로 독립된 시스템 사이의 이런 충돌을 해결하지 못합니다.

새 일정을 활성화하기 전에 특정 청구 기간을 어느 시스템이 소유하는지 확정하세요. 마지막으로 결제된 기간, 다음 청구서, 무료 체험 기간, 할인, 예정된 변경 사항을 대조하세요. 그런 다음 옛 시스템이 같은 기간에 대해 더 이상 청구를 시작할 권한이 없는지 확인하세요. 전환 순서는 제품에 따라 다르며, 인위적 데이터로 미리 시험해 보아야 합니다.

리허설에서는 데이터 추출과 전환 사이에 고객의 해지를 끼워 넣으세요. 월요일의 데이터 스냅숏에는 화요일에 내려진 결정이 반영되지 않습니다. 변경분을 옮기는 프로세스나 제품상 허용되는 제한된 동결 기간이 필요합니다. 내부 설정을 동결하더라도 구매자가 정당하게 서비스를 해지할 수단을 빼앗아서는 안 됩니다.

그룹 단위로 이전을 검증하라

합의된 제한적 세그먼트와 확대 기준으로 시작하세요. 정확한 금액, 예상한 상태값, 원활한 고객지원, 맞아떨어지는 대사가 기준입니다. 신규 고객과 기존 결제 고객은 따로 평가하세요. 거절 사유와 필요한 조치가 다를 수 있습니다. 순서는 테스트 카드 한 장의 편의가 아니라 실제 비즈니스 모델에 맞춰 정하세요.

그룹마다 원래 구성원 명단을 보관하세요. 그래야 새 시스템에 없는 고객이 눈에 띄고, 전환율 비교에 서로 다른 구매자가 섞이지 않습니다. 롤백에도 규칙이 필요합니다. 어떤 신규 거래를 옛 경로로 되돌릴 수 있고, 어떤 거래는 시작된 곳에서 끝나야 할까요? 이미 처리된 결제는 사이트 버전을 되돌리는 것만으로 취소할 수 없습니다.

이전은 신규 판매가 작동하고, 기존 의무가 합의된 프로세스로 처리되며, 모든 잔액이 설명되고, 의존성이 정리된 뒤 불필요한 접근 권한이 회수되었을 때 완료됩니다. 마지막 항목은 검증된 목록에 따라 수행해야 합니다. 그렇지 않으면 옛 계정 비용을 아끼려다 다음 환불 요청에 답할 수 없게 됩니다.