결제 서비스 기획 체크리스트

결제 앱 UI 예시, 출처: Nick Budrewicz

어떤 PG를 써야 할까?

 PG(Payment Gateway)는 온라인에서 결제를 처리하기 위해 중요한 역할을 하는 시스템입니다. 한국에서 많이 쓰이는 PG 서비스로 KG 이니시스(KCP), 나이스페이먼츠(NicePay), 다날, 페이코, 카카오페이, 토스페이먼츠가 있습니다.

 

 이런 PG들은 각각의 특징과 장단점이 있는데, 보통은 비즈니스의 특성과 목적에 맞게 선택하는 것이 중요합니다. 초기 등록비, 연회비, 수수료, 정산주기와 같은 지표를 비교하며 이용할 PG사를 정합니다. 저는 이와 같은 사업적인 결정사항에 대해서는 자세히 다루지 않겠습니다.

 

 

앱스토어의 인앱 결제 규정

 구체적인 것들을 고민해 보기에 앞서, Apple의 앱스토어(App Store)에 배포하는 앱 서비스의 담당자가 꼭 알아두어야 할 점이 있습니다. 바로 앱스토어에서의 결제 연동은 Apple의 정책에 따라서 제한되어 있다는 점입니다. 앱에서 판매하는 디지털 상품이나 서비스에 한해, PG와 Apple 인앱결제・정기결제는 함께 사용할 수 없습니다.

 

 사용자가 입력한 주소로 제품을 실물 배송하는 경우와 다르게, 앱서비스에서 '캐시', '포인트'와 같이 앱 안에서만 사용할 수 있는 재화를 판매하려면 앱스토어의 인앱 결제 시스템을 이용해야만 합니다. 정기 결제를 제공하는 경우에도, 역시 앱스토어의 정기 결제 규정을 따라야 합니다. 앱 출시 이전의 심사 과정에서 이를 엄격하게 관리하고 있기 때문에 예외는 없습니다.

 

 앱스토어 매출을 정산할 때, Apple로부터 30% 상당의 수수료를 제하고 정산받기 때문에 인앱결제를 사용하지 않으려는 서비스도 있습니다. 하지만 앱스토어에 결제기능이 포함된 서비스를 배포하는 이상, 인앱결제는 반드시 사용해야 합니다. (이 수수료 문제를 해소하기 위해 현업에서는 꼼수를 사용하기도 합니다. 공개적으로 권장할 만한 방법은 아니기 때문에 본문에는 작성하지 않겠습니다.)

 

 한 가지 더, 중국 본토에서는 앱스토어의 인앱 결제를 허용하지 않고 있기에(2023년 기준) 중국에 거주하는 사용자를 대상으로 하는 서비스 담당자라면 참고해 주시기 바랍니다. (애초에 중국에 거주하는 중국인 사용자들은 아이피 우회 방법으로 앱스토어를 이용하는 경향이긴 합니다.)

 

 이제부터는 우리 서비스에 붙일 결제 게이트웨이 수단을 정했다고 가정하겠습니다. PG, 또는 앱스토어 인앱결제와 정기결제 로직을 활용하고자 할 때, 먼저 확인하면 좋을 목록을 소개하겠습니다.

 

 

출처: CSS Author

결제 수단 정하기 체크리스트

- [ ] 우리 서비스는 다양한 결제 수단을 제공할 의무가 있을까?

- [ ] 우리 서비스는 다국어, 다양한 국가의 통화의 결제를 지원해야 할까?

- [ ] 우리 서비스는 모바일 앱과 웹의 결제 호환성을 유지해야 할까?

- [ ] 우리 서비스의 결제 시스템에 프로모션이나 할인 기능이 추가될 가능성이 있을까?

 

 

우리 서비스는 다양한 결제 수단을 제공할 의무가 있을까?

 첫 번째와 두 번째는 비슷한 동기에서 출발하는 질문입니다. 일반적으로 다국적 사용자를 대상으로 하는 글로벌 서비스 기획자가 고민해 보면 좋을 항목입니다.

 

 PG결제를 활용하는 서비스라면 사용자의 지역 특성에 맞춘 결제 방법을 고려해야 합니다. 가령 인도네시아에 거주하는 서비스 사용자가 페이코 결제를 하기는 어려울 것이라는 점입니다. 이런 경우에는 전 세계에서 널리 사용되는 PayPal 솔루션을 주로 사용하고, Braintree와 같은 디지털 지갑이나 비트코인 결제 수단을 지원하기도 합니다. 중국에서는 Alipay를 사용하죠.

 

 앱스토어나 구글 플레이스토어의 결제기능을 활용하는 앱서비스라면, 결제모달에서 사용자의 앱스토어나 구글 플레이스토어 계정 기반으로 통화 화폐와 금액을 안내합니다. 운영자가 직접 콘솔에서 금액을 설정할 수도 있습니다.

 

 (제가 현업에서 겪었던 이슈 하나를 소개하겠습니다. 당시 저는 글로벌 앱서비스의 결제 기획담당자였습니다. 제가 담당한 앱은 앱스토어 인앱결제를 활용했는데, 앱에서 판매하는 상품별 가격에 모든 국가별 화폐단위와 가격을 표시할 수 없다는 문제가 있었습니다. 앱스토어에서 결제기능을 지원하는 모든 국가를 대상으로 상품을 판매하고는 있었지만, 결제모달을 호출하기 전까지는 정확한 가격을 안내할 수가 없었던 문제입니다. (꼼꼼하기로 유명한 Apple이기에 더욱 왜인지 모르겠지만) Apple iOS 클라이언트 패키지에서는 해당 기능을 제공하지 않고 있었습니다. 결국 저는 상위 매출 5개 국가 사용자에게만 정확한 화폐단위와 금액을 안내하기로 결정했고, 그렇지 않은 국가의 사용자는 미국달러로 상품금액을 조회할 수 있도록 개선했습니다. 사용자 분기 로직이 들어갔기 때문에, 사용자가 상품 판매페이지에 진입하면 사용자의 앱마켓 계정 정보에서 국가정보를 체크하는 로직이 추가되었습니다. 이처럼 글로벌 서비스를 운영하는 담당자라면, 화폐나 통화정책의 이슈가 발생할 수 있습니다.)

 

 

우리 서비스는 모바일 앱과 웹의 결제 호환성을 유지해야 할까?

 세 번째 질문은 웹과 앱 모두를 제공하는 서비스에서 꼭 생각해 볼 점입니다. 웹과 앱 각각 플랫폼에서 결제한 정보를 얼마나 공유할지 정해야 합니다. 하루 구매 제한 횟수가 있다면 그를 공유할 것인지, 결제・결제취소・환불신청 상태를 얼마나 공유할 것인지, 구매하거나 반환받은 재화를 얼마나 공유할 것인지 같은 것들을 정합니다.

 

 

우리 서비스의 결제 시스템에 프로모션이나 할인 기능이 추가될 가능성이 있을까?

 네 번째 질문에 대한 답을 하려면 사업담당자와의 긴밀한 소통이 필요합니다.

 

 사업적 측면으로는 대상 고객 및 시점, 할인 및 프로모션 종류를 고민해 볼 수 있습니다. 어떤 고객(신규 가입자, 기존 사용자, 특정 이벤트 참여자)을 대상으로 할인을 제공할 것인지, 언제(특정 기간, 이벤트 기간, 휴가철) 제공할 것인지, 할인 형태(퍼센트 할인, 고정 금액 할인, 1+1 이벤트, 배송정책이 있다면 무료배송, 프로모션 코드 입력)는 어떻게 될 것인지에 대한 논의를 해 볼 수 있습니다.

 

 이를 기반으로 기술적인 측면을 고민하는 것이 좋습니다. 사용자가 할인 혜택을 받을 때 결제 시스템이 어떻게 동작할지 플로우차트를 정의하는 것이 필요하고, 프로모션 코드의 유효성 검사나 처리 로직에 대해 개발팀과 논의해 봐도 좋습니다. 할인에 제한 사항이 있다면 금액 제한, 사용 횟수 제한, 특정 상품에만 적용되는 조건 같은 것들을 개발팀에게 미리 안내하는 것도 좋습니다.

 

 가능하다면 실적과 효과를 측정할 수 있도록 설계합니다. 매출 변화, 사용자 유입 증가 같은 성과를 분석할 수 있는 지표를 설정하면 향후 전략을 세울 때 큰 도움이 됩니다.

 

 

출처: UI8

사용자 결제 경험 체크리스트

- [ ] 에러 메시지와 안내가 이해하기 쉽고 사용자 친화적인가?

- [ ] 모바일 앱, 웹 버전에서 일관된 결제 경험을 제공하는가?

- [ ] 결제 상태에 대한 실시간 업데이트를 제공하는가?

- [ ] 사용자에게 결제 완료 및 거래 상태와 관련된 알림을 제공하는가?

 

 

에러 메시지와 안내가 이해하기 쉽고 사용자 친화적인가?

 저는 결제 프로세스가 얼마나 간편하고 직관적인지 고민하는 것은 부차적인 것이라고 생각합니다. 일단 결제가 되고 봐야, 그다음 사용성을 고민할 수 있는 것이지요. 개인적인 견해로 결제 서비스의 꽃은 에러메시지입니다. 결제 프로세스에서 수십, 수백 개의 오류 상황이 발생할 수 있고, 발생하기 때문입니다.

 

 다음은 제가 정리해 본, 일반적으로 발생할 수 있는 결제 오류와 대응책입니다. 만약 PG를 연동했다면, 결제 오류시에 PG 측 API로부터 결제 에러코드가 반환될 것입니다.

 

결제 오류와 대응책

 1. 신용카드 거절

    - 사용자에게 다른 결제 수단 시도 또는 다른 카드 사용을 권장.

    - 사용자에게 카드사에 문의하도록 안내.

2. 거래 실패

    - 사용자에게 결제 실패 메시지를 표시.

    - 사용자에게 다시 시도하도록 안내.

    - 가능하면 사용자에게 실패 원인에 대한 정보 제공.

3. 잔액 부족

    - 사용자에게 잔액 부족으로 결제가 실패했다는 메시지를 표시.

    - 사용자에게 다른 결제 수단을 사용하거나 충전을 권장.

4. 카드 만료

    - 사용자에게 카드의 유효 기간이 만료되어 결제가 실패했다는 메시지를 표시.

    - 사용자에게 새로운 카드 등록을 권장.

5. 네트워크 문제

    - 사용자에게 네트워크 연결이 불안정하거나 끊어진 상태임을 안내.

    - 사용자에게 잠시 후 다시 시도하도록 안내.

6. 세션 만료

    - 결제 프로세스 중 세션이 만료된 경우, 사용자를 로그아웃하지 않고 결제 단계를 다시 시작하도록 안내.

    - '세션'은 전문적인 용어이므로, 사용자 안내 시에는 쉬운 메시지를 사용.

7. 중복 결제

    - 사용자에게 경고 메시지를 표시.

    - 사용자에게 중복 결제가 아닌 경우에만 거래를 진행하도록 안내.

8. 서버 오류

    - 사용자에게 사과하는 메시지를 표시.

    - 사용자에게 잠시 후 다시 시도하도록 안내.

9. 보안 문제

    - 사용자에게 보안 인증을 거치도록 안내.

10. 결제 API 오류

    - 사용자에게 잠시 후 다시 시도하도록 안내.

    - 개발팀에서 로그를 수집 및 관찰하고 있는지 확인. 

11. 환불 오류

    - 사용자에게 사과하는 메시지를 표시.

    - 사용자가 서비스 지원팀에게 접촉하여 해결할 수 있는 방안 제시.

    - 서비스 지원팀에게 문제를 공유하고 조치할 수 있도록 지원.

 

 모든 에러메시지에 다 대응할 수는 없습니다. 자주 발생하는 에러, 환불 오류와 같은 민감한 에러 위주로 구체적인 대응방안을 마련하는 것이 우선입니다. 이외의 사례는 사용자가 직접 문제를 해결할 수 있도록 가이드 페이지로 안내를 유도하거나, 서비스 지원팀에게 구체적인 도움을 받을 수 있도록 지원하는 것을 권장합니다.

 

 

모바일 앱, 웹 버전에서 일관된 결제 경험을 제공하는가?

 일관된 UI/UX를 제공하는 것은 당연하고, 기획자는 모바일 앱과 웹 간 연동 정책에 주목하는 것이 좋습니다. 앱에서 결제를 시작한 후에도 웹에서 결제를 계속할 수 있도록 세션 정보를 얼마나, 언제까지 공유할 것인지 정할 수 있습니다.

 

 목표하는 지표의 값에 도달하기 위해, 결제 속도나 성능을 개선할 수도 있습니다. 가령 결제 단계를 줄이면 일정 기간 동안의 결제 성공 횟수가 증가할 것이라는 가설을 세운다면, 결제 프로세스에서 로딩 속도를 최적화하거나, 생체 인증 기능을 활용해 결제를 간편하게 개선하는 방법이 있습니다.

 

 

결제 상태에 대한 실시간 업데이트를 제공하는가?

 결제 진행 상황에 대한 알림이나 상태메시지를 꼭 제공해서, 사용자가 언제든지 결제 상태를 확인할 수 있도록 해야 합니다. 결제 문제는 민감해서, 서비스에 대한 신뢰로 이어질 수 있기 때문입니다. 사용자에게 결제 프로세스에 대한 투명성을 제공하기 위해 생각해 볼 만한 몇 가지를 안내합니다.

 

결제 상태 업데이트

1. 결제 상태 실시간 표시

- 결제 진행 중, 결제 완료에 대한 상태를 사용자에게 실시간으로 제공.

- 결제 진행 중 상태에서는 시각적인 피드백 제공. 로딩 인디케이터나 프로그래스 바 UI 사용이 적절함.

- 결제 진행 상태가 오래 걸린다면 단계별 메시지를 제공해서 어느 단계에 있는지 안내.

- 결제 완료 상태에서는 결제 성공 메시지, 주문번호, 결제 내역을 제공.

 

2. 거래 상태 알림

- 거래 상태에 변화가 있을 때 사용자에게 실시간 알림 제공.

- 거래 상태는 다음과 같이 구분할 수 있음: 주문 접수(결제 처리 중), 결제 완료, 주문 처리 중, 배송 출발, 도착 예정, 배송 완료, 거래 취소, 환불 처리, 거래 완료.

 

3. 사용자 알림 설정

- 사용자가 원하는 경우 알림 설정을 사용자화할 수 있도록 제공.

- 거래 상태에 따른 알림 설정 켜고 끄기 기능을 제공하는 것을 권장. (e.g. '알림 설정에서 원하는 알림 유형을 선택하세요.')

 

 

 기획자가 나서서 챙기면 좋은 사례 위주로 소개드렸습니다. 이외에도 보안과 개인정보, 수수료와 비용, 환불 정책, 글로벌 국가별 결제 법규, 테스트와 QA, 데이터 분석과 모니터링 측면에서 고려해야 할 것들이 있습니다. 이미 내용이 길어져 버려서, 기회가 된다면 추가 설명을 하겠습니다.

 

 결제 서비스 담당자는 Yes or No 가 명확한 성격이 잘 어울리는 것 같습니다. 결제 서비스에 대한 오너십 없이 사업 담당자에게 업무를 넘겨버리거나, 개발팀에게 알아서 해달라고 맡기기 십상인 서비스 특성 때문이라고 생각합니다. 결제 서비스는 백엔드 동작이 중요하기에, 기획자의 기본 정책과 플로우차트를 비롯한 장표를 잘 작성하는 능력이 팀 협업에 큰 도움이 됩니다.

 

 마지막으로 PG와 웹・앱서비스 간의 결제와 환불 요청을 보여주는 간단한 플로우차트 예시를 놓고 마무리하겠습니다. 각 사각형 프로세스 하위에서 이루어지는 상세 플로우를 정의하면 실무에 큰 도움이 됩니다.

 

결제 플로우차트 예시

 

환불 플로우차트 예시

 

 

결제 서비스 체크리스트

- [ ] 우리 서비스는 다양한 결제 수단을 제공할 의무가 있을까?

- [ ] 우리 서비스는 다국어, 다양한 국가의 통화의 결제를 지원해야 할까?

- [ ] 우리 서비스는 모바일 앱과 웹의 결제 호환성을 유지해야 할까?

- [ ] 우리 서비스의 결제 시스템에 프로모션이나 할인 기능이 추가될 가능성이 있을까?

- [ ] 에러 메시지와 안내가 이해하기 쉽고 사용자 친화적인가?

- [ ] 모바일 앱, 웹 버전에서 일관된 결제 경험을 제공하는가?

- [ ] 결제 상태에 대한 실시간 업데이트를 제공하는가?

- [ ] 사용자에게 결제 완료 및 거래 상태와 관련된 알림을 제공하는가?

 

 

 

끝.