PayPal JavaScript SDK v6 마이그레이션 2026: Safari 결제 검수

PayPal v5에서 v6로 바꿀 때 가장 위험한 오판은 화면에 결제 버튼이 나타난 것을 이전 완료로 기록하는 것입니다. 실제로는 상품 상세, 장바구니, 결제 화면, 별도 결제 입구마다 다른 초기화 코드나 SDK 주소가 남아 있을 수 있습니다.

PayPal은 v5에서 v6으로 옮길 때 설정 방식과 이전 절차를 별도 문서로 안내합니다. 공식 v5에서 v6 이전 안내와 현재 SDK 설정 문서를 대조해 다음 항목을 기록합니다.

• 페이지별로 실제 불러오는 SDK 주소
• 초기화 시점과 중복 실행 여부
• 사용 중인 클라이언트 자격 증명
• 콘텐츠 보안 정책과 허용된 외부 연결
• 정상 결제의 기존 결과와 되돌림 조건
• 수정 담당자와 승인 담당자

PayPal JavaScript SDK v5를 반드시 v6으로 바꿔야 합니까?
공식 자료가 v6 설정과 이전 절차를 제공한다는 사실만으로 v5 전체가 즉시 중단됐다고 판단하면 안 됩니다. 통합 방식, 지원 범위, 수명 주기는 배포 시점의 공식 문서를 확인해야 합니다. 다만 새 결제 구성이나 유지보수를 진행한다면 v6 기준으로 별도 검수하고, 기존 v5 경로는 명확한 회귀 기준으로 보존하는 편이 안전합니다.

1단계: 샌드박스에서 기준 화면을 만듭니다

같은 상품, 통화, 언어, 배송 조건으로 결제 화면을 열어 정상 기준을 만듭니다. 첫 방문만 보지 말고 새로 고침, 장바구니에서 돌아오기, 결제 화면을 다시 열기까지 반복합니다.

Safari Web Inspector에서 스크립트, 네트워크 요청, 콘솔 오류를 저장합니다. Apple의 Safari 개발자 기능 활성화 안내를 참고해 개발 메뉴와 검사기를 준비합니다.

2단계: 표시되지 않을 때 원인을 층위별로 분리합니다

PayPal v6 버튼이 Safari에서 표시되지 않으면 어떻게 합니까?
먼저 네트워크 탭에서 SDK 요청이 성공했는지 확인합니다. 요청 자체가 없으면 태그 조건이나 초기화 시점을 봅니다. 요청은 있지만 렌더링이 없으면 콘솔 오류, 자격 증명, 콘텐츠 보안 정책, 중복 초기화를 확인합니다. 미국 구매자에게 보이는 결제 방식은 지역, 계정, 기기 조건에 따라 개인화될 수 있으므로 실제 표시 항목만 기록해야 합니다.

다음 체크리스트를 페이지마다 작성합니다.

• [ ] 상품 상세의 SDK가 v6 설정과 일치합니다.
• [ ] 장바구니에서 결제 화면으로 이동해 버튼이 한 번만 생성됩니다.
• [ ] 새로 고침 뒤 중복 버튼이나 중복 요청이 생기지 않습니다.
• [ ] 콘솔 오류와 실패한 네트워크 요청을 저장했습니다.
• [ ] 콘텐츠 보안 정책이 필요한 연결을 막지 않습니다.
• [ ] 지역별 결제 방식의 차이를 고정 요구사항으로 기록하지 않았습니다.

버튼 문제를 다른 브라우저에서만 확인하고 끝내면 안 됩니다. 다른 브라우저의 성공은 비교 자료일 뿐 Safari 승인 증거가 아닙니다.

Safari 결제는 버튼보다 로그인 창에서 변수가 많이 생깁니다. 팝업이 열리는 경우, Safari가 차단하는 경우, 구매자가 창을 닫는 경우, 로그인 중단 뒤 쇼핑몰로 돌아오는 경우를 각각 기록합니다.

Apple의 Safari 팝업 차단 설정 안내에 따라 팝업 상태를 확인합니다. 웹사이트 데이터, 교차 사이트 추적 설정, 확장 프로그램, 로그인 세션을 한꺼번에 바꾸지 않습니다. 동일한 테스트 계정에서 한 번에 하나의 변수만 변경해야 원인을 좁힐 수 있습니다.

주의: Safari의 개인정보 보호 기능을 장기간 해제해야만 결제가 완료된다면 통과로 처리하지 않습니다. 구매자에게 같은 설정 변경을 요구하는 구조인지 기술 담당자가 다시 확인해야 합니다. Safari 개인정보 보호 설정 설명도 함께 검토합니다.

PayPal 로그인 창과 결제 취소 흐름은 어떻게 테스트합니까?
정상 로그인 후 결제 승인, 로그인 창을 구매자가 직접 닫는 경우, 팝업 차단, 로그인 세션 만료를 차례로 실행합니다. 각 경우에 쇼핑몰 화면이 멈추지 않고 재시도나 다른 결제 수단을 안내하는지 확인합니다. 성공 화면으로 자동 이동하는 것만 기록하면 부족합니다.

샌드박스 구매자 계정으로 승인과 취소를 각각 실행합니다. 승인 뒤에는 주문 식별자, 서버 응답, 화면 결과를 한 기록에 연결합니다. 취소 뒤에는 장바구니가 비워졌는지, 주문이 생성되지 않았는지, 다시 결제할 수 있는지 확인합니다.

PayPal의 고급 자바스크립트 연동 안내는 클라이언트 흐름과 서버 처리를 함께 다룹니다. 운영 담당자는 화면의 문구를 확인하고, 기술 담당자는 승인과 포착 요청의 순서를 확인해야 합니다.

• [ ] 승인 후 성공 화면이 표시됩니다.
• [ ] 구매자 취소 후 명확한 취소 상태가 표시됩니다.
• [ ] 뒤로 가기나 새로 고침으로 중복 제출되지 않습니다.
• [ ] 결제 실패 뒤 재시도 경로가 작동합니다.
• [ ] 승인되지 않은 상태가 성공 주문으로 기록되지 않습니다.
• [ ] 화면 결과와 서버 응답의 주문 식별자가 일치합니다.

PayPal 샌드박스 결제는 성공했는데 왜 쇼핑몰 주문이 없습니까?
브라우저의 성공 화면과 서버의 주문 포착은 별개일 수 있습니다. 주문 생성, 구매자 승인, 서버 포착 사이에서 서버 오류가 발생하면 구매자는 성공처럼 보았지만 독립 쇼핑몰에는 주문이 없을 수 있습니다.

운영자는 쇼핑몰 주문 목록과 PayPal 샌드박스 활동 기록을 대조합니다. 기술 담당자는 승인 전후의 서버 응답, 포착 실패, 중복 요청, 결제 수단 거절을 확인합니다. 오류 코드는 추측하지 말고 PayPal 공식 오류 개요에 맞춰 기록합니다.

부정 결제나 실제 구매자 정보를 이용한 실험은 하지 않습니다. 취소, 거절, 서버 장애, 중복 작업은 공식 샌드박스 도구와 테스트 자료로만 재현합니다. 최종 이행 판단은 브라우저 이동이 아니라 서버가 확인한 상태를 기준으로 해야 합니다.

원격 Mac은 실제 Safari 화면, macOS 웹 호환성, 미국 노드에서의 구매자 진입 경로를 확인하는 데 사용할 수 있습니다. 그러나 원격 Mac이나 미국 IP가 결제 정책을 우회하거나 거래 성공, 계정 심사 통과를 보장하지는 않습니다.

미국 구매자용 랜딩 페이지에서 주력 상품, 통화, 언어, 배송 조건을 고정합니다. 같은 테스트 스크립트를 Safari에서 실행하고, 민감 정보가 보이지 않도록 화면을 가린 뒤 시각, 브라우저 버전, 주문 결과, 오류 화면을 남깁니다. PayPal 브라우저 지원 기준은 배포 전 지원 범위를 확인하는 기준으로 사용합니다.

팀에 반복 사용 가능한 macOS 환경이 없다면 미국 노드 원격 Mac 선택 기준을 먼저 확인할 수 있습니다. 결제 검수용 환경과 실제 운영 계정용 환경은 권한과 테스트 데이터를 분리해야 합니다.

최종 승인 체크

• [ ] 상품, 장바구니, 결제 화면의 실제 SDK 주소를 확인했습니다.
• [ ] 첫 방문과 재진입에서 중복 초기화를 확인했습니다.
• [ ] Safari 팝업 차단과 세션 변수를 따로 재현했습니다.
• [ ] 승인, 취소, 로그인 중단, 결제 거절을 샌드박스에서 실행했습니다.
• [ ] 서버 포착 상태와 쇼핑몰 주문을 연결했습니다.
• [ ] 오류 뒤 재시도 또는 대체 결제 안내를 확인했습니다.
• [ ] 미국 구매자용 Safari에서 같은 스크립트를 다시 실행했습니다.
• [ ] 탈취 화면, 실행 시각, 브라우저 버전, 주문 결과를 보관했습니다.
• [ ] 문제가 생기면 기존 연동으로 되돌릴 담당자와 조건을 정했습니다.

버튼만 표시된 상태와 서버 주문까지 완료된 상태를 같은 성공으로 취급하는 현재 방식은 세 가지 약점이 있습니다. Safari 팝업과 세션 차이를 놓치기 쉽고, 브라우저 성공 화면을 실제 주문 포착으로 오해할 수 있으며, 팀원이 각자 다른 기기와 설정으로 테스트해 증거가 재현되지 않습니다. MESHLAUNCH의 원격 Mac은 이런 검수를 반복할 고정 macOS 환경이 필요할 때 대안이 될 수 있습니다. 단기 환경으로 먼저 결제 행렬을 실행한 뒤, 원격 Mac 대여 전 검수 기준을 확인하고 장기 운영 환경이 정말 필요한지 결정하는 순서가 적절합니다.

이번 주 배포를 승인하기 어렵다면 먼저 샌드박스에서 다섯 결제 장면의 증거를 완성하고, Safari 재검수에서 실패한 항목만 기술 담당자에게 넘기십시오. 안정적인 실제 Mac 환경이 없는 팀은 짧은 기간의 MESHLAUNCH 환경으로 회귀 테스트를 끝낸 뒤 소규모 공개와 전체 배포 중 하나를 선택하는 편이 안전합니다.