결제창 띄우는 3가지 방법

핵심 요약

기본값은 redirect로 잡는 게 안전해요. 모바일 웹, 앱 내 웹뷰, SNS 인앱브라우저까지 넓게 커버할 수 있기 때문이에요. 다만 개발량이 더 많아요. redirect_url 복귀 페이지, 주문 상태 복원, receipt_id 조회/검증까지 같이 설계해야 해요.
네이버페이, 인스타그램 같은 예외 환경을 신경 쓰지 않는다면 iframe이나 popup도 충분히 괜찮아요. 특히 PC 웹에서는 개발량이 적고 UX도 무난해요.

1한 줄 정리: 기본값은 redirect가 가장 무난해요

iFrame은 개발량을 줄이기 위한 기본 제공 방식이에요. 개발량이 적고 UX도 무난해서, PC 웹 중심 서비스에서는 가장 먼저 검토하기 좋은 옵션이에요.

다만 iFrame으로 지원하지 않는 결제수단(예: 네이버페이)이 있고, 인앱브라우저(예: 인스타그램)처럼 브라우저 제약이 강한 환경에서는 redirect가 더 안정적이에요. 실무에서는 "평균적으로 예쁘게 뜨는가"보다 예외 환경에서도 실제로 승인까지 가는가가 더 중요해요. 그래서 서비스 전체에서 하나를 기본값으로 정해야 한다면 redirect가 가장 무난하고, 운영 리스크도 적어요.

반대로 말하면 네이버페이, 인스타그램 인앱브라우저 같은 예외 환경을 이번 범위에서 굳이 지원하지 않아도 된다면 iframe이나 popup으로 시작해도 괜찮아요. 이 경우에는 구현 속도와 주문서 경험을 더 우선해도 돼요.

특히 아래 조건이 하나라도 있으면 redirect 기본값이 잘 맞아요.

모바일 웹 비중이 높아요.
카카오톡·인스타그램·페이스북 같은 인앱브라우저 유입이 많아요.
카드결제 실패를 UX보다 더 크게 관리해야 해요.
결제 완료 후 서버 검증·주문 복구 플로우를 이미 설계할 수 있어요.

2창 모드(OpenType) 한눈에 보기

비교 캔버스

항목	Redirect	iFrame	Popup
화면 방식	현재 페이지가 결제창으로 이동	현재 페이지 안에 삽입	별도 팝업창 오픈
개발량	많음	적음	적음
호환성/안정성	가장 높음	낮음	보통
UI 일체감	낮음	가장 높음	중간
모바일/인앱브라우저 대응	강함	약함	약함
PC 주문서 경험	보통	좋음	보통
네이버페이 대응	가능	불가	가능
추천 포지션	기본값	PC 예외 옵션	예외 대응용

주의: 네이버페이는 iframe으로 보면 안 돼요. 네이버페이까지 받아야 하면 popup 또는 redirect로 열어야 해요.

부트페이 오픈 타입 문서의 예시도 instagram, facebook 브라우저에 대해 redirect를 지정해요. 이건 단순한 취향 문제가 아니라, 인앱브라우저에서는 iframe이나 popup이 카드결제 흐름과 충돌하기 쉬워서예요.

특히 카드결제는 본인인증, 외부 인증창, 앱 전환, 브라우저 제약이 끼는 순간 흐름이 쉽게 깨져요. 그래서 인스타그램 같은 SNS 인앱브라우저에서 카드결제가 실제로 돌아가게 하려면 redirect를 사실상 필수 전략으로 보는 게 안전해요.

정리하면 이래요.

일반 PC 웹: iframe, popup 검토 가능
일반 모바일 웹: redirect 우선
네이버페이, SNS 인앱브라우저: redirect 필수

4대신 redirect는 개발량이 더 많아요

redirect를 기본값으로 두면 끝이 아니라, 그다음부터가 구현이에요. 부트페이 문서도 redirect의 단점으로 서버 개발자 추가 개발 필요를 명시해요.

개발량이 늘어나는 이유는 보통 네 가져요.

① `redirect_url` 복귀 페이지를 따로 만들어야 해요

결제가 끝나면 PG가 redirect_url로 돌아오는데, 여기서 단순히 "결제 완료"만 띄우면 안 돼요. 복귀 페이지는 결과 수신 + 주문 상태 조회 + 최종 완료/실패 화면 분기까지 맡아야 해요.

② 복귀 데이터만 믿으면 안 돼요

공식 문서 기준으로 redirect_url로 넘어오는 데이터는 제한적이에요. 실무에서는 receipt_id와 order_id를 기준으로 다시 조회하는 쪽이 안전해요. 즉, redirect는 화면 이동 한 번으로 끝나는 방식이 아니라 복귀 후 조회/검증 단계까지 포함한 방식이에요.

③ 주문 상태 복원 로직이 필요해요

사용자가 결제 후 돌아왔을 때 브라우저 메모리만 믿으면 상태가 쉽게 꼬여요. 서버에 저장한 주문 ID 기준으로 결제 처리 중 → 승인 완료 → 실패/취소를 다시 그릴 수 있어야 해요.

④ 중복 처리와 멱등성을 같이 봐야 해요

복귀, 새로고침, 재시도, 웹훅이 겹치면 같은 주문을 여러 번 처리하려는 문제가 생길 수 있어요. 그래서 redirect를 기본값으로 둘 때는 멱등 처리까지 같이 설계해야 운영이 편해요.

즉, redirect는 결제 성공률을 높이는 대신 프론트와 서버 양쪽의 마무리 설계가 더 많이 들어가는 방식이라고 보면 돼요.

5그래도 PC 환경에서는 iframe이 꽤 괜찮아요

iFrame은 부트페이가 개발량을 줄이기 위한 기본 제공 방식으로 설명하는 옵션이에요. 현재 주문서 안에 결제창이 붙기 때문에 화면이 덜 튀고, 사용자는 페이지를 떠난다는 느낌이 적어요. 그래서 PC 웹 주문서 UX를 예쁘고 빠르게 만들고 싶을 때는 iframe이 좋은 선택이 돼요.

특히 이런 경우에 잘 맞아요.

데스크탑 중심 서비스예요.
주문서 안에서 브랜드 톤을 유지하고 싶어요.
결제수단 예외가 크지 않아요.
인앱브라우저 유입 비중이 낮아요.

다만 여기서 중요한 건 조건을 나눠 보는 거예요. PC 중심이고, 네이버페이나 인스타그램 인앱브라우저 같은 예외까지 이번에 꼭 챙길 필요가 없다면 iframe이나 popup도 충분히 현실적인 선택이에요. 반대로 모바일·인앱브라우저까지 같이 가져가면 예외가 늘어나므로 redirect 쪽이 더 안전해져요.

실무 해석은 보통 이렇게 가요.

전체 기본값: redirect
PC 웹 최적화: iframe
iframe 미지원 예외 대응: popup 또는 redirect

6popup은 언제 쓰나

popup은 iFrame으로 안 되는 결제수단을 메우는 용도로 이해하면 쉬워요. 공식 문서도 popup을 iFrame 미지원 결제수단 대응 쪽으로 설명해요. 다만 사용자가 직접 "결제 계속하기"를 눌러야 하고, 브라우저 팝업 차단 정책도 신경 써야 해요.

그래서 popup은 메인 전략보다는 아래처럼 두는 편이 나아요.

특정 PG/결제수단이 iframe에서 제약이 있어요.
redirect까지는 붙이기 어려운 짧은 대응이 필요해요.
데스크탑에서만 제한적으로 운영해요.

즉, popup은 기본값이 아니라 예외 대응 카드예요.

7추천 운영 순서

복잡하게 시작하지 말고 아래 순서로 가면 돼요.

모바일·인앱브라우저까지 넓게 커버해야 하면 기본값은 redirect로 둬요.
인스타그램 같은 SNS 인앱브라우저에서 카드결제가 중요하면 redirect를 고정해요.
PC 중심 서비스이고 네이버페이 같은 예외 지원이 당장 중요하지 않다면 iframe으로 가볍게 시작해도 돼요.
운영하면서 예외 환경 이슈가 보이면 그때 redirect 폴백을 붙여요.
redirect를 쓰기로 했다면 복귀 페이지와 서버 검증 로직을 단단하게 만들어요.

이 순서가 좋은 이유는 명확해요. 기본값을 redirect로 잡아두면 가장 까다로운 환경부터 먼저 커버할 수 있고, 그다음 PC UX 최적화는 선택적으로 붙이면 되기 때문이에요.

실제로 붙이려면

오픈 방식을 정했다면 결제창 호출 옵션은 다음 문서에서 확인해요.

결제창 오픈 모드 — /payment-window/open-type
결제창 연동 — /payment-window/integration