“결제만 붙이면 돼요”라는 말을 자주 듣습니다. 화면으로 보면 버튼 하나라서 그렇게 느껴집니다. 그런데 결제는 서비스에서 가장 손이 많이 가는 기능 중 하나입니다. 미리 알고 시작하면 일정이 안 밀립니다.
개발보다 심사가 오래 걸립니다
결제를 붙이려면 PG사 심사를 통과해야 합니다. 사업자등록증, 판매하는 상품 정보, 이용약관, 환불 규정 같은 서류가 필요합니다.
여기서 일정이 밀리는 경우가 많습니다. 개발은 며칠이면 되는데 심사가 일주일 이상 걸립니다. 그래서 저희는 프로젝트를 시작할 때 결제 심사부터 먼저 넣으시라고 안내드립니다. 개발과 심사를 같이 돌리면 일정이 겹쳐서 손해가 없습니다.
결제는 “성공”보다 “실패”가 중요합니다
정상적으로 결제되는 흐름은 어렵지 않습니다. 진짜 일은 나머지에 있습니다.
- 사용자가 결제 창을 중간에 닫았을 때
- 카드사에서 승인이 거절됐을 때
- 결제는 됐는데 우리 서버로 결과가 안 왔을 때
- 같은 주문을 두 번 결제했을 때
특히 세 번째가 무섭습니다. 사용자 돈은 빠져나갔는데 우리 서비스에는 기록이 없는 상태입니다. 이걸 막으려면 결제 결과를 앱에서 받은 값으로만 믿으면 안 되고, 서버가 PG사에 직접 다시 물어봐서 확인해야 합니다.
결제 성공 여부는 사용자의 화면이 아니라 서버가 확인한 값으로 판단합니다.
환불 규칙을 먼저 정하세요
개발보다 먼저 정해야 하는 건 정책입니다.
- 언제까지 환불이 되나요?
- 부분 환불이 있나요?
- 이미 사용한 서비스는 어떻게 계산하나요?
이게 안 정해진 상태로 개발을 시작하면, 나중에 로직을 통째로 다시 짜게 됩니다. 화면 몇 개 바꾸는 수준이 아니라 데이터 구조가 바뀝니다.
실제로 써본 방식
리워드 마케팅몰에서는 광고비를 미리 충전해 두고 주문할 때 차감하는 구조를 썼습니다. 신용카드는 토스페이먼츠로 연동하고, 무통장 입금도 같이 지원합니다.
미리 충전하는 방식은 장점이 분명합니다. 주문할 때마다 결제 창이 뜨지 않아 흐름이 끊기지 않고, 정산도 단순해집니다. 대신 “충전 잔액”이라는 개념이 생기니 잔액 기록을 정확하게 남기는 게 중요해집니다.
앱은 규칙이 하나 더 있습니다
앱에서 디지털 상품을 팔면 스토어 결제를 써야 하는 경우가 있습니다. 실물 상품이나 오프라인 서비스는 일반 결제가 되지만, 앱 안에서만 쓰는 재화는 애플과 구글의 결제를 통해야 합니다.
이걸 모르고 만들면 심사에서 막힙니다. 무엇을 파는지에 따라 처음부터 다르게 설계해야 합니다.
정리
- 심사를 먼저 넣고 개발을 같이 진행합니다.
- 실패와 중복 상황을 먼저 설계합니다.
- 결제 결과는 서버가 다시 확인합니다.
- 환불 정책을 개발 전에 정합니다.
- 앱이면 스토어 결제 규칙을 먼저 확인합니다.
결제는 잘 되면 티가 안 나고, 한 번 잘못되면 크게 티가 나는 기능입니다. 그래서 처음에 시간을 쓰는 게 맞습니다.