한 줄 판단
PG 하나만 쓸 계획이고 앞으로 바꿀 일도 없다면 직접 연동해도 돼요. 하지만 낮은 수수료로 시작하고, 빠르게 붙이고, 나중에 결제 상품과 PG를 바꿀 선택지까지 남기고 싶다면 Bootpay를 먼저 검토할 만해요.
핵심 요약
- PG 직접 연동은 특정 PG 하나의 결제창을 띄울 때는 단순해요.
- 하지만 수수료, 정산 조건, 기능 조건이 안 맞으면 나중에 옮기는 비용이 커질 수 있어요.
- Bootpay는 카드 일반 기준 수수료 2.9%를 기준으로 검토할 수 있어 초기 부담이 작이에요.
- SDK, 예제, MCP, 관리자 화면이 있어 결제 요청부터 서버 검증, 웹훅까지 빠르게 테스트할 수 있어요.
- Bootpay 위에서는 링크페이, 결제위젯, 자동결제, 예약결제, 브랜드페이, 커머스 API까지 넓혀갈 수 있어요.
- 특정 PG의 정산 조건이나 수수료 조건이 안 맞으면 다른 PG를 추가하거나 변경할 수 있어요.
- 거래액이 커져 다른 PG에서 더 낮은 수수료 제안이 와도, Bootpay 연동 구조를 유지한 채 조건을 바꾸는 선택지가 있어요.
수수료와 정산 조건은 업종, PG사, 심사 결과, 계약 시점에 따라 달라질 수 있어요. 실제 오픈 전에는 최종 계약 조건을 기준으로 확인해야 해요.
이런 상황이라면
스타트업 A팀은 결제를 붙이려고 해요. 개발자는 “그냥 특정 PG SDK를 직접 붙이면 되는 것 아닌가요?”라고 말해요. 맞는 말이에요. 단건 결제만 보면 PG 직접 연동도 가능해요.
그런데 팀은 결제창만 보면 안 돼요. 수수료가 낮은지, 추가 비용은 없는지, 서버 검증과 웹훅까지 안전하게 붙일 수 있는지 봐야 해요. 운영 중 정산 조건이 안 맞으면 다른 PG로 바꿀 수 있는지도 봐야 해요.
지금은 단건 결제만 필요해도 나중에는 결제 링크, 결제위젯, 자동결제, 브랜드페이가 필요할 수 있어요. 거래액이 커진 뒤 다른 PG에서 더 낮은 수수료를 제안하면 그 조건도 비교할 수 있어야 해요.
이 글은 “PG 직접 연동하면 되는데 왜 Bootpay를 쓰나?”라는 질문에 5가지 기준으로 답해요.
1결제 수수료 부담이 작이에요
결제 수수료는 바로 마진에 영향을 줘요. 연회비나 부가 비용이 붙으면 매출이 작은 팀에게 더 부담이 돼요.
처음에는 두 가지만 보면 돼요.
- 카드 일반 기준 수수료가 얼마인지
- 별도 연회비나 추가 수수료가 있는지
Bootpay는 카드 일반 기준 수수료 2.9%를 기준으로 검토할 수 있어요. 별도 추가 비용 없이 시작할 수 있는 구조라 초기 팀이 부담 없이 결제를 붙여보기 좋아요.
PG를 직접 계약하면 보통 그 PG가 제시하는 조건 안에서 판단해야 해요. Bootpay는 여러 PG와 연결되어 있기 때문에, 신규 가맹점은 더 낮은 수수료 조건을 제안받을 수 있어요.
핵심은 단순해요. 처음부터 큰 계약이나 복잡한 조건을 전제로 잡기보다, 낮은 비용으로 결제를 열고 실제 운영 비용을 확인하는 편이 현실적이에요.
더 보기: PG 수수료
2결제 연동을 빠르게 시작할 수 있어요
PG 직접 연동도 빨라요. 문서를 보고 SDK를 붙이면 결제창은 열 수 있어요.
하지만 실제 서비스에서는 결제창을 여는 것만으로 끝나지 않아요. 최소한 아래 흐름까지 붙어야 해요.
- 프론트에서 결제 요청을 만들어요.
- 서버에서 결제 금액과 상태를 검증해요.
- 주문 상태를 저장해요.
- 웹훅으로 결제 완료, 취소, 입금 같은 상태 변화를 받아요.
이 흐름이 닫혀야 “결제는 됐는데 주문은 안 잡히는 문제”를 줄일 수 있어요.
Bootpay는 SDK, 예제, 개발자 문서가 있어 이 흐름을 빠르게 확인할 수 있어요. MCP를 붙이면 AI 코딩 도구가 Bootpay 문서와 예제를 찾아보고, 현재 프로젝트 구조에 맞는 연동 초안도 만들 수 있어요.
관리자 화면도 같이 쓸 수 있어요. PG 활성화, 결제수단 설정, 연동키 확인, 웹훅 설정 같은 작업을 문서와 관리자 화면을 보면서 처리할 수 있어요. 처음 붙이는 팀이 “키는 어디서 찾지?”, “웹훅은 어디에 넣지?”, “서버 검증은 어디까지 해야 하지?”에서 헤매는 시간을 줄일 수 있어요.
실제로 붙이려면: 결제 연동 시작하기 · AI 연동 가이드 · 결제 검증 · 웹훅
3PG 하나보다 결제 상품 선택지가 넓어요
특정 PG를 직접 연동하면 그 PG가 제공하는 기능을 기준으로 설계하게 돼요. 처음에는 단건 결제만 필요하니 문제가 없어 보여요. 하지만 서비스가 커지면 필요한 결제 방식이 늘어나요.
예를 들어 이런 상황이 생겨요.
- 상담 결제나 예약금은 결제 링크로 받아야 해요.
- 쇼핑몰 주문서 안에 결제수단 선택 UI를 넣고 싶어요.
- 구독형 서비스라서 자동결제가 필요해요.
- 재구매가 많은 서비스라서 자체 간편결제가 필요해요.
- 결제 이후 상품, 고객, 주문, 구독 관리까지 묶고 싶어요.
Bootpay는 PG 위에서 이런 결제 상품을 제공해요. 그래서 특정 PG 하나의 부가 기능만 보는 것이 아니라, Bootpay 흐름 안에서 필요한 상품을 단계적으로 고를 수 있어요.
| 상품 | 쓰는 상황 | 핵심 |
|---|---|---|
| 결제창 | 빠르게 단건 결제를 붙일 때 | SDK로 결제창을 열고 서버에서 검증해요 |
| 링크페이 | 개발 없이 결제 링크를 보내야 할 때 | 상담 결제, 예약금, 주문 변경 결제에 유용하예요 |
| 결제위젯 | 주문서 안에서 결제수단 선택 UI를 보여줄 때 | 결제 UX와 운영 설정을 함께 관리해요 |
| 자동결제 | 매월 과금, 크레딧 자동 충전, 멤버십을 운영할 때 | 빌링키로 반복 결제를 처리해요 |
| 예약결제 | 특정 시점에 결제를 걸어둬야 할 때 | 예약, 후불, 일정 기반 과금에 맞아요 |
| 브랜드페이 | 회원의 재결제 경험을 줄이고 싶을 때 | 저장된 결제수단으로 자체 간편결제를 만들어요 |
| 커머스 API | 상품·고객·주문·구독까지 관리해야 할 때 | 결제 이후 커머스 운영으로 확장해요 |
단, 모든 상품이 모든 PG에서 항상 같은 수준으로 동작하는 것은 아니에요. Bootpay는 가능한 많은 PG를 같은 흐름으로 묶는 방향을 지향하지만, PG사별 API 범위와 기술적 제약 때문에 일부 기능은 특정 PG나 결제수단에서 제한될 수 있어요. 도입 전에는 우리 PG와 결제수단 조합에서 필요한 기능이 지원되는지 확인해야 해요.
더 보기: 결제위젯 도입 · 브랜드페이 도입 · 링크페이 도입 · 부트페이 커머스
4조건이 안 맞으면 PG를 추가하거나 변경할 수 있어요
PG 직접 연동의 가장 큰 리스크는 처음 고른 PG 조건이 계속 맞을 거라고 생각하는 거예요. 하지만 실제 운영을 해보면 조건이 안 맞는 경우가 생겨요.
특히 정산 조건은 오픈 전에는 잘 보이지 않아요. 처음 제안받을 때는 좋아 보여도, 거래액이 커진 뒤에 보증보험 한도, 담보액, 정산 보류 조건이 문제가 될 수 있어요.
예를 들어 월 거래액이 보증보험 담보액을 넘으면 초과분 정산이 묶일 수 있어요. 정산 한도를 올리기 위해 추가 담보를 요구받을 수도 있어요. 실제로 월 거래액이 몇 억 원 단위로 커진 뒤, 담보 한도 때문에 정산금 일부가 계속 묶이는 사례도 생겨요.
이런 조건은 오픈 전 검토표에서는 잘 보이지 않아요. 실제 운영 중 정산이 묶이고 나서야 “이 조건은 우리 서비스에 안 맞아요”는 걸 알게 되는 경우가 많아요.
담보, 보증보험, 정산 보류, 정산 주기는 Bootpay가 직접 정하는 조건이 아니에요. 실제 계약되는 PG사의 정산 조건이에요. 그래서 처음부터 특정 PG에 너무 강하게 묶이지 않는 구조가 중요해요.
Bootpay로 연동해두면 서비스 코드를 처음부터 다시 짜지 않고, 같은 결제 흐름 안에서 PG를 추가하거나 변경할 수 있어요. 조건이 안 맞으면 바꿀 수 있어야 해요.
더 보기: 보증보험과 정산
5거래액이 커진 뒤에도 가격 협상 선택지를 남겨요
처음에는 Bootpay의 제안 조건으로 시작해도 돼요. 하지만 거래액이 커지면 상황이 달라져요.
월 거래액이 커지면 다른 PG사에서 더 낮은 수수료를 제안할 수 있어요. 기존 PG가 조건을 다시 제안하는 경우도 있어요.
이때 결제 연동이 특정 PG에 강하게 묶여 있으면 낮은 수수료 제안을 받아도 옮기기 어려워요. 결제 요청 코드, 서버 검증, 웹훅, 관리자 운영 흐름을 다시 맞춰야 하기 때문이에요.
Bootpay는 이런 상황에서 API 이용 비용만 내고 Bootpay 연동 구조를 유지하는 선택지도 제공해요. 가맹점은 더 유리한 PG 수수료 조건을 검토하면서도, 기존에 만들어둔 결제 요청, 서버 검증, 웹훅, 관리자 운영 흐름을 최대한 유지할 수 있어요.
Bootpay 입장에서도 가맹점이 완전히 이탈하는 것보다 API 이용료를 내고 계속 Bootpay 인프라를 쓰는 편이 나아요. 그래서 이 구조는 가맹점과 Bootpay 모두에게 현실적인 선택지가 돼요.
핵심은 처음 선택이 마지막 선택이 아니어야 한다는 점이에요. 초기에는 빠르게 열고, 거래액이 커진 뒤에는 더 좋은 수수료 조건을 비교하고, 필요하면 PG 조건만 바꾸는 식으로 운영할 수 있어야 해요.
그래서 왜 Bootpay를 쓰나
직접 PG 연동이 맞는 경우도 있어요. 사용할 PG가 이미 확정되어 있고, 정산 조건도 충분히 검토했고, 단건 결제 외 확장 계획이 거의 없다면 직접 연동이 더 단순할 수 있어요.
반대로 아래 중 하나라도 해당하면 Bootpay를 검토할 이유가 있어요.
- 초기 수수료와 비용 부담을 낮게 시작하고 싶어요.
- AI와 MCP로 결제 연동 초안을 빠르게 만들고 싶어요.
- 결제위젯, 링크페이, 자동결제, 브랜드페이처럼 이후 상품 확장 가능성이 있어요.
- 운영 중 PG 정산 조건이 안 맞을 때 다른 PG로 바꿀 수 있어야 해요.
- 거래액이 커진 뒤 더 좋은 PG 수수료 제안을 받을 가능성이 있어요.
- 결제 API에서 커머스 API로 넓혀갈 가능성이 있어요.
실제로 붙이려면
도입 판단이 끝났다면 개발자 문서에서 최소 결제 흐름부터 확인해요.
- 시작하기 — developers.bootpay.ai/guide/intro
- 환경 설정 — developers.bootpay.ai/guide/setup
- 연동키 발급 — developers.bootpay.ai/guide/keys
- 결제 흐름 — developers.bootpay.ai/guide/payment-flow