토스페이먼츠 결제 연동 후 PG창 최초 진입 시
저희 홈페이지에서 결제방식(신용카드 (SC0010) or무통장입금 SC0040 )을 선택해서 들어가더라도
"로컬(테스트)" 에서는 결제 방법을 선택해주세요. [계좌이체] [신용체크카드] [가상계좌] [Foreign Card] 와 같이 선택할 수 있는 화면이 나오고 (이미지 참고)
운영에서는 해당 선택할 수 있는 화면이 나오지는 않고, 무통장입금(SC0040)을 선택했다면 곧바로 입금할 은행 선택 화면이 나와요.
두 환경에서는 왜 다르게 나오는지 알 수 있을까요?
이미지 참고 해주세요.!!
33 Replies
⏳ 잠시만 기다려주세요! 곧 답변드리겠습니다
오류 문의일 경우 아래 정보를 미리 전달해주시면, 빠른 답변에 도움이 됩니다.
- 주문번호(orderId) :
- 문의 내용 :
(img를 함께 첨부해주시면 도움이됩니다)
* 계약관련 내용은 1544-7772로 문의주세요.
* 주말/공휴일에는 답변이 늦을 수 있어요.
SC0040 과 같은 결제코드가 확정되어 있지 않을경우에는
좌측처럼 "바둑판" 이라는 창이 제공됩니다.
만약 테스트 환경에서 결제코드 확정했다면,
추가로 XPay 상점관리자 설정에 따라 갑니다.
답변 감사합니다.
무통장입금 결제방식을 선택하고 토스페이먼츠 PG창 진입할떄는
$("input[name='LGD_CUSTOM_USABLEPAY']").val("SC0040");
와 같이 결제코드를 확정하고 진입을 하거든요. (로컬/운영환경 동일)
두 환경이 같은 소스라서 모두 결제 코드를 확정하고 진입을 하게 되는데
XPay 상점관리자 설정은 어떻게 확인할 수 있을까요??
참고로 로컬(테스트)환경에서 PC버전, 모바일 버전이 나뉘는데...
PC버전에서는 바둑판 형태가 제공되지 않고 모바일에서만 바둑판 형태가 제공돼요..
원하시는 바가 "바둑판을 보기싫다" 가 맞을까요?
바둑판이 안보였으면 좋겠는것은 아니구요.
며칠 전(02.14) 운영환경에서 한가지 이슈 사항이 있었는데, 해당 내용을 파악 중입니다.ㅜㅜ
저희 소스 상에 정해진 규칙에 따라
토스페이먼츠로 전달되는 주문번호 형태는
신용카드는 [ undefined_1589_786_20250214140214e49f ] 와 같은 형태로,
가상계좌는 [2025-02-000032-ABCD] 와 같은 형태로 전송이 되거든요.
정상적이라면 위와 같은 형태로 전달이 되어야 맞는데..
가상계좌로 신청한 건이 신용카드처럼 [ undefined_1589_786_20250214140214e49f ] 와 같은 형태로 주문번호가 전달 되는 현상이 있어서요.
로컬환경에서 여러번 테스트를 해보니 위와 같은 현상은
저희 사이트 내에서 결제방식을 신용카드(SC0010)를 선택하여 토스페이먼츠결제 창으로 진입하고,
바둑판에서 가상계좌를 선택하고 완료 시에 위와 같은 현상이 발생하더라구요.
(즉 결제방식 '신용카드'로 토스페이먼츠 진입 > 바둑판에서 '가상계좌' 선택)
다시 말해, 최초 질문드린 내용처럼
로컬환경과는 달리 운영환경에서는 바둑판 형태로 선택이 되지 않고 있어서, 위와 같은 현상이 발생할 수 가 없는데
혹시나 제가 모르는 진입경로로 운영환경에서도 바둑판 형태가 노출이 되고 있지 않나 싶어서요.
며칠동안... 발생한 이 이슈 때문에 정말 다방면으로 확인을 하고 있는데....
방금 말씀드린 위 케이스 말고는 재현이 되지 않거든요...ㅠㅠ
음 운영환경에서는 나올수가 없는데
어째서 가맹점에서 인지하고 있는 수단별 주문번호가 아니라
뜬금없는 다른 수단의 주문번호로 결제가 인입되었는가, 이거군요.
undefined_1589_786_20250214140214e49f 이게 그 주문번호 인가요?
잠시만요!
undefined_1589_786_20250214140237fc51
저희가 제주아트센터 결제 시스템을 관리하는데,
평소에 이와 같은 이슈가 나오지 않다가... 이번에 유독 인기 많은 공연이라
예매가 몰리는 시간대 14:00 ~ 14:20 사이에 발생했거든요.
대략 이와 같은 증상이 30~40건 발생했습니다 ㅜㅜ 그중에 예시 주문번호는 위와 같습니다.
예상으로는 신청하고자 하는 사람이 많아.. 좌석이 충돌 나면서 현상이 발생한 것 같습니다..
지금도 그렇고 14:20 이후로도 위와 같은 현상이 발생하지는 않았거든요...
좌석 충돌 케이스를 정말 다방면으로 테스트를 다해봤는데도..
해당 현상이 나타나지는 않는데..... 😭
undefined_1589_786_20250214140237fc51
바둑판이 노출 되어야 하지만 모바일 바둑판 제외 청약으로 사용 가능한 결제 수단 >> [VIRTUAL_ACCOUNT]
* 바둑판 노출로 요청이 들어옴
* 그런데, 청약으로 모바일에서는 바둑판 보이지 않도록 설정 되어 있음
* 동시에, LGD_CUSTOM_FIRSTPAY=SC0040 라고 요청 파라미터에 존재
* 이로 인해, "가상계좌" 결제창이 뜬 것으로 보여짐
해결방안
* LGD_CUSTOM_FIRSTPAY 을 사용하지 않도록 요청 파라미터 삭제
* 특정 결제수단으로 창을 띄우고 싶을때는 LGD_CUSTOM_USABLEPAY을 사용
카드
LGD_CUSTOM_USABLEPAY=SC0010
가상계좌
LGD_CUSTOM_USABLEPAY=SC0040
헐... 그러면 실제로 대상자(사용자)에게 바둑판이 노출되었던게 맞나요??....
제가 물려받은 프로젝트라.....
기존 케이스 별로
LGD_CUSTOM_FIRSTPAY 값에
SC0010(신용카드)
SC0030(계좌이체)
SC0040(가상계좌) 값이 들어가 있던데...
"LGD_CUSTOM_FIRSTPAY" 를 사용하지 않도록 하고
대체로 "LGD_CUSTOM_USABLEPAY" 을 써야 맞는가요?
대상 주문번호를 가진 사용자에게 바둑판 형태로 노출된 것으로 확인이 되나요....?ㅠㅠ
요청이 바둑판으로 띄우는 요청이었는데,
청약으로 바둑판 뜨지 않도록 막혀 있었고,
동시에 LGD_CUSTOM_FIRSTPAY 가 전달 되어서,
바둑판으로 뜨지않고 가상계좌 창으로 뜬것이라고 이해해주시면 될것 같아요
LGD_CUSTOM_FIRSTPAY 를 사용하지 않고
LGD_CUSTOM_USABLEPAY 사용하시면
바둑판 안뜨고 원하는 창으로 뜨게 될겁니다
혹시 정말 죄송하지만
청약으로 바둑판 뜨지 않도록 막혀 있었다는 것이 무슨 뜻인지 알수있을까요...??
청약.......
기존 FIRSTPAY로도 잘 동작 되고 있다가 ..
결제창 요청이 많은 경우에 이럴 수가 있는건가 해서요...ㅠㅠ
문제가 있었던 주문번호를 몇개 더 주시면 확인할 수 있을것 같아요.
undefined_1589_786_2025021414035642db
undefined_1589_786_202502141405461002
undefined_1589_786_20250214140425cd94
undefined_1589_786_20250214141031f7f5
undefined_1589_786_202502141410283ee2
undefined_1589_786_202502141408209c20
도와 주셔서 감사합니다 ㅠㅠ..
혹시
LGD_CUSTOM_FIRSTPAY 와 LGD_CUSTOM_USABLEPAY
두 개의 차이점이 뭔지 가이드 같은 걸 받아볼 수 있을까요? 가이드가 없어서요...
LGD_CUSTOM_FIRSTPAY 는 유플러스 PG에서도 아주 오래전 파라미터로 더이상 사용하지 않는 파라미터입니다.
현재는 LGD_CUSTOM_USABLEPAY 만 사용하도록 되어 있는데, 드물게 예전 가맹점 코드에 남아 있어 사용하시는 경우도 있었습니다.
감사합니다.
LGD_CUSTOM_USABLEPAY 으로 명칭 대체 하도록 하겠습니다.
위에 말씀드린 주문번호도 같은 현상으로 발생했는지 확인 해주실 수 있을까요...?
네, 모두 같은 케이스에 해당합니다.
전부 LGD_CUSTOM_FIRSTPAY=SC0040 로 확인됩니다
감사합니다.
그런데 하나 의문이 드는 사항이..
기존 소스에는 LGD_CUSTOM_FIRSTPAY=SC0040 으로 되어 있었지만,
제가 테스트 할 때, 실제 운영환경에서 바둑판 형태가 아닌 바로 입금은행 선택하는 화면으로 진입을 했었거든요.
그런데..
간헐적으로 최초 진입 페이지가 " 바둑판형태 " 이거나 " 입금은행 선택화면 " 일수가 있나요? 제가 몇번 테스트를 해봐도 줄곧 입금은행 선택화면 으로 나왔거든요. 위 예시 주문번호 케이스에서 사용자에게 바둑판 형태가 제공된 것이 맞는건가 싶어서요....
간헐적으로 최초 진입 페이지가 " 바둑판형태 " 이거나 " 입금은행 선택화면 " 일수가 있나요? 제가 몇번 테스트를 해봐도 줄곧 입금은행 선택화면 으로 나왔거든요. 위 예시 주문번호 케이스에서 사용자에게 바둑판 형태가 제공된 것이 맞는건가 싶어서요....
바둑판형태 이거나LGD_CUSTOM_USABLEPAY 에 별도 결제수단 하나만 특정하지 않으면 값에 포함된 결제수단이 바둑판형식으로 보여집니다.
입금은행 선택화면은 LGD_CUSTOM_USABLEPAY 에 가상계좌 결제수단을 넘겨주셨을꺼에요. 이건 특정 상점에만 예외가 아니라 전체 가맹점에 해당되는 내용이라서 모두 같습니다.
바쁘실텐데 답변 달아주셔서 감사합니다...
제가 설명 부족으로 .. 답변이 저희 오류 상황과 맞는지 명확하지가 않아서요.
하나만 더 여쭤보겠습니다! 이 부분만 확인이 된다면 명확 할 것 같아요.
토스페이먼츠 측에서 확인이 될지는 모르겠지만........
위 주문번호 예시 사용자들은
최초 토스페이먼츠 PG창 진입 전,
'신용카드(SC0010)' 혹은 '계좌이체(SC0020)' 을 선택하여 PG창 진입하였고,
바둑판 형태에서 '가상계좌'(SC0040) 선택한 케이스 인가요? 확인이 될까요?
LGD_CUSTOM_USABLEPAY = SC0010 (카드)
또는
LGD_CUSTOM_USABLEPAY= SC0030 (계좌이체)
를 파라미터 값에 담겨 결제요청이 들어왔다면 가상계좌 결제는 발생할 수 없습니다.
LGD_CUSTOM_USABLEPAY = SC0010-SC0030 이면 카드나 계좌만 선택할 수 있는 바둑판
LGD_CUSTOM_USABLEPAY = SC0010-SC0030-SC0040 이면, 카드, 계좌, 가상계좌를 선택할 수 있는 바둑판
위 코드로 지정하면 된다고 스펙 문서상 되어 있고,
지금은 굳이 안되는 케이스를 찾아서 만드시기보다는 해당 케이스가 발생하지 않도록 해결이 되는
원하는 방식으로 LGD_CUSTOM_USABLEPAY 에 값 설정하셔서 해결하는 방향으로 가시는게 좋을 것 같습니다.
❤️ 기술문의 경험이 어떠셨나요?!
간단히 코멘트 남겨주세요! 제품 발전에 큰 힘이 됩니다.
기존 소스에는
LGD_CUSTOM_USABLEPAY 이 아닌 LGD_CUSTOM_FIRSTPAY 으로 설정되어 있었거든요.
ex.
...
param.push({name : 'LGD_CUSTOM_FIRSTPAY', value : 'SC0040'});
...
LGD_CUSTOM_FIRSTPAY 는 현재 사용되지 않는 것이므로 위와 같이 해당 FIRSTPAY 값에 SC0040 으로 가상계좌를 지정해도
명칭이 USABLEPAY가 아닌 과거에 쓰던 FIRSTPAY 이므로 바둑판으로 열릴 수도 있는건지?해서요...
아니요 안됩니다
LGD_CUSTOM_USABLEPAY 를 사용하시면 됩니다
참고로 여기서 안된다는것은 LGD_CUSTOM_FIRSTPAY 를 사용하시면 안된다는 겁니다.
네네.. 말씀주신대로 LGD_CUSTOM_FIRSTPAY 는 사용 안할 예정이구요.
저는 원인이 궁금한 거라서...
"LGD_CUSTOM_FIRSTPAY" 으로 SC0040 으로 지정하게되면,
이는 현재 사용하지 않는 것이니 토스페이먼츠PG창에서는 결제방식을 선택하여 진입하지 않은 것으로 인식하여 바둑판으로 열릴 수 있는지가 궁금해서요.
혹시 LGD_CUSTOM_USABLEPAY 자체를 넘기지 않으셨나요?
LGD_CUSTOM_USABLEPAY 에 결제수단을 지정하면 지정된 결제수단만 포함된채로 바둑판 형태로 띄우고
LGD_CUSTOM_USABLEPAY 가 없다면 상점ID의 계약된 전체 결제수단이 바둑판형태로 띄워지거든요.
따라서 LGD_CUSTOM_USABLEPAY 를 명시적으로 사용하시고, 필요한 결제수단을 특정해서 사용하시는게 좋을것 같습니다.
저희 소스 상에는
PC 인 경우에는 LGD_CUSTOM_USABLEPAY 를 사용하였고
모바일인 경우에는 LGD_CUSTOM_FIRSTPAY 이 사용되고 있었습니다.
히스토리를 찾아보니, 디바이스 별로 명칭을
- PC > LGD_CUSTOM_USABLEPAY
- 모바일 > LGD_CUSTOM_FIRSTPAY
으로 사용되고 있었습니다.
이는 잘못된 코드이므로 디바이스 별 구분 없이 LGD_CUSTOM_USABLEPAY 으로 통용하여 수정하고자 합니다.
네 아주 오래전 히스토리입니다.
유플러스 PG 때, 해당코드가 PC, 모바일 분리되었다가 LGD_CUSTOM_USABLEPAY 로 통합되었는데,
당시에도 여러차례 공지를 했음에도 반영하지 않은 가맹점들이 많았던 것으로 알고 있습니다.
네, LGD_CUSTOM_USABLEPAY 를 사용하시면 됩니다.
혹시 유부장님 께서 말씀해주신 지난 현상에
"요청이 바둑판으로 띄우는 요청이었고, 청약으로 바둑판 뜨지 않도록 막혀있었다 "
라는 내용에 대해서 설명좀 가능할까요?...
요청이 바둑판으로 띄우는 요청 < 은
저희가 토스페이먼츠 측으로 보낸 파라미터 중, 변수 값이 따로 있나요?
그리고 청약으로 바둑판 뜨지 않도록 막혀 있었다는 건 어떤 설정일까요? 이 또한 파라미터로 보내나요?
LGD_CUSTOM_USABLEPAY 를 안보내면
바둑판으로 띄우는 요청 입니다
LGD_CUSTOM_USABLEPAY를 안보낸다 = 바둑판으로 띄우는 요청이다
그런데 청약 (계약 설정) 에 바둑판으로 띄우지 않기가 되어 있다
이때 LGD_CUSTOM_FIRSTPAY 가 넘어오는데, 오래던 F/O 했지만, 바둑판이 LGD_CUSTOM_FIRSTPAY 에 영향을 받았다
LGD_CUSTOM_FIRSTPAY 가 SC0040 으로 넘어온다, 의미는 가상계좌다
그래서 가상계좌 창이 떴다
해결책
LGD_CUSTOM_USABLEPAY 를 보낸다
LGD_CUSTOM_FIRSTPAY 를 보내지 않는다
CST_PLATFORM 값이 service 인 경우 바둑판 띄우지 않음
CST_PLATFORM 값이 test인 경우 바둑판 띄움
현재 CST_PLATFORM 값에 따라 바둑판 여부가 결정되는데... 이 내용이 청약(계약 설정)과 관련된 내용일까요?
아니요!!
그게 아니에요!
계속 설명 드리는데
LGD_CUSTOM_USABLEPAY 를 안보내면
바둑판으로 띄우는 요청 입니다
오래전 아주 옛날 유플러스 시절
모바일에서는 LGD_CUSTOM_FIRSTPAY 를 받았는데
LGD_CUSTOM_USABLEPAY 로 바뀌었어요
그런데, 지금 문의주시는 곳은, 오래전에 유플러스가 공지한 변경을 적용하지 않아서
아직도 LGD_CUSTOM_FIRSTPAY 를 사용하고 있던것으로 생각되는데
LGD_CUSTOM_USABLEPAY 가 없으면 바둑판으로 띄우는 요청이에요
자, 모바일에서 LGD_CUSTOM_FIRSTPAY 를 쓰고 있으니, LGD_CUSTOM_USABLEPAY 가 안넘어 왔으니까, 자연스럽게 바둑판 띄우는 요청이 되었겠죠?
1) LGD_CUSTOM_USABLEPAY 를 안보내면 바둑판으로 띄우는 요청
2) 보니까 모바일에서는 LGD_CUSTOM_FIRSTPAY 하는 것처럼 보임
3) 그러면 LGD_CUSTOM_USABLEPAY 를 안보내는 거니까, 결과적으로 바둑판으로 띄우는 요청 임
자 한번 더 상황에 대해 설명합니다
1) LGD_CUSTOM_USABLEPAY 를 안보내면 바둑판으로 띄우는 요청
2) 보니까 모바일에서는 LGD_CUSTOM_FIRSTPAY 하는 것처럼 보임
3) 그러면 LGD_CUSTOM_USABLEPAY 를 안보내는 거니까, 결과적으로 바둑판으로 띄우는 요청 임
4) 지금 청약 (계약설정) 이 "바둑판 안띄우기" 로 되어 있음. 이건 예전 담당자 또는 누군가가 토스페이먼츠로 요청했을 것임. 그건 내부에서 확인 해보세요.
5) 모바일에서 LGD_CUSTOM_USABLEPAY 가 안넘어와서 "바둑판" 으로 띄워야 하는데, 청약에 "바둑판 안띄우기" 가 있음
6) 그런데 LGD_CUSTOM_FIRSTPAY 가 SC0040 으로 넘어오고 있음.
7) 그래서 이걸 참고해서 SC0040 - 가상계좌 창을 띄움
자, 그러면 이제 토스페이먼츠가 설명할수 없는건 뭐냐
왜 주문번호 undefined_1589_786_20250214140237fc51 이런 형태로 된 요청이 가상계좌로 넘어왔는가?
그건 토스페이먼츠는 모르는 부분입니다
아까 설명한대로, 사람이 급격히 많이 요청했다고 하니
운영하는 시스템에서 요청이 꼬인게 아닌가 단순 예상하는데
그건 저희는 모르는 부분이니 알아보시면 될것 같고
1) LGD_CUSTOM_USABLEPAY 를 안보내면 바둑판으로 띄우는 요청
2) 보니까 모바일에서는 LGD_CUSTOM_FIRSTPAY 하는 것처럼 보임
3) 그러면 LGD_CUSTOM_USABLEPAY 를 안보내는 거니까, 결과적으로 바둑판으로 띄우는 요청 임
자 한번 더 상황에 대해 설명합니다
1) LGD_CUSTOM_USABLEPAY 를 안보내면 바둑판으로 띄우는 요청
2) 보니까 모바일에서는 LGD_CUSTOM_FIRSTPAY 하는 것처럼 보임
3) 그러면 LGD_CUSTOM_USABLEPAY 를 안보내는 거니까, 결과적으로 바둑판으로 띄우는 요청 임
4) 지금 청약 (계약설정) 이 "바둑판 안띄우기" 로 되어 있음. 이건 예전 담당자 또는 누군가가 토스페이먼츠로 요청했을 것임. 그건 내부에서 확인 해보세요.
5) 모바일에서 LGD_CUSTOM_USABLEPAY 가 안넘어와서 "바둑판" 으로 띄워야 하는데, 청약에 "바둑판 안띄우기" 가 있음
6) 그런데 LGD_CUSTOM_FIRSTPAY 가 SC0040 으로 넘어오고 있음.
7) 그래서 이걸 참고해서 SC0040 - 가상계좌 창을 띄움
1번 부터 7번 까지의 상황이 이해가 안되면 말씀 주세요
말씀주시는 내용에 이해 안되는 부분은 없습니다.
청약(계약설정)에서 바둑판 안띄우기로 설정되어 있는데,
어떤 이유로 모바일-'로컬'환경에서는 바둑판이 띄워지고 있는지 여쭤봤습니다.
그래서 'CST_PLATFORM' 값에 따라 좌우 되는지 여쭤봤던거구요...
운영에서는 CST_PLATFORM 값이 service
로컬에서는 CST_PLATFORM 값이 test 로 되어있거든요..
로컬에서도 CST_PLATFORM 값을 service로 바꾸니 바둑판이 뜨지 않아서요.
결론적으론
청약(계약설정)에서 바둑판 안띄우기로 설정이 되어있으니.. LGD_CUSTOM_FIRSTPAY/LGD_CUSTOM_USABLEPAY 여부에 상관없이
실제 사용자들이 바둑판을 마주했을리는 없겠네요...
로컬 테스트 때 찾아낸 동일한 증상을 구현해내려면 바둑판이 있어야 하거든요.
ㄴ LGD_CUSTOM_FIRSTPAY 값을 신용카드(SC0010) 으로 지정 후 PG창 진입 > 바둑판에서 다른결제방식 가상계좌(SC0040) 선택 후 진행
그렇다면 제가 찾아낸 위 바둑판을 통한 오류경로가 아닌 또 다른 이유가 있을 것 같습니다.
긴 시간 도움 주셔서 감사합니다.. 많이 배웠습니다.
감사합니다.
테스트 환경은 라이브 환경하고 구성이 달라서
"바둑판 안띄우기" 라는 설정이 안되어 있을 수 있습니다
그래서 test 에서는 떴을 가능성이 있고요