Plugin 진입점
결제 기능은 독립된 서비스로 마케팅되는 것이 아니라 채팅의 플러그인 선택기에서 시작됩니다.
결제 기능
결제 기능은 결제 버튼을 추가하는 것 이상입니다
현재 코드베이스를 기준으로 We0.ai는 플러그인 진입점을 통해 실제 생성 경로로 결제 기능을 라우팅할 수 있습니다. 사용자가 채팅에서 플러그인을 활성화하면 프론트엔드는 표시되는 지시문과 숨겨진 agentPrompt를 모두 백엔드로 전달합니다. 백엔드는 해당 기능을 시스템 프롬프트에 주입하므로, 생성된 결과는 체크아웃, 결제 창, 콜백 검증, 결과 조회, 플랜 연결을 포괄하는 연결된 경로에 더 가까워집니다. 이는 결제를 더 이상 후반 단계의 패치로 취급할 필요가 없으며, 훨씬 더 이른 시점에 정식 제공 및 수익화 검증에 들어갈 수 있음을 의미합니다.
코드에서 이미 확인된 핵심 노드
이 페이지는 실제 구현을 기반으로 합니다. 저장소에는 플러그인 진입, 메시지 패스스루, 결제 API, 결제 팝업, 콜백 처리를 위한 구체적인 코드가 이미 포함되어 있습니다.
2계층 프롬프트 패스스루
프론트엔드는 표시되는 플러그인 텍스트를 메시지에 추가하고, 숨겨진 XML로 package와 agentPrompt도 전송합니다.
결제 API 경로
프로젝트에는 /api/payment/checkout, /api/payment/webhook, /api/payment/result 같은 핵심 라우트가 이미 포함되어 있습니다.
결제 창 피드백
현재 구현은 결제 페이지 실행, 동일 출처 결과 게시, 성공 또는 취소 처리, WeChat 결제 조회를 이미 포괄합니다.
플러그인 진입부터 생성된 결제 코드까지 플로우가 작동하는 방식
핵심 아이디어는 마케팅 문구가 아닙니다. 이는 메시지 구성, 시스템 프롬프트 주입, 런타임 결제 코드에 연결된 명시적인 기능 경로입니다.
사용자가 plugin을 활성화
plugin-select-button에서 플러그인을 선택하면, 인라인 또는 대화상자 매개변수가 메시지가 제출될 때까지 프론트엔드에 저장됩니다.
메시지에 기능 정보 포함
제출 시 플러그인 텍스트는 메시지 본문에 추가되고, package와 agent_prompt는 enabled-plugins XML에 첨부됩니다.
Backend가 결제 기능 삽입
백엔드는 마지막 사용자 메시지에서 enabled-plugins를 파싱하고, 전달된 agent_prompt를 읽은 뒤 이를 시스템 프롬프트에 병합합니다.
연결된 결제 경로가 생성됨
그런 다음 결과는 가격 구성, 체크아웃 생성, 웹훅 검증, 결제 결과 조회, 프론트엔드 결제 창 상호작용을 중심으로 계속 이어질 수 있습니다.
생성된 결제 플로우가 단순히 "결제를 지원합니다"라고 말하는 것과 다른 이유
사용 가능한 결제 기능은 버튼 스타일링의 문제가 아닙니다. 결제 전후의 코드 경로가 실제로 연결되어 있는지에 달려 있습니다.
| 차원 | 생성된 결제 플로우 | 분리된 결제 설명 |
|---|---|---|
| 활성화 | 플러그인 진입점에서 명시적으로 활성화되고 생성 플로우 전반에 전달됨 | 프롬프트에 모호하게 언급되어 구현 시점에 쉽게 누락됨 |
| 코드 랜딩 지점 | 체크아웃, 웹훅, 결과, 결제 창 노드에 매핑 가능 | 버튼이나 개념적인 문장에서 멈추는 경우가 많음 |
| 런타임 루프 | 결제 실행, 결과 반환, 주문 조회, 콜백 처리를 포괄함 | 프론트엔드와 백엔드 사이에 큰 공백을 남김 |
| 가장 적합 | 수익화로 이동하는 프로덕션 프로젝트에 더 적합함 | 초기 데모에만 적합함 |
해결하는 문제
- 결제 요구사항을 모호한 요구가 아니라 추적 가능한 생성 진입점으로 전환합니다.
- 프론트엔드에는 버튼이 있지만 백엔드에는 실제 플로우가 없는 간극을 줄입니다.
- 체크아웃, 웹훅, 결과 조회, 결제 페이지 상호작용을 함께 구현하기 쉽게 만듭니다.
- 인증, 플랜, 크레딧 또는 기타 수익화 루프가 필요한 프로젝트에 적합합니다.
- 프로젝트가 가격과 전환 경로를 훨씬 더 일찍 검증하도록 돕습니다.
프로젝트에서 개선되는 점
많은 웹사이트 프로젝트는 초기 단계에서 페이지와 콘텐츠만 검증합니다. 수익화가 필요해질 때쯤 결제, 요금제, 주문, 결과 피드백에 또 한 번의 엔지니어링 작업이 필요하다는 것을 알게 됩니다. 생성된 결제 플로우의 장점은 이러한 핵심 부분이 더 일찍 구조에 포함되어, 프로젝트가 보여줄 수 있는 상태에서 판매 가능한 상태로 더 자연스럽게 이동할 수 있다는 점입니다.
더 이른 수익화 검증
결제가 더 일찍 생성 범위에 포함되면, 팀은 구독, 구매, 충전 플로우를 훨씬 빨리 검증할 수 있습니다.
출시 전 막판 재작업 감소
결제가 동일한 생성 경로의 일부가 되면, 팀은 체크아웃, 콜백, 결과 조회를 패치하기 위해 최종 출시 단계까지 기다릴 필요가 없습니다.
요금제, 크레딧, 계정 로직에 더 잘 맞음
페이지가 이미 확정된 뒤 구조 변경을 강요하는 대신, 결제를 가격 요금제, 크레딧 사용, 계정 권한, 수익화 구조와 함께 더 자연스럽게 설계할 수 있습니다.
더 완성도 높은 프로덕션 제공
소개 페이지만 만드는 것과 비교해, 생성된 결제 플로우는 프로젝트가 거래하고, 전환하고, 계속 운영될 수 있는 상태에 더 가까워지도록 돕습니다.
성장과 전환 루프를 더 일찍 완성
결제가 더 일찍 포함되면, 트래픽에서 가입, 구매로 이어지는 경로를 별도의 관심사가 아닌 하나의 전환 루프로 설계하기가 더 쉬워집니다.
사용 사례
- 구독, 일회성 구매 또는 크레딧 충전이 필요한 제품 사이트
- AI 생성 범위 안에 결제를 포함하려는 SaaS 사이트와 MVP
- Stripe, Creem 또는 WeChat Pay 통합 가이드가 필요한 프로젝트
- 말로만 "결제를 지원합니다"라고 주장하는 데서 멈추면 안 되는 프로덕션 제공 시나리오
- 가격 모델, 멤버십 제안, 전환 루프를 더 일찍 검증하려는 제품 팀
Ready to turn an idea into a live site?
Start from one sentence and have a complete website in minutes.