결제기능 연동기 - 2부

안녕하세요! 호패에서 Furo(https://furo.one ) 의 이것저것을 개발하는 에드입니다.

호패 팀은 2022년의 마지막 스프린트 목표를 결제 기능 연동으로 정했는데요, 그 과정을 5부작 메이커로그로 작성하고 있습니다!

1부에서는 지금 당장 Furo에 결제 기능을 도입하기로 한 이유와 필요한 기능에 대해 정리해보았습니다!🔥🔥 2부에서는 실제로 결제 기능을 구현하기에 앞서 다른 프로덕트들의 결제기능을 리서치을 리서치하고 Furo 고객의 유저 스토리를 정의했던 과정을 소개해보려 합니다!

지난화 요약

결제기능이 필요한 이유

유료 고객이 생기기 시작했고, 앞으로 유료로 전환하는 고객에 대응하기 위하여

필요한 기능

신용카드 등록
정기 결제
고객 프로젝트의 사용량 집계 시스템
크레딧 시스템

결제기능 레퍼런스 리서치

모방은 창조의 어머니라고 했나요.😀 전체적인 결제 플로우를 그리기에 앞서 평소 잘 이용해오거나 참고하던 서비스들의 정기결제 시스템을 리서치하였습니다.

리서치의 주요 포인트

1) 결제수단 등록 화면 진입 플로우

보통 어떤 식으로 결제수단 등록 화면에 진입하게 될까?

2) 결제수단 등록 화면 구성

결제수단 등록 화면에 결제 수단 등록 버튼만 있지는 않을 것 같지는 않은데 어떤 정보들과 기능으로 화면을 구성해야 할까?

3) 결제내역 화면 구성

상품 이름, 금액, 결제일... 또 어떤 정보를 어떤 UI로 보여주어야 할까?

4) 신용카드 등록 UX

신용카드 등록에는 어떤 정보가 필요하지?
신용카드를 등록했다가 도중에 정보를 삭제하면?
신용카드는 보통 여러 개 등록해서 쓸 수 있나?
여러 개 등록하면 대표 카드 지정도 해야겠네?
등등...

5) 유료 플랜 적용 단위

유료 플랜을 어떤 단위로 적용해야 할까? (팀, 워크스페이스, 프로젝트, ...)

결제 시스템을 만들 때 까다로운 부분 중 하나는 "유료 플랜을 어떤 단위에 적용할 것인가" 하는 문제입니다. 초기 SaaS의 경우 팀 기능이 없는 경우가 많기는 하지만, 기능의 성숙도가 높아지면 프로젝트는 [ 팀 > 워크스페이스 > 프로젝트 ] 의 계층구조로 관리되며, 사용자는 여러 팀에 속할 수 있게 되죠. 그렇다면 유료플랜은 어느 단위에 적용되는 것이 좋을까요? 결론부터 말씀드리면 일반적으로는 '팀'입니다. 팀은 회사 전체나 개발 부서 전체를 고려한 계층이기 때문입니다. (Team이라는 용어 대신 Organization이라고 명명하는 경우도 많죠) Furo는 아직 팀과 팀원을 관리할 수 있는 기능 없지만 내부적으로 팀을 만들고 관리할 수 있도록 DB 스키마를 구성해두었습니다. 때문에 실제 결제를 할 때 어떤 UX로 팀에 유료플랜을 적용하는지 파악하는 것이 이번 리서치의 중요한 포인트 중 하나였습니다!

리서치 내용 와이어프레임으로 정리

Alchemy

Alchemy는 Dapp을 개발할 때 직접 블록체인 노드를 운영하지 않고도 블록체인 네트워크와 통신할 수 있도록 엔드포인트를 제공하는 서비스(Web3 Provider)죠! 블록체인과 Dapp 개발에 익숙하지 않은 독자라면 이해가 어려울 수 있지만 본편의 주제를 고려하여 자세한 설명은 생략하는 점 양해 부탁드리겠습니다.😅

Alchemy의 경우 요청수 기반으로 요금을 청구합니다. 저희 Furo는 MAU 기반의 사용료 청구를 고려하고 있었기에 Alchemy를 참고하였습니다.

특징

개인 설정에서 결제 페이지로 이동한다.
결제 페이지에서 현재 적용되고 있는 구독 플랜과 다른 구독 플랜의 정보를 비교할 수 있다.
먼저 신용카드를 등록해야만 다른 구독 플랜으로 변경할 수 있다.
청구서 페이지가 별도로 존재한다.
요청 수에 따른 예상 비용 추정할 있는 cost estimator가 있다.
구독 플랜은 팀 단위로 적용되지만, 사용자는 하나의 팀에만 속할 수 있기 때문에 팀을 선택하여 결제를 하는 UI는 없다.
다른 사용자를 초대하고 크레딧을 얻을 수 있으며, 이 크레딧을 결제 금액 대신 지불할 수 있다.

Vercel

Vercel은 프론트엔드 어플리케이션을 호스팅해주는 서비스입니다. 데이터를 저장할 필요 없는 싱글페이지 애플리케이션을 호스팅하고, 관리하는데 최적화되어 있죠.

Vercel 가격 정책의 특징은 팀원 수 기반의 기본 요금을 선불로 청구하고 과 네트워크 대역폭 등 사용량 기반의 추가 요금을 후불로 청구한다는 점입니다(usage-based meter with flat price). Furo가 고려중인 가격 정책이 거의 정확히 이러한 형태이기 때문에 Vercel도 많이 참고하였습니다.

특징

유료 플랜을 무료로 2주 체험할 수 있다.
사용자는 여러 개의 팀에 속할 수 있으며, 구독플랜은 팀 별로 적용된다.
팀원수, 네트워크 대역폭 사용량 등 기본 구독료 이외의 추가 사용료를 지불해야 한다.
유료플랜 전환 즉시 선불로 결제가 발생하며, 추가 사용료에 대하서는 이후에 청구된다. (아마 다음 달에 합산하여 청구되는 것으로 추정된다)
청구서에서는 추가 사용료를 항목별로 계산하여 보여준다.
유료 플랜 전환시 신용카드가 등록되어 있지 않으면 카드를 등록하는 UI를 보여준다.

Stytch

Stytch는 Furo와 거의 동일한 서비스라고 할 수 있습니다. 프론트엔드 SDK나 백엔드 API를 이용하여 쉽고 빠르고 안전하게 사용자 인증 기능을 구현할 수 있도록 하는 서비스죠. Furo에서 많이 참고하는 서비스들 중 하나이기도 합니다.

Stytch는 '고객에게 전달하려는 가치' 라는 차원에서 Furo가 가장 방향성이 같은 서비스입니다. 로그인/회원가입 단계에서 고객의 사용자 전환율을 높이고 고객과 함께 성장하겠다는 가치는 MAU 기반의 사용료가 청구되는 가격 정책에 잘 반영되어 있다고 볼 수 있죠.

특징

MAU 기반의 과금 정책을 사용한다.
유료 구독 플랜을 사용하려면 무조건 세일즈 팀에 연락해야 한다.
구독 플랜은 하나의 워크스페이스 단위로 적용된다. (팀 단위로 적용되는 것과 사실상 동일하다)
Alchemy처럼 사용자는 하나의 팀에만 속할 수 있다.
청구서 페이지가 따로 없고 결제페이지 하단에 청구서 목록 정보가 함께 있다.

Auth0

Auth0 역시 Furo와 거의 동일한 서비스로, 사용자 인증 분야의 공룡기업이라고 할 수 있습니다. 2014년에 시드 투자를 받았고, 현재는 7조 가치의 회사가 되었죠.

Furo를 처음 기획할 때부터 많이 참고하였던 서비스이고, MAU 기반의 가격 정책을 사용한다는 점에서 확인하고 넘어갈 필요가 있었습니다.

특징

MAU 기반의 가격 정책을 사용한다.
다른 서비스들보다 상대적으로 세분화되어 있는 네 가지 구독 플랜을 제공한다.
Alchemy와 유사하게 결제 페이지에서 구독 플랜별 특징을 비교할 수 있다.
팀(Auth0에서는 Organization)이 아닌 Tenant(하나의 환경설정이 적용되는 컨테이너 - 지역, 등등... ) 단위로 구독플랜이 적용된다.

정리

다른 서비스들의 결제 UI / UX를 와이어프레임으로 정리해봤습니다. 이를 바탕으로 정리한 Furo 결제시스템의 대략적인 유저스토리와 와이어프레임은 다음과 같습니다.

요약

구독 플랜은 팀 단위로 적용된다.
유료 구독 플랜의 요금은 기본요금과 MAU, Email 전송량 등에 의해 계산되는 추가 금액으로 구성된다.
사용자는 결제 페이지에서 현재 MAU와 Email 전송량 등 리소스 사용량과 예상 결제 금액을 볼 수 있다.
사용자가 유료 플랜을 구독하기 위해서는 신용카드를 먼저 등록해야 한다.
신용카드는 여러 개 등록할 수 있으며, 그 중 대표카드를 지정할 수 있다.
사용자는 신용카드를 결제수단으로 등록할 수 있다.
사용자는 등록한 신용카드로 유료 플랜을 정기결제할 수 있다.
사용자는 Furo에서 지급하는 크레딧을 사용하여 정기결제 비용을 지불할 수 있다.
사용자가 유료 플랜을 구독하면 그 달의 기본 요금을 선불로 지불하고 그 달의 MAU, Email 전송량 등에 의해 계산된 추가 사용요금은 다음 달에 합산되어 청구된다.
사용자는 그 달의 기본요금, 사용량, 할인 내역등이 포함된 청구서 목록과 청구서 상세 내역을 볼 수 있다.

2부 요약

결제 시스템 리서치 포인트

결제수단 등록 화면
결제 내역 화면
유료 플랜 적용 단위

다른 서비스의 결제 시스템 정리

Alchemy, Vercel, Stytch, Auth0 의 결제 시스템을 리서치

유저 스토리 정의

리서치를 바탕으로 Furo에 필요한 유저 스토리 정의

글을 마치며

2부에서는 Furo에 결제시스템을 도입하기 위해 리서치를 하고 유저스토리를 정의했던 과정을 기록해보았습니다! 평소엔 눈여겨보지 않았던 결제 시스템을 알아보는 일 자체가 꽤나 흥미롭고 재미있었던 기억이 나네요. 그런데 돌이켜보면 이 때 와이어프레임과 유저스토리를 더 명확하게 작성했어야 했었습니다. 이후 시스템의 아키텍처와 DB스키나, API 스펙을 설계하는 과정에서 팀원들이 생각하고 있는 유저 스토리와 화면 구성이 모두 조금씩 달라서 혼선이 많았거든요... 🤣🤣🤣 앞으로는 리서치 자체보다는 리서치 이후에 팀원들 모두가 같은 방향으로 달릴 수 있도록 명확한 형태의 산출물을 정리하는 데에 더 힘을 써야겠다는 생각을 해봅니다.

끝까지 읽어주셔서 정말 감사합니다!

다음주에는 "3부 - 결제 대행 서비스 리서치와 선정" 으로 돌아오겠습니다!