2025년 10월 14일·8분
모바일 앱의 Apple Pay: 개념과 작동 방식
모바일 앱에서 Apple Pay가 무엇인지, 내부에서 어떻게 작동하는지, 안전하게 통합해 결제 속도를 높이고 전환율을 개선하는 방법을 알아보세요.
모바일 앱에서 Apple Pay가 무엇인지, 내부에서 어떻게 작동하는지, 안전하게 통합해 결제 속도를 높이고 전환율을 개선하는 방법을 알아보세요.
Apple Pay는 애플의 디지털 월렛이자 결제 서비스입니다. 사용자는 iPhone, Apple Watch, iPad 또는 Mac에 신용카드, 직불카드, 일부 선불·스토어 카드를 안전하게 저장하고 탭 한 번 또는 얼굴·지문 확인만으로 결제할 수 있습니다.
카드 번호나 청구 정보를 입력하는 대신 사용자는 Face ID, Touch ID 또는 기기 암호로 인증합니다. Apple은 기기별 토큰을 생성해 실제 카드 번호가 가맹점에 전달되지 않도록 합니다.
Apple Pay는 주로 세 가지 맥락에서 작동합니다:
이 가이드는 앱 내부에서 전 경험이 앱 안에 머무는 인앱 Apple Pay에 중점을 둡니다.
작은 화면에서 카드 정보를 입력하는 것은 느리고 오류가 발생하기 쉽습니다. Apple Pay는 여러 입력 필드를 하나의 상호작용으로 대체하여 보통:
카드와 주소가 이미 기기에 저장되어 있기 때문에 첫 구매자도 마찰이 줄어듭니다.
Apple Pay는 지원 지역의 최근 iPhone, iPad, Apple Watch, Mac 모델에서 동작하며 Visa, Mastercard, American Express 등 주요 네트워크와 일부 지역 네트워크를 지원합니다(발급 은행에 따라 다름).
Apple Pay는 다음과 같은 경우에 가장 적합합니다:
다른 지갑이나 전통적인 카드 폼과 병행해서 제공해야 하며, Apple Pay가 없는 사용자도 결제할 수 있도록 해야 합니다.
Apple Pay는 단순한 “더블 클릭으로 결제” 경험 뒤에 많은 복잡성을 숨깁니다. 내부적으로는 여러 주체와 보안 계층이 조율되어 안전하게 자금이 이동합니다.
일반적인 Apple Pay 거래에는 다음이 포함됩니다:
사용자가 카드를 Apple Wallet에 추가하면 실제 카드 번호(FPAN, Funding Primary Account Number)는 카드 네트워크와 발급사로 안전하게 전송됩니다. 그들은 기기용 DPAN(Device Primary Account Number)과 해당 기기에 고유한 암호 키를 응답합니다.
Apple Pay 거래에서는 DPAN을 사용합니다. 앱과 백엔드는 FPAN을 보지 않습니다. 이 것이 Apple Pay 토큰화 모델의 핵심입니다: 기기는 대체 카드 번호와 일회성 크립토그램을 사용해 실제 카드를 노출하지 않습니다.
지원되는 기기에서는 결제 자격 증명과 키가 Secure Element(또는 Secure Enclave로 보호됨)에 저장됩니다. 사용자가 인증하면(Face ID, Touch ID, 또는 암호), Secure Element는:
앱은 Apple Pay API를 통해 이 불투명하고 암호화된 토큰을 받고 이를 백엔드로 전달하면 백엔드가 PSP나 게이트웨이로 전달합니다.
PSP는 토큰을 복호화해 DPAN과 크립토그램을 추출하고 카드 네트워크를 통해 발급 은행으로 승인 요청을 제출합니다. 발급사는 크립토그램과 카드 상태를 검증한 뒤 승인 또는 거절을 반환합니다.
이후 정산 단계에서 승인된 금액이 캡처되고 배치되어 발급 은행에서 가맹점의 어큐러로 이동합니다. 앱 입장에서는 단지 캡처 또는 판매 완료로 보이지만 내부적으로는 어큐러, 카드 네트워크, 발급사 간에 DPAN을 사용해 조정됩니다—실제 카드 번호는 사용되지 않습니다.
앱에 Apple Pay를 추가하기 전에 기술적·비즈니스적·지역적 요구사항을 충족해야 합니다.
가맹점 측에서는 다음이 필요합니다:
많은 가맹점은 웹 기반 또는 하이브리드 플로우에서 사용되는 가맹점 검증을 위해 Merchant Identity 인증서를 추가로 생성합니다.
인앱 Apple Pay는 다음에서 지원됩니다:
최신 API를 사용하는 경우 최소 지원 OS를 Apple 문서에서 확인하세요.
Apple Pay는 모든 국가 또는 은행에서 지원되지 않습니다. 다음을 확인하세요:
Apple은 특정 가맹점 카테고리 및 사용 사례(불법 상품, 일부 디지털 콘텐츠/서비스, 고위험 업종 등)를 제한할 수 있습니다. 다음을 확인하세요:
결국 Apple Pay 토큰화와 복호화를 지원하는 PSP/게이트웨이가 필요합니다. 공급자에게 다음을 확인하세요:
원활한 Apple Pay 흐름은 사용자에게 거의 보이지 않는 경험을 제공합니다. 일반적인 단계는 다음과 같습니다.
여정은 일반적으로 상품 페이지나 장바구니 화면에서 시작됩니다. 사용자가 옵션(사이즈, 색상, 수량)을 선택하면 체크아웃으로 이동합니다.
체크아웃 또는 장바구니 화면에서 Apple이 제공하는 표준 Apple Pay 버튼을 표시하세요. 버튼은:
사용자가 버튼을 누르면 Apple Pay 시트가 화면 하단에서 올라옵니다.
이 시트에는 보통 다음이 포함됩니다:
사용자는 확인 전에 시트에서 카드, 배송지, 연락처 등을 조정할 수 있습니다.
결제를 승인하려면 사용자는 다음으로 인증합니다:
시트는 예: Face ID 기기에서 “더블클릭하여 결제”와 같이 명확히 안내합니다.
인증 후 시트는 진행 상태를 표시하고 사라져 앱으로 돌아갑니다.
앱은 즉시 명확한 상태를 보여줘야 합니다:
이 상태들을 명확하고 일관되게 유지하면 사용자가 결제 상태를 명확히 이해하고 흐름에서 통제감을 느끼게 됩니다.
iOS에서 Apple Pay 구현은 PassKit 프레임워크와 몇 가지 핵심 클래스 중심입니다. 앱 수준의 엔드투엔드 흐름은 다음과 같습니다.
이로써 앱 번들이 가맹점 식별자와 연결되어 Apple Pay 토큰을 서버용으로 생성할 수 있게 됩니다.
PKPaymentRequest 생성import PassKit
func createPaymentRequest() -> PKPaymentRequest? {
guard PKPaymentAuthorizationController.canMakePayments() else { return nil }
let request = PKPaymentRequest()
request.merchantIdentifier = "merchant.com.yourcompany.app"
request.countryCode = "US"
request.currencyCode = "USD"
request.supportedNetworks = [.visa, .masterCard, .amex]
request.merchantCapabilities = [.capability3DS]
request.paymentSummaryItems = [
PKPaymentSummaryItem(label: "Pro Subscription", amount: 9.99),
PKPaymentSummaryItem(label: "Your Company", amount: 9.99)
]
return request
}
merchantIdentifier, countryCode, currencyCode는 가맹점 설정과 일치해야 합니다. supportedNetworks는 귀사와 PSP가 지원하는 카드 스킴을 반영합니다. 최소한 merchantCapabilities에 .capability3DS를 포함하세요.
PKPaymentButton 추가 및 배치Apple의 UI 가이드라인을 준수하려면 커스텀 버튼 대신 PKPaymentButton을 사용하세요:
let payButton = PKPaymentButton(paymentButtonType: .buy, paymentButtonStyle: .black)
제품 화면, 장바구니, 최종 체크아웃 등 구매 의도가 가장 강한 곳에 배치하세요. PKPaymentAuthorizationController.canMakePayments()가 false면 버튼을 비활성화하거나 숨기세요.
PKPaymentAuthorizationController 표시 및 콜백 처리요청으로 컨트롤러를 생성하고 PKPaymentAuthorizationControllerDelegate를 구현하세요:
func startApplePay() {
guard let request = createPaymentRequest() else { return }
let controller = PKPaymentAuthorizationController(paymentRequest: request)
controller.delegate = self
controller.present(completion: nil)
}
extension CheckoutViewController: PKPaymentAuthorizationControllerDelegate {
func paymentAuthorizationController(_ controller: PKPaymentAuthorizationController,
didAuthorizePayment payment: PKPayment,
handler completion: @escaping (PKPaymentAuthorizationResult) -> Void) {
// Send payment.token to your server for processing
// Then call completion(.init(status: .success, errors: nil)) or .failure
}
func paymentAuthorizationControllerDidFinish(_ controller: PKPaymentAuthorizationController) {
controller.dismiss(completion: nil)
}
}
didAuthorizePayment 메서드에서 payment.token을 실제 과금 처리용 서버로 전달합니다. 서버가 응답하면 .success 또는 .failure로 완료하고 paymentAuthorizationControllerDidFinish에서 시트를 닫습니다.
서버 로직은 Apple Pay 시트를 실제 금전 이동으로 바꾸는 역할을 합니다. 앱은 사용자 인증을 수집하고, 백엔드는 가맹점 유효성 검사, 토큰 처리 및 결제 게이트웨이와의 통신을 담당합니다.
Apple Pay 시트를 표시하기 전에 앱은 Apple로부터 가맹점 세션을 받아야 합니다.
PKPaymentAuthorizationController에서 제공한 merchant validation URL을 백엔드로 전송합니다.이 흐름은 앱이 귀하의 가맹점 ID와 도메인에 연관되어 있음을 Apple에게 증명합니다.
사용자가 결제를 승인하면 앱은 암호화된 결제 토큰(PKPaymentToken)을 받고 이를 HTTPS로 백엔드에 전송합니다.
서버에서는:
게이트웨이는 토큰을 복호화(네트워크 토큰 또는 DPAN 사용)하고 카드 네트워크로 카드 승인을 실행합니다.
게이트웨이는 일반적으로 두 가지 흐름을 제공합니다:
백엔드는 게이트웨이의 트랜잭션 ID, 금액, 통화 및 상태를 저장해야 하지만 원시 카드 데이터나 복호화된 토큰 내용은 저장하지 마세요.
정산, 환불 및 고객 지원에 실제로 필요한 정보만 저장하세요:
전체 카드 번호, CVV, 또는 암호화되지 않은 결제 토큰을 서버에 절대 저장하지 마세요. 민감한 처리는 PCI 준수 게이트웨이에 위임하고 통신은 모두 TLS로 보호하며 엄격한 로깅 및 접근 제어를 적용하세요.
Apple Pay는 앱이 원시 카드 번호에 접근하지 않도록 설계되었지만 보안 모델과 귀사의 책임을 이해하는 것이 중요합니다.
사용자가 카드를 Apple Pay에 추가하면 발급사와 네트워크는 실제 PAN(카드 번호)을 기기 계정 번호(DAN)로 대체합니다.
결제 시:
앱과 백엔드는 토큰과 거래 메타데이터만 보며 기본 카드 세부 정보는 보지 못합니다.
민감한 키와 결제 자격 증명은 Secure Enclave에 하드웨어 수준으로 격리되어 저장·처리됩니다.
인증은 사용자 확인에 연결됩니다:
앱은 단지 시스템 시트로부터 성공 또는 실패 신호만 받고 생체데이터나 Secure Enclave 내용을 액세스하지 않습니다.
각 Apple Pay 거래는 다음을 사용합니다:
네트워크와 발급사는 이러한 값을 검증해 클론, 재생·재전송 공격 및 변조를 탐지합니다.
Apple Pay는 앱의 PCI DSS 범위를 상당히 줄일 수 있습니다. 이유:
하지만:
정식 지침은 어큐러, PSP 및 적격 보안 평가사(QSA)와 상의하세요.
Apple Pay는 위험을 줄이지만 부주의한 통합은 노출을 다시 초래할 수 있습니다.
실용적인 팁:
이 경계를 지키면 Apple Pay의 내장 보호 기능을 활용하면서 컴플라이언스 부담을 관리할 수 있습니다.
철저한 테스트는 Apple Pay 통합이 실제 고객에게 올바르게 동작함을 확신하는 유일한 방법입니다. 올바른 샌드박스 설정과 테스트 계획이 필요합니다.
Apple Developer / App Store Connect에서 Users and Access → Sandbox에 샌드박스 테스트 계정을 생성하세요. 이 특수 Apple ID들은 테스트 기기에서 실제 카드 과금 없이 시뮬레이션할 때 사용됩니다.
테스트 기기에서:
지역·통화·카드 스킴이 다른 다양한 샌드박스 테스터를 사용해 엣지 케이스를 재현하세요.
iOS 시뮬레이터는 기본적인 Apple Pay 테스트를 지원해 UI 검증과 초기 개발에 유용합니다. 인증을 시뮬레이트하고 PKPaymentAuthorizationController 흐름을 확인할 수 있습니다.
다만 실제 기기에서만 제공되는 다음을 항상 검증하세요:
시뮬레이터는 편의 기능일 뿐 대체 수단이 아닙니다.
클라이언트와 서버를 포함한 엔드투엔드 흐름에서 최소 다음을 커버하세요:
거부 및 오류 코드를 유도할 수 있는 게이트웨이별 테스트 카드 번호와 트리거를 사용하세요.
문제 추적을 위해 충분히 로그를 남기되 민감한 결제 데이터를 절대 기록하지 마세요. 피해야 할 항목:
대신 기록할 항목:
created → authorized → captured → failed)앱에서 백엔드로 전달되는 상관 ID를 통해 클라이언트 로그와 서버 로그를 연결하세요.
테스트를 실행할 때 다음을 주시하세요:
간헐적 오류나 느린 승인 문제가 보이면 통합 버그로 가정하기 전에 게이트웨이와 Apple 상태를 먼저 확인하세요. 일시적 플랫폼 문제를 코드 버그로 오인하는 시간을 줄일 수 있습니다.
신중한 Apple Pay 디자인은 “있으면 좋은 기능”을 주력 전환 드라이버로 바꿀 수 있습니다. 버튼 배치와 문구의 작은 결정이 사용 빈도에 큰 영향을 줍니다.
구매 의도가 강한 위치에 사용하세요:
“결제 옵션 더보기” 등 추가 탭 뒤에 숨기지 마세요. 단계가 늘어날수록 사용 빈도는 떨어집니다.
다음 위치에서 Apple Pay를 익스프레스 체크아웃으로 제공하세요:
익스프레스 체크아웃으로 제공할 때는 배송 및 연락처 처리 방식이 Apple Pay 인증 중에 이루어짐을 명확히 하세요.
Apple의 **Human Interface Guidelines(HIG)**을 따르세요:
비인증 색상이나 아이콘을 사용해 인지도를 떨어뜨리거나 브랜드 규칙을 위반하지 마세요.
Apple Pay의 도움을 받아 마찰을 줄이세요:
목표는 한 번의 결정적 탭으로 결제 완료하는 것입니다.
혼란스러운 실패 상태는 판매 손실로 바로 이어집니다. 오류 처리 계획:
오류 세부는 내부적으로 안전한 로그에 기록하고, 사용자에게는 이해하기 쉬운 수준의 정보만 제공하세요.
대부분의 Apple Pay 문제는 구성 오류에서 시작됩니다.
우선 코드에서 사용하는 merchant ID가 Apple Developer 계정의 것과 정확히 일치하는지 확인하세요. 한 문자라도 틀리면(또는 샌드박스 merchant ID를 프로덕션에서 사용하면) 흐름이 깨집니다.
다음으로 엔타이틀먼트와 기능을 확인하세요:
Apple Pay 버튼이 보이지 않거나 시트가 표시되지 않으면 구성 오류를 의심하세요.
Apple Pay는 일부 국가·발급사·기기에서 제한될 수 있습니다.
버튼을 표시하기 전에 PKPaymentAuthorizationController.canMakePayments()와 canMakePayments(usingNetworks:)를 사용하세요. false이면 버튼을 숨기고 대체 결제수단과 함께 명확한 설명을 제공하세요.
사용자가 카드가 “지원되지 않음”이라고 보고할 때 확인할 항목:
가맹점 검증 실패는 보통 Apple Pay 시트가 금방 닫히거나 아예 나타나지 않는 증상으로 드러납니다.
네이티브 앱의 경우 주된 원인은:
서버 또는 검증 엔드포인트에서 로그에 다음을 남기세요:
대부분의 경우 로그가 잘못 구성된 항목을 바로 가리킵니다.
모든 실패가 기술적인 것은 아닙니다. 많은 경우가 발급사 거부입니다.
게이트웨이 또는 프로세서의 응답을 항상 확인하세요. 구분해야 할 항목:
사용자에게는 다음과 같은 친절한 메시지로 매핑하세요:
원시 게이트웨이 오류 코드나 불필요한 기술 정보를 사용자에게 노출하지 마세요.
운영 환경에서 Apple Pay의 안정성을 유지하려면 모든 결제 시도에 대해 구조화된 로깅이 필요합니다:
거부, 가맹점 검증 오류, 타임아웃 급증에 대한 대시보드와 알림을 설정하세요. 클라이언트 이벤트와 서버 로그를 상관시켜 문제가 어디서 발생하는지 빠르게 추적할 수 있게 하세요.
이러한 관찰 가능성은 라이브 트래픽에서 문제 발생 시 디버깅 시간을 크게 단축합니다.
Apple Pay를 앱에 도입한 후에는 실제로 체크아웃을 개선하는지 입증해야 합니다. 이를 위해 적절한 이벤트를 추적하고 핵심 지표를 모니터링하며 체계적인 실험을 수행하세요.
명확한 퍼널을 만들고 각 단계에서 이벤트를 기록하세요:
이벤트와 함께 다음과 같은 컨텍스트를 연결하세요:
이를 통해 사용자가 어디서 이탈하는지, UX 관련(취소)인지 기술적(승인 실패)인지 또는 백엔드 문제(캡처 실패)인지 구분할 수 있습니다.
초점이 분명한 지표 세트는 영향을 판단하기 쉽게 합니다:
버전별·시간별로 추적해 Apple Pay 통합 및 UX 개선이 지표를 향상시키는지 확인하세요.
다양한 실험을 진행해 Apple Pay의 효과를 최적화하세요:
채택률, 성공률, 지불까지 소요 시간, 전환율 변화를 측정하세요. 작은 레이아웃 변화도 의미 있는 개선을 가져올 수 있습니다.
Apple Pay의 프라이버시 보장과 규제를 존중하면서 분석을 통합하세요:
Mixpanel, Amplitude, Firebase 같은 주요 분석 플랫폼은 민감 결제 상세를 제외한 Apple Pay 이벤트를 다룰 수 있습니다.
Apple Pay에서 얻은 인사이트는 단일 버튼을 넘어 전체 체크아웃을 개선하는 데 활용할 수 있습니다:
시간이 지나면 이런 측정은 Apple Pay뿐 아니라 전체 체크아웃 경험을 빠르고 명확하며 신뢰할 수 있게 다듬는 데 도움을 줍니다.
Apple Pay 지원은 보통 단일 iOS 앱에서 끝나지 않습니다. 사용자들은 디바이스와 채널을 넘나들며 동일한 결제 경험을 기대하므로 구현 선택은 이를 반영해야 합니다.
네이티브 앱은 PKPaymentAuthorizationController를 사용해 결제 토큰을 백엔드로 직접 전달합니다. 장점:
**웹의 Apple Pay(Safari)**는 자바스크립트와 Payment Request API를 사용합니다. 웹 체크아웃이 이미 있거나 데스크톱과 모바일 Safari 모두에서 Apple Pay를 제공하려면 적합합니다.
많은 팀은 앱 내 네이티브 Apple Pay와 웹의 Apple Pay를 모두 지원하되 백엔드 결제 파이프라인은 공유하는 접근을 선택합니다.
Google Pay, PayPal 등 다른 지갑도 지원한다면 높은 수준의 흐름을 정렬하세요:
이렇게 하면 기기와 결제수단을 바꿔도 사용성이 크게 달라지지 않습니다.
React Native, Flutter 등에서는 일반적으로:
iPhone, iPad, Apple Watch에서 테스트하세요:
iOS, 웹, 기타 플랫폼에 걸쳐 단일 디자인 시스템과 체크아웃 로직을 유지하고 채널별로 얇은 통합 계층을 두는 것이 권장됩니다.
Apple Pay를 건강하게 유지하는 것은 대규모 리팩토링보다 규율 있는 유지보수에 가깝습니다.
Apple Pay는 만료되는 merchant ID와 Payment Processing 인증서에 의존합니다.
소유권 맵을 만들고 누가 Apple Developer 계정을 관리하는지, 인증서가 CI/CD 및 서버 어디에 저장되는지, 어떻게 사용되는지 문서화하세요.
그런 다음:
주요 iOS 릴리스마다 베타와 정식 빌드에서 Apple Pay 플로우를 테스트하세요. 특히:
다음 자료들을 모니터링하세요:
연 1회 이상 디자인 리뷰를 계획해 최신 가이드라인과 접근성 요건에 맞추세요.
카드 네트워크, 통화 및 지원 지역은 시간이 지나며 변경됩니다. 다음을 구성 가능하게 만드세요:
게이트웨이가 새로운 네트워크나 지역 결제를 추가할 때 조정하고 PKPaymentRequest를 업데이트하세요.
게이트웨이 변경, 앱 구조 개편, 토큰 포맷 업데이트 시에는:
이 흐름을 문서화해 신규 팀원이 역공학 없이도 유지보수할 수 있게 하세요.
네트워크의 토큰화 심화, Wallet 내 영수증·주문 업데이터 강화, 인앱·웹·오프라인 Apple Pay의 긴밀한 연계가 확산될 것입니다. Tap to Pay on iPhone과 지역별 금융 옵션 같은 기능이 계속 확대될 것으로 예상되므로, 통합을 구성 기반으로 설계해 핵심 흐름을 다시 구현하지 않고도 새로운 기능을 도입할 수 있게 하세요.
Apple Pay는 사용자의 iPhone, iPad, Apple Watch 또는 Mac에 저장된 카드를 이용해 결제할 수 있게 해주는 애플의 디지털 월렛입니다.
모바일 앱에서는 수동으로 카드 정보를 입력하는 대신 Face ID, Touch ID 또는 기기 암호로 시스템 시트에서 결제를 확인합니다. 앱은 원시 카드 데이터 대신 암호화된 결제 토큰을 받아 백엔드와 결제 게이트웨이에 전송해 실제 결제를 완료합니다.
이로 인해 결제가 더 빨라지고 오류가 줄며 카드 번호가 앱 인프라에 남지 않습니다.
다음과 같은 경우 Apple Pay를 도입하는 것이 좋습니다:
Apple Pay는 카드, PayPal 등 기존 결제수단과 함께 제공하는 추가 옵션으로 가장 잘 작동합니다. 다른 결제수단을 완전히 대체하지 마세요; Apple Pay 이용이 불가능한 사용자도 결제할 수 있어야 합니다.
최소한 다음이 필요합니다:
또한 Apple Pay가 지원되는 지역과 은행에서 운영해야 하며, 가맹점 카테고리 및 제품이 Apple 규정에 부합하는지 확인해야 합니다.
iOS에서의 높은 수준 절차는 다음과 같습니다:
기기에서 생성되는 암호화된 결제 토큰에는 다음이 포함됩니다:
이 토큰은 결제 처리자(PSP)의 공개키로 암호화되어 전달되므로 앱과 백엔드는 이를 불투명한 블롭으로 취급합니다. 백엔드는 토큰을 게이트웨이에 전달하고, 게이트웨이는 이를 복호화해 카드 네트워크와 발급사에 승인을 요청한 뒤 성공 또는 실패를 반환합니다.
앱이나 서버는 실제 PAN이나 암호화 키를 보지 못합니다. 볼 수 있는 것은 거래 메타데이터와 상태뿐입니다.
서버에서 해야 할 일은 다음과 같습니다:
토큰을 직접 복호화하려 하거나 장기 보관하지 마세요. 민감한 카드는 PCI 준수 게이트웨이에서 처리하게 하십시오.
주요 원인들은 다음과 같습니다:
먼저 Apple Developer 포털, Xcode 엔타이틀먼트, 게이트웨이 설정을 확인하고 서버 로그에서 merchant validation 및 게이트웨이 오류 코드를 검사하세요.
안전하게 테스트하려면:
Simulator는 빠른 UI 검증에 유용하지만 Wallet 설정, 생체인증 등 실제 동작은 물리 기기에서 꼭 확인하세요.
전환율을 높이기 위한 권장 사항:
PKPaymentButton을 공식 브랜딩 규칙에 맞게 사용하고 버튼 근처에 명확한 안내 문구(예: “Apple Pay로 즉시 결제”)를 추가하세요.이런 패턴은 마찰을 줄이고 Apple Pay를 빠르고 신뢰할 수 있는 경로로 느껴지게 합니다.
Apple Pay를 자체 퍼널로 추적하세요. 유용한 신호는 다음과 같습니다:
버튼 위치와 문구에 대해 A/B 테스트를 진행하고 Apple Pay 사용자의 완료 및 취소율을 다른 결제수단과 비교하세요.
PKPaymentRequest를 만듭니다.PKPaymentButton을 표시합니다.PKPaymentAuthorizationController를 표시합니다.didAuthorizePayment에서 payment.token을 서버로 전송하여 처리합니다..success 또는 .failure를 반환하고 시트를 닫습니다.대부분의 생체인증, 토큰 생성 등은 시스템 UI가 처리합니다.