웹에서 Apple Pay를 붙일 때 알아야 할 구현 흐름
웹사이트에 Apple Pay를 붙이면 모바일 Safari 사용자에게 훨씬 빠른 결제 경험을 제공할 수 있습니다. 다만 버튼 하나만 추가한다고 끝나는 기능은 아닙니다. 도메인 검증, 결제 세션 생성, 결제 토큰 승인, PG 연동까지 함께 설계해야 합니다.
가장 현실적인 선택: PG/PSP 연동
대부분의 서비스는 Stripe, Adyen, Toss Payments 같은 결제 대행사나 PSP가 제공하는 Apple Pay 기능을 쓰는 것이 가장 안전합니다.
이 방식의 장점은 다음과 같습니다.
- Apple Pay 도메인 검증 절차를 안내받을 수 있다.
- Merchant Validation과 결제 토큰 처리를 PG가 상당 부분 대신한다.
- 카드 승인, 취소, 정산, 영수증 등 운영 기능과 연결하기 쉽다.
- PCI 책임 범위를 줄일 수 있다.
직접 구현은 가능하지만 결제 보안과 운영 책임이 커지므로 특별한 이유가 없다면 PG 방식을 먼저 검토하는 것이 좋습니다.
Apple Pay on the Web의 기본 조건
웹에서 Apple Pay를 사용하려면 보통 다음 조건이 필요합니다.
- Apple Developer Program 계정
- Apple Pay Merchant ID
- HTTPS가 적용된 결제 도메인
- Apple Pay 도메인 검증 파일
- Apple Pay JS를 지원하는 브라우저와 기기
- 실제 결제를 승인할 PG/PSP 또는 자체 결제 서버
프론트엔드 흐름
프론트엔드에서는 먼저 Apple Pay 사용 가능 여부를 확인합니다.
const canUseApplePay =
typeof window !== 'undefined' &&
'ApplePaySession' in window &&
ApplePaySession.canMakePayments();사용 가능한 경우에만 Apple Pay 버튼을 노출합니다. 버튼은 Apple의 Human Interface Guidelines를 따르는 것이 좋습니다.
결제 요청에는 국가, 통화, 지원 카드 네트워크, 총액 등을 담습니다.
const paymentRequest = {
countryCode: 'KR',
currencyCode: 'KRW',
merchantCapabilities: ['supports3DS'],
supportedNetworks: ['visa', 'masterCard', 'amex'],
total: { label: '상점명', amount: '10000' },
};서버에서 반드시 해야 할 일
결제 금액과 주문 상태는 서버가 기준이 되어야 합니다. 클라이언트가 보낸 금액만 믿으면 위변조 위험이 있습니다.
서버는 보통 다음을 담당합니다.
- 주문 생성 및 금액 확정
- Apple Merchant Validation 처리
- Apple Pay 결제 토큰을 PG에 전달
- 승인 결과 검증
- 주문 상태 확정
직접 구현 시 주의점
직접 Apple Pay JS를 구현하면 onvalidatemerchant, onpaymentauthorized 같은 이벤트를 다뤄야 합니다. 특히 Merchant Identity Certificate 보관, validation URL 호출, 결제 토큰 처리 방식이 중요합니다.
이 영역은 보안 책임이 크기 때문에 인증서와 키는 서버에서 안전하게 관리해야 하며, 클라이언트에 노출되어서는 안 됩니다.
적용 순서
- 사용하는 PG가 Apple Pay on the Web을 지원하는지 확인
- Apple Developer Merchant ID와 도메인 검증 준비
- PG 관리자에서 Apple Pay 활성화
- 프론트엔드에 Apple Pay 버튼 추가
- 서버에서 주문 생성과 승인 검증 구현
- 실제 기기 Safari에서 테스트
듀오랩스가 보는 관점
Apple Pay는 결제 전환율을 높이는 좋은 기능이지만, 결제는 UX보다 안전한 운영 설계가 먼저입니다. 고객 입장에서는 “빠른 결제”만 보이지만, 개발 측면에서는 주문 상태, 금액 검증, 승인 실패 처리, 환불 흐름까지 함께 설계해야 안정적인 서비스가 됩니다.
우리 서비스에 적용할 계획이 있으신가요?
홈페이지·웹서비스 개발 살펴보기 →함께 읽기
- Polar.sh와 토스페이먼츠는 무엇이 다를까: 웹 결제 서비스 선택 기준Polar.sh와 토스페이먼츠는 모두 웹사이트에 결제를 붙일 때 검토할 수 있는 서비스입니다. 하지만 둘은 같은 종류의 결제대행사가 아닙니다.
- 그래프 DB가 RDB를 대체할까? 숫자로 본 2026년 데이터베이스 흐름데이터베이스 순위 사이트 DB-Engines에는 데이터 모델별 인기 추이를 그린 그래프가 있습니다. 2013년 1월을 100으로 놓고 2026년 10월까지 이어 보면 그래프 DBMS는 901이 됩니다. 아홉 배입니다. 같은 기간 관계형 DBMS는 80으로 오히려 내려왔습니다.
- SSL 인증서를 처음 이해할 때 알아야 할 것웹사이트 주소 앞에 자물쇠 표시가 붙고 https://로 시작한다면 SSL/TLS 인증서가 사용되고 있다는 뜻입니다. 인증서는 방문자가 접속한 사이트가 진짜인지 확인하고, 주고받는 데이터를 암호화하는 역할을 합니다.
- HSTS 설정 전 알아야 할 옵션과 안전한 적용 순서HSTS(HTTP Strict Transport Security)는 브라우저에 “이 도메인은 항상 HTTPS로만 접속해야 한다”고 알려주는 보안 정책입니다. 잘 설정하면 중간자 공격과 SSL stripping을 줄일 수 있지만, 성급하게 적용하면 장애 복구가 어려워질 수 있습니다.
- LLM 게이트웨이 직접 구현: 스트리밍부터 사용량 기록까지이 글에서 직접 구현할 LLM 서버는 모델 가중치를 GPU에 올리는 추론 서버가 아닙니다. 여러 외부 또는 내부 모델 엔드포인트 앞에서 인증, 모델 선택, 스트리밍, 장애 처리, 사용량 기록을 담당하는 애플리케이션 계층의 LLM Gateway입니다. 모델 추론 자체는 vLLM 같은 별도 엔진이나 상용 API가 담당한다고…