암호화폐 결제 연동 테스트는 결제 페이지가 열리는지만 확인하는 작업이 아닙니다. 결제를 검증한 뒤에만 올바른 주문을 정확히 한 번 이행한다는 것을 입증해야 합니다. 메시지 전달 테스트, 애플리케이션의 주문 상태 테스트, 승인받은 실제 자금 인수 검증을 구분하세요. 각각 확인하는 내용이 다릅니다.
이 점검표는 결제 흐름 출시를 준비하는 개발자와 판매자를 위한 것으로, 선택한 자산과 네트워크가 실제로 제공되는 USDC 또는 USDT 결제에도 적용됩니다. 권장 테스트 절차이지, Yolfi가 여러분의 애플리케이션에서 이 테스트를 통과했다거나 완전한 테스트넷 결제 흐름을 제공한다는 보고가 아닙니다.
어떤 종류의 테스트인지 먼저 구분하세요
모의 결제 알림은 블록체인 이체가 아닙니다. 테스트넷 이체는 운영 네트워크의 결제가 아닙니다. 브라우저 리디렉션의 성공도 둘 중 어느 쪽을 의미하지 않습니다.
| 테스트 계층 | 확인할 수 있는 내용 | 확인할 수 없는 내용 |
|---|---|---|
| 통제된 테스트 데이터로 진행하는 애플리케이션 테스트 | 주문 상태 전이, 거부 규칙, 중복 처리 | 제공업체가 배포된 수신기에 접근할 수 있는지 여부 |
| 제공업체 테스트 Webhook | 엔드포인트 접근 가능 여부와 제공업체 테스트 페이로드 처리 | 자금이 이동했는지, 실제 청구서가 결제되었는지 여부 |
| 명시적으로 지원되는 경우의 테스트넷 이체 | 해당 테스트 네트워크에서의 동작 | 운영 자산의 제공 여부나 메인넷 정산 |
| 승인받은 실제 결제 인수 검증 | 실제 운영 결제 한 건에서 관찰한 결과 | 모든 네트워크, 토큰, 장애 상황의 정상 동작 |
Ethereum 네트워크 안내는 계정 잔액과 거래 내역이 독립된 네트워크 사이에서 공유되지 않는다고 설명합니다. 주소가 같아 보여도 테스트넷 자금을 메인넷에서 사용할 수는 없습니다. 일반적인 지갑 테스트가 해당 결제 서비스에도 적용된다고 가정하지 말고 제공업체의 최신 문서를 확인하세요.
테스트 범위를 문서로 먼저 정하세요
무언가를 보내기 전에 애플리케이션 환경, 제공업체 계정, 수신기 URL, 서명 비밀키 보관 위치, 주문 ID와 의도한 부수 효과를 기록하세요. 모의 시나리오에서는 폐기 가능한 고객 레코드를 사용하고 실제 배송, 유료 이용 권한과 고객 이메일 발송을 비활성화하세요.
테스트 설정과 운영 설정을 분리하세요. 서명 비밀키를 글, 스크린샷, 이슈 또는 채팅 기록에 복사하지 마세요. 테스트 증거에는 사용한 비밀키의 버전을 표시하되 값을 노출해서는 안 됩니다. 테스트 실패를 조사한다는 이유로 구매자에게 지갑 복구 문구나 개인키를 요청하지 마세요.
실제 자금 검증은 금액, 수수료, 수신 주소와 담당자에 대해 명시적인 내부 승인을 받은 뒤 진행하세요. 사업자가 통제하는 지갑과 손실을 감당할 수 있는 금액을 사용하세요. 오래된 스크린샷, 자동 생성된 코인 페이지나 비공식 테스트 안내에 나왔다는 이유만으로 특정 주소나 네트워크에 돈을 보내서는 안 됩니다.
주문 금액을 서버가 통제하는지 입증하세요
Yolfi API 결제에서는 판매자 서버가 최종 금액과 통화로 Checkout Session(결제 세션)을 생성합니다. 이후 구매자가 지원되는 네트워크와 토큰을 선택하면 해당 세션에서 Invoice(결제 청구서)가 생성됩니다. 재사용 가능한 Paylink는 서버가 가격을 정하는 동적 주문과 용도가 다릅니다.
동적 장바구니라면 자금 이동을 테스트하기 전에 자체 서버의 가격 계산과 세션 연결을 검증하세요.
- 브라우저가 보낸 합계를 변경해도 서버가 확정한 주문 가격을 덮어쓸 수 없는지 확인하세요.
- 다른 고객의 주문 참조값을 사용해 보고 애플리케이션이 무단 접근을 거부하는지 확인하세요.
- 결제 흐름을 새로고침하거나 다시 열어도 반복된 시도가 의도한 주문에 계속 연결되는지 확인하세요.
- 세션 생성 후 장바구니를 변경하고, 기존 결제 시도를 교체하거나 거부하는 명확한 규칙이 있는지 확인하세요.
이는 애플리케이션의 인수 기준이지, 제공업체 엔드포인트가 가능한 모든 요청을 거부한다는 주장이 아닙니다. 서버의 주문 참조값과 반환된 세션 참조값을 함께 보관하세요. API 필드를 임의로 만들거나 브라우저에서 조작할 수 있는 식별자가 소유권을 증명한다고 가정하지 마세요.
실제 판매를 만들지 않고 테스트 Webhook을 보내세요
현재 Yolfi Webhook 문서는 실제 이벤트와 동일한 전달 경로, 어댑터, 서명 헤더를 사용하는 관리 화면의 테스트 이벤트를 설명합니다. 페이로드에는 livemode: false와 evt_test_로 시작하는 이벤트 ID가 포함됩니다. 이 테스트는 청구서, 결제 이벤트, 구독이나 고객 레코드를 생성하지 않습니다.
이 이벤트로 정산이 아니라 전달과 페이로드 처리를 확인하세요. 수신기가 200 OK를 반환해도 잘못된 이용 권한을 부여하거나 메시지를 조용히 버릴 수 있습니다. 전달 결과뿐 아니라 그 결과로 형성된 애플리케이션 상태도 점검하세요.
문서에 명시된 절차와 엔드포인트별 서명 비밀키로 서명을 검증하세요. 조직 API 키를 사용하는 것이 아닙니다. 운영 주문 이행 경로가 테스트 이벤트를 결제 완료 주문으로 처리할 수 없는지 확인하세요. 격리된 테스트 환경에서 테스트 데이터로 주문 이행을 실행한다면 폐기 가능한 레코드를 사용하고 운영 레코드와 별도로 점검하세요.
Yolfi는 외부에서 접근 가능한 HTTP 또는 HTTPS 수신 주소를 요구하며 리디렉션을 따르지 않습니다. 로컬 개발에는 공개 HTTPS 터널을 사용할 것을 문서에서 권장합니다. 최종 수신기 URL을 정확히 확인하세요. 다른 경로나 로컬 전용 주소로 보낸 요청의 성공은 제공업체의 전달을 입증하지 못합니다.
정상 흐름 스크린샷만 남기지 말고 장애 매트릭스를 사용하세요
제공업체의 테스트 전송 기능이 지원하지 않는 사례는 자체 격리 테스트 환경에서 통제된 테스트 데이터로 실행하세요. 애플리케이션 테스트임을 명확히 표시하고, 만들어 낸 제공업체 이벤트를 실제 결제 증거로 제시하지 마세요.
| 시나리오 | 애플리케이션에서 확인해야 할 결과 |
|---|---|
| 유효한 테스트 이벤트 | 테스트로 기록되며 실제 제공이나 결제 완료 영수증이 없음 |
| 서명 누락 또는 잘못된 서명 | 주문을 변경하기 전에 거부됨 |
| 결제가 시작됐지만 확인되지 않음 | 주문이 미결제 상태로 유지됨 |
| 알 수 없는 주문의 결제 확인 | 조사를 위해 보류하며 고객을 추측해서 연결하지 않음 |
| 동일한 서명 이벤트가 두 번 전달됨 | 영구 저장된 업무 결과는 하나이며 중복 제공이 없음 |
| 두 작업 프로세스가 같은 이벤트를 처리함 | 동시 처리 중에도 주문 이행 결정은 한 번만 이루어짐 |
| 수신기 장애 후 복구 | 중복 이행 없이 복구된 결과를 확인함 |
| 복귀 전에 브라우저가 닫힘 | 결제 처리가 복귀 페이지에 의존하지 않음 |
Yolfi에서 invoice.created는 시작을 나타내며, 문서상 주문 이행을 촉발하는 이벤트는 payment.confirmed입니다. 첫 메시지를 받았다는 이유만으로 주문을 결제 완료 상태로 바꾸지 마세요. Webhook 멱등성 안내는 영구 저장을 통한 중복 제거를 설명합니다. 이 점검표는 구현이 실제로 그렇게 동작하는지 증거를 모으는 데 초점을 맞춥니다.
복구를 의도적으로 테스트하세요. 이벤트를 저장하기 전에 성공을 반환하는 프로세스는 충돌 시 처리할 작업을 잃을 수 있습니다. 완료 기록 전에 상품을 제공하면 재시도 후 중복 제공이 발생할 수 있습니다. 영속성이 있는 처리 설계를 선택한 뒤 중단 지점을 시험하세요. 한 번의 요청 성공이 신뢰성을 입증한다고 가정해서는 안 됩니다.
구매자 안내와 미해결 결제 처리 경로를 확인하세요
휴대전화와 데스크톱에서 실제 결제 흐름을 여세요. 이체 전에 표시 금액, 선택한 자산, 네트워크, 수신 주소와 만료 정보를 이해할 수 있는지 확인하세요. 복사 기능과 QR 스캔을 테스트하되 QR 코드가 모든 송금 지갑을 자동으로 올바르게 설정한다고 가정하지 마세요.
오류 메시지를 테스트하려고 지원하지 않는 토큰을 보내거나, 일부러 잘못된 네트워크를 사용하거나, 되돌릴 수 없는 이체를 하지 마세요. 이러한 고객 문의 상황은 통제된 레코드로 연습하세요. 잘못된 네트워크 결제 예방 안내는 구매자에게 제공할 확인 사항을 설명합니다.
미결제 또는 만료된 주문을 연습하세요. 구매자에게는 근거 없는 자금 복구 약속이 아니라 명확한 상태와 안전한 다음 단계가 안내되어야 합니다. 만료된 청구서 처리 절차를 참고해 다시 결제를 요청하기 전에 무엇을 조사할지 정하세요. 첫 시도 상태가 불분명하다고 두 번째 결제를 자동으로 요구해서는 안 됩니다.
승인받았다면 실제 결제 인수 검증 한 건을 기록하세요
선택한 운영 자산과 네트워크를 실제 결제 흐름에서 사용할 수 있는지 확인한 뒤에만 진행하세요. 필요한 네트워크 수수료를 고려하고 수신 주소를 사업자가 통제하도록 하세요. 제공업체 테스트 Webhook의 성공은 검증되지 않은 경로로 실제 자금을 보내도 된다는 근거가 아닙니다.
주문과 결제 참조값, 실제 자산과 네트워크, 금액, 관찰한 확인 상태, 수신 지갑 증거와 최종 주문 이행 상태를 기록하세요. 모든 상황에 적용되는 확인 횟수나 정산 시간을 약속하지 마세요. 지갑 스크린샷만 보지 말고 실제로 관찰한 결과를 확인하세요.
그다음 해당 결제를 주문 및 영수증 기록과 대조하세요. 대사 점검표는 입금된 자금, 주문별 배분액과 수수료를 구분하는 데 도움이 됩니다. 인수 검증 결제액을 환불할 계획이라면 환불을 별도로 승인하고 검증하세요. 자동 취소된다고 가정해서는 안 됩니다.
검증 통과가 입증하는 것은 특정 시점에 관찰한 경로 하나뿐입니다. 결제 로직, 수신기 배포, 비밀키나 지원 경로가 바뀌면 관련 인수 테스트를 반복하세요. USDC 결제 한 건이 성공했다고 모든 USDT 네트워크가 작동한다는 증거로 일반화해서는 안 됩니다.
출시 검증 증거를 보관하세요
테스트한 애플리케이션 버전, 환경, 시나리오, 예상 결과, 실제 결과와 미해결 문제를 간단한 보고서로 남기세요. 고객 식별자나 전체 지갑 내역을 공개하지 말고 비공개 로그와 주문 기록으로 연결하세요.
테스트 이벤트가 운영 주문을 이행할 수 있거나, 중복 이벤트로 두 번 제공될 수 있거나, 잘못된 서명이 상태를 바꿀 수 있거나, 확인된 결제를 안전하게 매칭할 수 없다면 출시를 막으세요. 각 미해결 항목에 담당자를 지정하세요. 녹색 전달 성공 표시는 이런 업무 결과를 대신할 수 없습니다.
자주 묻는 질문
Yolfi 테스트 Webhook은 암호화폐를 이동시키나요?
아닙니다. 문서에 설명된 테스트는 청구서나 결제 기록을 생성하지 않고 전달과 페이로드 처리를 검증합니다. 실제 블록체인 결제가 성공했다는 증거는 아닙니다.
테스트넷 결제는 결제 서비스 샌드박스와 같은가요?
아닙니다. 테스트넷은 별도의 블록체인 네트워크이며, 제공업체 샌드박스는 해당 서비스 전용 환경입니다. 필요한 특정 모드를 제공업체가 지원하는지 확인하세요. 이 글은 Yolfi가 테스트넷 결제 흐름을 제공한다는 근거가 아닙니다.
결제 페이지에서 리디렉션이 성공하면 출시해도 되나요?
그 근거만으로는 부족합니다. 서버 측 결제 처리, 주문 매칭, 중복 방지와 장애 복구를 검증하세요. 구매자가 복귀 페이지가 열리기도 전에 브라우저를 닫을 수 있습니다.
모든 장애를 실제 돈을 보내서 테스트해야 하나요?
아닙니다. 격리된 애플리케이션 테스트와 문서화된 제공업체 시뮬레이션으로 장애 처리를 검증하세요. 실제 결제 인수 검증에는 승인과 지원 경로 확인이 필요하며, 일부러 잘못된 네트워크로 이체하는 것은 적절한 테스트가 아닙니다.
결론: 출시 전에 업무 결과를 검증하세요
범위를 명확히 정하고 서버 측 주문 처리를 입증하며 모의 이벤트와 검증된 자금을 구분하세요. 적합한 고정가 상품에는 Yolfi 결제 링크를, 동적 주문에는 문서에 명시된 API 흐름을 사용하세요. 그런 다음 브라우저 리디렉션이 아니라 결제 처리가 주문 이행을 통제한다는 증거를 보관하세요.
