앱에서 돈 받기 - 결제 수납을 위한 쉬운 안내서
AI로 만든 앱에서 결제를 받는다는 건 Stripe 같은 결제 서비스와 연결한다는 뜻입니다. 카드 입력 폼을 띄우고 돈을 옮기는 일은 그쪽이 맡고, 당신의 앱은 주문을 기록하고 결제가 확인되면 그에 맞게 반응하기만 하면 됩니다.
당신의 앱이 프로젝트에서 비즈니스로 바뀌는 특정한 순간이 있습니다. 누군가 처음으로 그 앱을 통해 당신에게 돈을 지불하는 순간입니다. 그리고 그건 버그가 그저 민망한 것에서 “내 돈을 가져가 놓고 나는 아무것도 못 받았다”로 바뀌는 순간이기도 합니다. 결제 수납은 대부분의 빌더가 추가하게 될 기능 중 판돈이 가장 큰 기능이지만, 다행히 어렵고 무서운 부분은 사실 당신이 직접 만들 필요가 없습니다. 그저 제대로 연결하고, 지루한 예외 상황들을 건너뛰지만 않으면 됩니다.
이 글은 AI로 만든 앱에서 결제를 수납하는 것에 대한 쉬운 안내서입니다. 실제로 내부에서 무슨 일이 일어나는지, 잘못될 수 있는 세 가지, 그리고 처음에 갖춰야 할 한 가지 설정을 다룹니다.
”결제 받기”는 정확히 무엇을 의미할까요?
결제를 받는다는 것은 결제 시스템을 직접 만드는 대신 결제 서비스 제공업체와 앱을 연결한다는 뜻입니다 — 대부분의 사람들이 선택하는 곳은 Stripe이고, 무난한 기본값입니다. 여기서 역할 분담이 이렇게 되는데, 이걸 이해하는 게 가장 안심되는 부분입니다.
결제 서비스가 카드 입력 폼을 보여줍니다. 결제 서비스가 카드 번호를 받고, 확인하고, 돈을 옮깁니다. 그런 다음 결제 서비스는 당신의 앱에 딱 한 가지만 알려줍니다. “이 사람이 당신에게 4만 원을 지불했습니다.” 당신의 앱은 카드 번호를 절대 보지도, 저장하지도, 건드리지도 않습니다. 이건 한계가 아니라 전체 핵심입니다. 카드 데이터는 법적으로도 보안적으로도 지뢰밭이고, 그걸 완전히 결제 서비스 안에만 두면 그 지뢰밭은 당신 일이 아니라 그쪽 일이 됩니다. 만약 당신의 빌더가 “카드 정보를 당신의 데이터베이스에 저장해 드릴게요”라고 제안한다면, 답은 언제나 안 됩니다입니다.
그러니 결제에서 당신의 앱이 실제로 해야 할 일은 작습니다. 고객을 결제 서비스의 체크아웃 화면으로 보내고, 결제 서비스가 돈이 들어왔다고 알려주면 그에 맞게 정확히 반응하는 것.
일회성 결제부터 시작해야 할까요, 구독부터 시작해야 할까요?
일회성 결제부터 시작하세요. 구독과 핵심 배선은 똑같지만 정기 결제 특유의 예외 상황은 하나도 없고, 대부분의 첫 제품은 “한 번만 내면 그걸 받는다”만 있으면 충분합니다. 구독은 나중에, 매달 돈을 낼 만한 가치가 있는 것을 정말로 갖췄을 때 의도적으로 추가하세요.
거의 모든 경우를 두 가지 결제 형태가 커버합니다.
- 일회성 결제 — 티켓, 템플릿, 1회 코칭 세션, 다운로드 가능한 가이드를 구매하는 경우. 돈이 한 번 움직이면 끝입니다.
- 구독 — 월간 멤버십, 정기 요금제. 돈이 매달 자동으로 움직인다는 뜻이고, 그건 곧 “카드가 만료되면 어떻게 되나”, “취소하면 어떻게 되나”, “이번 달 결제가 실제로 처리되긴 했나” 같은 문제까지 함께 떠안았다는 뜻입니다.
AI로 만든 앱에서 가장 흔한 결제 실수는 무엇인가요?
AI로 만든 앱에서 벌어지는 결제 문제는 거의 전부 세 가지 실수로 귀결됩니다. 결제가 일어났다는 사실을 앱이 잊어버리는 것, 영수증이 없어서 고객이 두 번 결제하는 것, 그리고 실제 돈으로 성공 케이스만 테스트하는 것. 각각에 대해 빌더에게 그대로 붙여넣을 수 있는 쉬운 지시문이 있습니다.
1. 결제는 되는데 앱이 잊어버린다. 고객이 결제하고, 돈은 당신의 결제 서비스 계정에 들어오는데 — 당신의 앱에는 누가 무엇을 결제했는지에 대한 기록이 전혀 없습니다. 어느 워크숍 주최자는 이런 식으로 티켓 30장을 팔았고, 결국 Stripe에는 돈이 있는데 스프레드시트에는 이름이 하나도 없는 상황이 됐습니다. 누구를 문 앞에서 들여보내야 할지 전혀 알 수 없었죠.
해결책은 이렇습니다. 결제가 확인되는 순간, 주문 기록을 저장하세요 — 누가 결제했는지, 무엇을 샀는지, 얼마를 냈는지, 언제인지, 그리고 명확한 “결제 완료: 예”까지. 빌더에게 이렇게 요청하세요. “결제가 성공하면 고객, 상품, 금액, 결제 상태가 담긴 주문 기록을 만들어줘. 고객이 감사 페이지로 돌아오는 것에 의존하지 말고, 결제 서비스의 결제 확인 신호에 의존해줘.” 이 마지막 부분이 중요합니다 — 사람들은 탭을 닫고, 연결이 끊기고, 실수로 두 번 클릭하기도 합니다. 돈이 실제로 움직였다는 신뢰할 수 있는 신호는 결제 서비스가 당신의 앱으로 직접 보내는 메시지(웹훅)이지, 고객의 브라우저가 성공 화면으로 다시 돌아오는 것이 아닙니다.
2. 영수증이 없어서 두 번 결제한다. 어떤 사람이 결제 버튼을 누르고, 로딩 스피너를 보고, 이메일도 확인 메시지도 아무것도 못 받으면 — 실패했다고 생각하고 다시 결제합니다. 이제 당신은 하나를 환불해야 하고, 그 사람은 당신을 덜 신뢰하게 됩니다. 빌더에게 이렇게 요청하세요. “결제가 완료되는 순간 확인 이메일을 보내고, 결제가 완료됐다는 것과 다음에 무슨 일이 일어나는지를 명확히 보여주는 화면을 표시해줘.” 결제 후의 침묵은 당신의 앱에서 가장 비싼 침묵입니다.
3. 실제 돈으로 테스트한다. 이게 조용히 망가진 채로 출시되는 원인입니다. 빌더들은 자기 카드로 자기 제품을 직접 구매해서 체크아웃을 테스트하고, 한 번 성공하는 걸 보고 완료라고 선언합니다 — 카드가 거절되거나 결제가 환불됐을 때 무슨 일이 일어나는지는 한 번도 확인하지 않고요. 어떤 앱은 카드가 거절됐는데도 주문을 “결제 완료”로 표시했습니다. 아무도 그 경로를 테스트하지 않았기 때문이죠. 고객은 제품을 공짜로 받았고, 창업자는 월말이 되어서야 그 사실을 알게 됐습니다.
이걸 테스트하는 데 실제 돈은 전혀 필요 없습니다. 모든 결제 서비스에는 테스트 모드가 있고, 가짜 카드 번호가 준비되어 있습니다 — 일부러 거절되도록 설계된 번호도 있어서, 당신의 앱이 어떻게 반응하는지 직접 볼 수 있습니다. 빌더에게 이렇게 요청하세요. “체크아웃 전체를 먼저 테스트 모드에서 만들고 테스트해줘. 성공 케이스뿐 아니라 카드 거절 케이스와 환불 케이스도 처리해줘.” 테스트 모드는 결제 관련 세계 전체에서 가장 저평가된 기능입니다.
조용히 넘어가는 부분: 이제 당신은 사업자입니다
사람들이 잊어버리는 두 가지가 있습니다. 첫째, 실제로 돈을 받으려면 결제 서비스에 당신의 진짜 정보가 필요합니다 — 지급받을 사업자 계좌나 은행 계좌 같은 것들이죠. 이건 앱이 알아서 만들어주는 게 아니라 한 번 직접 작성해야 하는 양식입니다. 둘째, 벌어들인 돈에 대한 세금은 당신이 처리해야 할 몫이지, 앱이 알아서 해줄 일이 아닙니다. 둘 다 어렵지는 않지만, 아무도 미리 말해주지 않으면 둘 다 놀랄 만한 일입니다.
결제를 추가할 때 가장 먼저 무엇을 만들어야 할까요?
가장 먼저 딱 하나만 만드세요. 상품 하나, 가격 하나, 일회성 결제 하나, 테스트 모드로. 그 경로가 깔끔하게 작동할 때까지 — 돈이 “움직이고”, 주문이 기록되고, 확인 메시지가 뜰 때까지 — 장바구니, 쿠폰, 요금제 단계, 구독은 참으세요. 카드 거절을 한 번도 견뎌본 적 없는 기능 풍부한 체크아웃보다, 제대로 작동하는 그 하나의 경로가 훨씬 값집니다.
그런 다음 낯선 사람 테스트를 두 번 해보세요. 먼저, 거절되도록 되어 있는 카드 번호로 테스트 모드에서 체크아웃해보세요 — 당신의 앱이 진실을 말하나요(“결제가 처리되지 않았습니다”), 아니면 거짓말을 하고 주문을 결제 완료로 표시하나요? 그다음 성공하는 테스트 구매를 해보세요 — 당신이 고객이라면 믿을 만한 주문 기록과 확인 메시지를 받았나요?
결제 수납은 당신이 추가할 기능 중 가장 무섭게 느껴지지만, 실제로는 실패 모드 세 가지와 그걸 전부 공짜로 리허설해볼 수 있는 테스트 모드가 딸린 배선 작업일 뿐입니다. 돈을 낼 만한 가치가 있는 그 하나를 고르고, 테스트 모드 체크아웃 하나를 연결한 다음, 진짜 카드가 닿기 전에 가짜 판매를 처음부터 끝까지 — 거절된 카드까지 포함해서 — 통과시켜보세요. 그게 첫 번째 할 일의 전부입니다.