자체 Tap to Pay 앱을 구축하는 것은 얼마나 어려울까요? (직접 시도해 보았습니다)

SDK 브로셔에서 제시하는 것보다 더 어렵습니다. 그리고 그 어려움은 대부분 코드가 아닙니다. 저희는 Final POS 앱에 Tap to Pay 기능을 출시했기 때문에, 이 답변은 문서를 읽어서가 아니라 직접 경험한 데서 나온 것입니다. 자체 Tap to Pay 앱을 구축하고 싶다면, 훨씬 더 긴 권한 획득 프로젝트(결제 대행사 파트너십, Apple의 수동 권한 승인 또는 Android의 연구소 평가, 그리고 앱 심사)에 둘러싸인 짧은 소프트웨어 프로젝트를 계획해야 합니다. 이 모든 과정이 첫 번째 실제 결제가 이루어지기 전에 완료되어야 합니다.

빠른 주의 사항: 플랫폼 및 카드 업계의 규칙은 자주 변경됩니다. 아래의 모든 내용은 발행일 기준 정확하므로, 구체적인 내용은 스냅샷으로 취급해 주시기 바랍니다.

Tap to Pay 앱은 실제로 어떤 역할을 하나요?

Tap to Pay는 휴대폰 자체를 카드 단말기로 바꿉니다. 단말기도, 동글도 필요 없습니다. 고객이 비접촉식 카드나 Apple Pay, Google Pay 같은 모바일 지갑을 가맹점의 기기에 직접 탭하면, 휴대폰의 NFC 칩(비접촉 결제에 사용되는 근거리 무선 통신)을 통해 결제가 진행됩니다. 용어가 다소 헷갈린다면, 모바일 탭 결제와 모바일에서의 Tap to Pay의 차이점을 정리해 두었으니 확인해 보세요.

여기에 함정이 있습니다. NFC 태그를 읽는 것은 주말 프로젝트 수준으로 간단하며, 취미로 하는 사람들도 늘 하는 일입니다. 하지만 결제 카드를 읽는 것은 차원이 다른 일입니다. 카드는 EMV(카드 업계의 칩 프로토콜)를 사용하며, 카드 데이터는 종단 간 암호화 상태를 유지해야 하고, 인증된 소프트웨어만 이 데이터에 접근할 수 있습니다.

왜 카드를 직접 읽을 수는 없나요?

코드 조각이 실제로 실행되기 전에 기술 스택의 모든 레이어에서 권한을 요구하기 때문입니다.

• Apple은 앱에 결제 NFC에 대한 원시 접근 권한을 주지 않습니다. Apple이 케이스별로 부여하는 특별 권한인 Tap to Pay on iPhone 권한(Entitlement) 뒤에 있는 ProximityReader 프레임워크를 사용해야 합니다. 또한 Apple은 지원되는 결제 서비스 제공업체(PSP, 실제로 돈을 이동시키는 회사)와의 연동을 요구합니다. PSP는 가맹점 기기에 로드되는 인증된 단말기 구성을 제공하고 인증 부담을 짊어집니다.

• Android는 개발자에게 더 개방적인 NFC 접근 권한을 제공하지만, 결제 수락 앱은 여전히 독립적인 PCI 공인 연구소로부터 PCI MPoC 표준(휴대폰을 결제 단말기로 사용할 때 적용되는 카드 업계의 보안 규칙)에 따른 평가를 받아야 합니다.

• 두 플랫폼 모두의 기저에는 매입 관계가 필요합니다. 즉, 카드 네트워크의 규칙을 준수하면서 가맹점을 위해 대금을 정산해 줄 결제 대행사(Processor)가 필요합니다.

이 중 어느 것도 코드를 더 잘 짠다고 해서 해결할 수 있는 것이 아닙니다. 서류 작업, 계약, 그리고 심사 대기의 연속입니다.

iPhone에서의 승인 경로는 어떻게 되나요?

Apple이 발표한 요구 사항에 따르면, 경로는 다음과 같습니다. 조직 수준의 Apple 개발자 계정을 보유하고(계정 소유자가 직접 요청을 제출해야 함), 해당 지역에서 지원되는 PSP와 파트너십을 맺고, 권한을 요청하고, ProximityReader API 또는 PSP의 SDK를 연동하고, 결제 화면에 대한 Apple의 디자인 가이드라인을 준수하고, 앱을 심사에 제출합니다. Apple 문서에 따르면 이 기능은 지원되는 국가 및 지역에서만 작동하므로, 사용 가능 여부 자체는 시장별로 이미 결정되어 있습니다.

개발자가 아닌 창업자나 가맹점의 입장에서 이 목록을 다시 읽어보세요. '기능 구현'에 해당하는 단계는 단 하나도 없습니다. 기능 구현은 쉬운 부분이며, 권한 획득이야말로 진정한 진입 장벽입니다.

결제가 작동한 후에는 어떤 작업이 필요한가요?

승인된 결제는 단지 결제 수단일 뿐, POS 시스템 전체를 의미하지는 않습니다. 돈이 움직이는 순간, 결제 주변의 모든 것이 정확해야 합니다. 대조할 장바구니, 영수증의 세금, 환불 경로, 그리고 정산 보고서(매일 모든 금액이 매출과 일치해야 함) 등이 그렇습니다. 저희는 Lovable이나 Replit으로 POS를 구축할 수 있는지 검토할 때도 동일한 격차를 발견했습니다. 인터페이스를 생성하는 것은 빠르지만, 그 아래에 있는 커머스 레이어를 구축하는 데 엄청난 시간이 소요됩니다.

Tap to Pay는 고유한 운영상의 특이점도 가지고 있습니다. 저희의 구현 방식에서는 결제를 받는 동일한 기기에서 매출을 등록해야 하며, 브라우저가 아닌 네이티브 앱에서만 작동합니다. 이러한 제약 조건은 어떤 브라우저나 브로셔에도 나와 있지 않습니다. 직접 발견하고, 우회 방법을 설계하고, 도움말 문서를 작성해야 합니다. 그리고 카운터 위의 휴대폰만으로는 부족해지는 순간, 결국 실제 하드웨어 결정을 내려야 합니다.

그렇다면 자체 Tap to Pay 앱을 구축하는 것은 얼마나 어려울까요?

특정한 방식으로 어렵습니다. 코딩은 가장 작은 부분에 불과하며, 결제 대행사 파트너십, Apple 권한 획득, Android 연구소 인증, 앱 심사가 대부분을 차지하며, 이 중 어느 것도 엔지니어링 노력만으로 해결되지 않습니다. 저희에게는 그만한 가치가 있었습니다. POS 플랫폼이 그 비용을 사용하는 모든 가맹점에 분산시킬 수 있기 때문입니다. Tap to Pay는 이제 저희 가맹점들이 켜기만 하면 되는 결제 버튼이며, Tap to Pay 결제 받기는 카운터에서 5단계만 거치면 되는 일상적인 작업입니다. 결제 자체가 귀사의 제품이라면 이 험난한 과정은 입장료와 같습니다. 하지만 결제가 단지 대금을 받는 수단일 뿐이라면, 자체 Tap to Pay 앱을 구축하는 것은 재정적으로 아무런 의미가 없습니다. 완성된 버전이 이미 POS 앱 내에 존재하며, 수수료를 비교하는 것이 진짜 핵심이기 때문입니다.

기본 원칙: 어떤 기능이 존재하기 위해 타인의 허가가 필요하다면, 아무리 영리한 코드를 짜더라도 지름길은 없습니다.