BESTPAY / PG결제

PG결제 도입 절차,
계약 뒤 첫 결제까지

PG결제 도입 절차, 지금 필요한 확인부터 차례로 살펴보면 됩니다. 신청을 마치고 전달받는 상점 식별값과 계정 · 연동 안내는 시험 중 사용한 값과 다를 수 있습니다. 누가 설정을 적용하고 누가 결과를 확인할지 정해 두면 계약 완료 뒤 개통 준비가 이어집니다. 첫 거래 목록과 오류 · 취소 · 고객 문의, 계약 조건과 첫 명세를 모읍니다. 베스트페이가 현재 준비 상태에 맞춰 다음 순서를 함께 정리합니다.

PG결제 도입 절차 · 준비 자료와 운영 환경을 확인하는 장면
서비스 이해를 돕기 위한 AI 연출 이미지입니다.

AT A GLANCE / 핵심 요약

  1. 이 문서에서 보는 것PG결제 도입 절차의 준비와 진행을 여섯 항목으로 나눠 봅니다. 첫 확인에서는 최종 계약과 상점 정보, 운영 환경 안내 및 담당자 계정을 준비하면 됩니다. 필요한 자료를 실제 운영과 맞춰 보세요. 첫 확인 항목
  2. 먼저 맞출 기준준비된 자료가 있다는 것과 실제로 쓸 수 있는 상태는 다를 수 있습니다. 소액 실거래를 했다면 취소 결과와 주문 상태, 정산 반영 여부까지 확인해 보세요. 적용 기준
  3. 다음으로 할 일마지막으로 첫 거래 목록과 오류 · 취소 · 고객 문의, 계약 조건과 첫 명세를 모읍니다. 현재 준비된 것과 추가 확인할 것을 나눠 두면 상담에서 다음 작업을 구체적으로 정할 수 있습니다. 상담 준비

계약 뒤 받는 것

이 단계에서 결정할 것

  • 최종 계약과 상점 정보, 운영 환경 안내 및 담당자 계정을 준비합니다.
  • 서비스의 설정 절차에 따라 운영 정보를 적용하고 결과 수신 · 취소 기능을 점검합니다.

PG결제 도입 절차의 첫 확인입니다. 계약 뒤 받은 정보를 실제 설정에 맞춥니다. 신청을 마치고 전달받는 상점 식별값과 계정 · 연동 안내는 시험 중 사용한 값과 다를 수 있습니다. 누가 설정을 적용하고 누가 결과를 확인할지 정해 두면 계약 완료 뒤 개통 준비가 이어집니다. 최종 계약과 상점 정보, 운영 환경 안내 및 담당자 계정을 준비합니다. 서비스의 설정 절차에 따라 운영 정보를 적용하고 결과 수신 · 취소 기능을 점검합니다. 첫 거래를 조회해 올바른 가맹점과 금액 · 수단으로 기록되는지 확인합니다. 전체 흐름은 PG결제 안내에서 함께 볼 수 있습니다.

계약은 완료됐지만 빌더 설정에 시험 상점 정보가 남아 있다면 실제 고객 결제를 열기 전에 환경과 상태를 다시 대조해야 합니다. 거래가 올바른 가맹점에 기록되고 고객 화면의 상호 · 수단이 맞는지 확인합니다. 민감한 키나 계정 정보를 일반 문서 · 메신저로 무분별하게 전달하지 않고 권한 있는 경로로 관리합니다. 계약에서 확인한 상점 정보가 실제 사이트의 설정과 다르면 승인 오류나 잘못된 상호 표시가 생길 수 있습니다. 사업자 · 가맹점 · 환경 · 수단을 한 번에 대조해 의도한 계약으로 거래가 처리되도록 맞춥니다.

연동 — 누가 무엇을

이 단계에서 결정할 것

  • 신청 · 계약 · 개발 · 운영 담당자와 연락 경로, 각자가 준비할 자료를 정리합니다.
  • 단계별 완료 결과를 다음 담당자에게 넘기고 추가 요청의 책임자를 분명히 정합니다.

신청 · 개발 · 운영 담당자를 연결해 둡니다. 도입 과정은 사업자 서류를 준비하는 사람, 사이트를 설정하는 사람과 실제 주문을 처리하는 사람이 다를 수 있습니다. 각 단계의 전달 항목과 완료 기준을 나누면 자료가 준비됐는데 다음 작업이 멈추는 일을 줄일 수 있습니다. 신청 · 계약 · 개발 · 운영 담당자와 연락 경로, 각자가 준비할 자료를 정리합니다. 단계별 완료 결과를 다음 담당자에게 넘기고 추가 요청의 책임자를 분명히 정합니다. 시험 · 개통 · 운영 인수인계에 빠진 항목이 없는지 확인합니다.

개발사가 연동을 끝냈어도 운영자가 관리자에 접근하지 못하면 고객 문의를 처리할 수 없으므로 권한 전달까지 점검합니다. 오픈 전에 모든 담당자가 승인 조회 · 취소 · 장애 문의의 흐름을 이해하는지 확인합니다. 한 사람이 여러 역할을 맡더라도 점검 항목은 구분해 기록하고 놓친 작업이 없는지 확인합니다. 신청부터 운영까지 작업이 여러 사람에게 나뉘면 각 단계가 무엇을 완료해야 다음 단계로 넘어가는지 정하는 것이 좋습니다. 자료 · 설정 · 결과의 전달 기준이 있으면 도입 일정과 책임을 확인하기 쉽습니다.

PG결제 도입 절차 · 실무 준비 내용을 다른 장면에서 점검하는 모습
서비스 이해를 돕기 위한 AI 연출 이미지입니다.

시험 결제 체크

이 단계에서 결정할 것

  • 시험 주문번호와 금액, 수단, 기기 · 브라우저, 예상 결과를 표에 적습니다.
  • 시험 환경에서 성공과 실패를 확인한 뒤 승인된 운영 환경에서 안내된 소액 거래를 수행합니다.

승인과 취소를 한 묶음으로 시험합니다. 결제 기능은 성공 화면이 한 번 나타났다고 점검이 끝나지 않습니다. 승인, 취소, 실패, 결과 알림, 주문 상태와 모바일 복귀를 이어서 확인해야 고객이 실제로 사용하는 흐름과 관리자 업무를 함께 점검할 수 있습니다. 시험 주문번호와 금액, 수단, 기기 · 브라우저, 예상 결과를 표에 적습니다. 시험 환경에서 성공과 실패를 확인한 뒤 승인된 운영 환경에서 안내된 소액 거래를 수행합니다. 수정 후 같은 조건으로 다시 확인한 결과와 처리 담당자를 덧붙입니다.

승인은 되었는데 주문이 미결제로 남는 경우에는 고객에게 다시 결제하도록 안내하기 전에 원거래 결과를 먼저 조회합니다. 소액 실거래를 했다면 취소 결과와 주문 상태, 정산 반영 여부까지 확인합니다. 실결제 시험은 실제 돈이 움직이는 거래이므로 담당자 허가와 서비스의 시험 안내에 따라 범위를 정합니다. 변경과 시험의 기록은 다음 담당자가 같은 상황을 재현하는 데 도움이 됩니다. 화면 캡처만 쌓기보다 언제 어떤 환경에서 어떤 주문으로 실행했고 결과가 어떻게 남았는지를 한 줄로 연결해 보관합니다.

시험 결제 체크 확인표
확인할 것준비 · 확인 방법판단 기준
자료시험 주문번호와 금액, 수단, 기기 · 브라우저, 예상 결과를 표에 적습니다날짜 · 시각, 환경, 주문번호와 거래 식별값, 예상 · 실제 결과를 적을 양식을 준비합니다
진행시험 환경에서 성공과 실패를 확인한 뒤 승인된 운영 환경에서 안내된 소액 거래를 수행합니다성공뿐 아니라 실패 · 취소 · 모바일 복귀 결과도 기록하고 문제의 재현 순서를 남깁니다
결과소액 실거래를 했다면 취소 결과와 주문 상태, 정산 반영 여부까지 확인합니다수정 후 같은 조건으로 다시 확인한 결과와 처리 담당자를 덧붙입니다

실결제 전환 당일

이 단계에서 결정할 것

  • 운영키와 계약 상태, 결과 수신 주소, 전환 시각과 담당자 · 연락 경로를 준비합니다.
  • 안내된 순서로 설정을 바꾸고 실제 주문서에서 결제 · 취소와 완료 안내를 확인합니다.

운영 전환은 확인 목록을 두고 진행합니다. 시험을 마친 설정을 실제 고객에게 여는 날에는 키와 주소, 가맹점 상태 및 노출 수단을 함께 확인합니다. 전환 담당자와 시간, 문제가 생겼을 때의 대응을 정하면 설정 변경이 겹치는 일을 줄일 수 있습니다. 운영키와 계약 상태, 결과 수신 주소, 전환 시각과 담당자 · 연락 경로를 준비합니다. 안내된 순서로 설정을 바꾸고 실제 주문서에서 결제 · 취소와 완료 안내를 확인합니다. 오픈 때 노출할 수단과 안내가 실제 계약 · 개통 범위와 같은지 확인합니다.

전환 당일 상품 가격이나 도메인을 동시에 크게 바꾸면 오류 원인을 찾기 어려울 수 있어 변경 항목을 구분해 관리합니다. 첫 거래가 맞는 가맹점에 기록되는지와 알림 · 정산 예정 정보가 이어지는지 확인합니다. 시험 완료와 카드사별 개통 상태는 별개일 수 있으므로 사용할 수단의 승인 · 설정 여부를 확인합니다. 사이트와 결제 기능이 준비되면 고객이 주문을 마칠 수 있는지와 운영자가 그 주문을 처리할 수 있는지를 동시에 확인합니다. 작은 시험 주문으로 승인 · 취소 · 알림 · 정산 조회와 문의 경로를 실제로 따라가 봅니다.

첫 정산 확인

이 단계에서 결정할 것

  • 거래일 · 정산 기준일 · 예정 입금일, 계약 주기와 정산 계좌를 확인합니다.
  • 같은 기간의 거래 명세를 내려받고 취소 · 수수료 · 기타 조정 금액을 분리합니다.

승인일과 입금일은 다른 날짜입니다. 결제가 승인된 시점, 매입 또는 정산 대상에 포함되는 시점, 사업자 계좌로 입금되는 시점을 나누면 통장과 매출이 다른 이유를 찾기 쉬워집니다. 정산은 계약에서 정한 기준과 집계 기간에 따라 이루어집니다. 거래일 · 정산 기준일 · 예정 입금일, 계약 주기와 정산 계좌를 확인합니다. 같은 기간의 거래 명세를 내려받고 취소 · 수수료 · 기타 조정 금액을 분리합니다. 차액이나 지연의 사유와 다음 확인 시점을 기록하고 실제 반영 결과를 대조합니다.

월말에 승인된 거래가 다음 달 정산으로 넘어갔다면 매출이 없어졌다기보다 조회 기준일이 다른 경우인지 먼저 살핍니다. 예정 정산액과 실제 계좌 입금액을 같은 가맹점 · 회차로 대조합니다. 당일 매출 합계와 당일 통장 입금액을 바로 비교하면 서로 다른 거래 묶음을 대조하게 될 수 있습니다. 정산 예정액은 아직 지급되지 않은 거래 상태를 포함할 수 있으므로 실제 입금 자료와 구분합니다. 예정일이 지났거나 금액이 다를 때는 해당 회차의 변경 · 보류 · 취소 조정이 있는지 차례로 확인합니다.

도입 뒤 첫 달

이 단계에서 결정할 것

  • 첫 거래 목록과 오류 · 취소 · 고객 문의, 계약 조건과 첫 명세를 모읍니다.
  • 주문과 결제를 대조하고 첫 정산에서 공제 항목 · 입금액을 확인합니다.

첫 달 운영은 작은 차이를 찾는 기간입니다. 처음에는 고객 기기와 결제 수단, 실제 취소 · 정산 회차가 시험 때보다 다양해질 수 있습니다. 승인 · 주문 불일치와 반복 문의, 비용 적용을 짧은 주기로 확인하면 설정과 안내의 차이를 조기에 찾기 좋습니다. 첫 거래 목록과 오류 · 취소 · 고객 문의, 계약 조건과 첫 명세를 모읍니다. 주문과 결제를 대조하고 첫 정산에서 공제 항목 · 입금액을 확인합니다. 이전 달과 기준이 같은지 확인한 뒤 필요한 설정 · 조건 재검토를 진행합니다.

고객이 완료 화면을 찾지 못해 같은 주문을 반복한다면 결과 페이지와 조회 안내, 중복 요청 처리까지 함께 점검할 수 있습니다. 수정한 내용과 재확인 결과를 남겨 이후 월간 점검 기준으로 씁니다. 한 달 자료만으로 장기 실적이나 승인 수준을 과도하게 일반화하지 않습니다. 운영이 안정된 뒤에도 거래 · 취소 · 비용 · 입금의 연결은 정기적으로 확인하는 편이 좋습니다. 같은 양식을 유지하면 월별 변화가 상품 · 행사 영향인지 설정이나 계약 변화 때문인지 비교하기 쉬워집니다.

FREQUENTLY ASKED

PG결제 도입 절차
자주 묻는 질문 FAQ

일정을 미리 정할 수 있나요?

자료가 완성된 시점부터 다음 단계를 확인합니다. 준비에 걸리는 시간과 기관 · 서비스의 검토 시간은 구분해야 합니다. 사이트가 아직 열리지 않거나 서류 발급이 남았다면 그 작업의 완료가 선행될 수 있어 신청일 하나만으로 전체 일정이 결정되지는 않습니다. 신청 · 계약 · 개발 · 운영 담당자와 연락 경로, 각자가 준비할 자료를 정리합니다.

희망 오픈일이 정해져 있다면 그날 필요한 수단과 기능부터 우선순위를 정해 준비 범위를 구체적으로 상의할 수 있습니다. 공개 안내의 일반적인 소요일을 해당 사업자의 확정 일정으로 사용하지 않습니다. 대기 중 처리할 수 있는 작업과 승인 후에만 진행할 수 있는 일을 나누어 일정표를 만듭니다. 오픈 전에 모든 담당자가 승인 조회 · 취소 · 장애 문의의 흐름을 이해하는지 확인합니다. 담당자에게 단계별 상태와 다음 제출 항목을 확인하고 기록을 갱신합니다.

신청과 개발 담당자가 달라도 되나요?

신청 · 개발 · 운영 담당자를 연결해 둡니다. 도입 과정은 사업자 서류를 준비하는 사람, 사이트를 설정하는 사람과 실제 주문을 처리하는 사람이 다를 수 있습니다. 각 단계의 전달 항목과 완료 기준을 나누면 자료가 준비됐는데 다음 작업이 멈추는 일을 줄일 수 있습니다. 단계별 담당자와 입력 자료, 완료 결과와 다음 전달 대상을 정리합니다.

개발사가 연동을 끝냈어도 운영자가 관리자에 접근하지 못하면 고객 문의를 처리할 수 없으므로 권한 전달까지 점검합니다. 한 사람이 여러 역할을 맡더라도 점검 항목은 구분해 기록하고 놓친 작업이 없는지 확인합니다. 단계별 완료 결과를 다음 담당자에게 넘기고 추가 요청의 책임자를 분명히 정합니다. 시험 · 개통 · 운영 인수인계에 빠진 항목이 없는지 확인합니다. 오픈 전에 모든 담당자가 승인 조회 · 취소 · 장애 문의의 흐름을 이해하는지 확인합니다.

시험 결제는 어디까지 하나요?

승인과 취소를 한 묶음으로 시험합니다. 결제 기능은 성공 화면이 한 번 나타났다고 점검이 끝나지 않습니다. 승인, 취소, 실패, 결과 알림, 주문 상태와 모바일 복귀를 이어서 확인해야 고객이 실제로 사용하는 흐름과 관리자 업무를 함께 점검할 수 있습니다. 날짜 · 시각, 환경, 주문번호와 거래 식별값, 예상 · 실제 결과를 적을 양식을 준비합니다.

승인은 되었는데 주문이 미결제로 남는 경우에는 고객에게 다시 결제하도록 안내하기 전에 원거래 결과를 먼저 조회합니다. 실결제 시험은 실제 돈이 움직이는 거래이므로 담당자 허가와 서비스의 시험 안내에 따라 범위를 정합니다. 시험 환경에서 성공과 실패를 확인한 뒤 승인된 운영 환경에서 안내된 소액 거래를 수행합니다. 수정 후 같은 조건으로 다시 확인한 결과와 처리 담당자를 덧붙입니다. 소액 실거래를 했다면 취소 결과와 주문 상태, 정산 반영 여부까지 확인합니다.

실결제 전환 때 무엇을 바꾸나요?

운영 전환은 확인 목록을 두고 진행합니다. 시험을 마친 설정을 실제 고객에게 여는 날에는 키와 주소, 가맹점 상태 및 노출 수단을 함께 확인합니다. 전환 담당자와 시간, 문제가 생겼을 때의 대응을 정하면 설정 변경이 겹치는 일을 줄일 수 있습니다. 대표 상품과 시험 시나리오, 운영자 계정과 문의 · 장애 연락 경로를 준비합니다.

전환 당일 상품 가격이나 도메인을 동시에 크게 바꾸면 오류 원인을 찾기 어려울 수 있어 변경 항목을 구분해 관리합니다. 시험 완료와 카드사별 개통 상태는 별개일 수 있으므로 사용할 수단의 승인 · 설정 여부를 확인합니다. 안내된 순서로 설정을 바꾸고 실제 주문서에서 결제 · 취소와 완료 안내를 확인합니다. 오픈 때 노출할 수단과 안내가 실제 계약 · 개통 범위와 같은지 확인합니다. 첫 거래가 맞는 가맹점에 기록되는지와 알림 · 정산 예정 정보가 이어지는지 확인합니다.

결제한 날 바로 입금되나요?

승인일과 입금일은 다른 날짜입니다. 결제가 승인된 시점, 매입 또는 정산 대상에 포함되는 시점, 사업자 계좌로 입금되는 시점을 나누면 통장과 매출이 다른 이유를 찾기 쉬워집니다. 정산은 계약에서 정한 기준과 집계 기간에 따라 이루어집니다. 예정 정산일과 가맹점, 예상 지급액 및 실제 계좌 입금 내역을 준비합니다.

월말에 승인된 거래가 다음 달 정산으로 넘어갔다면 매출이 없어졌다기보다 조회 기준일이 다른 경우인지 먼저 살핍니다. 당일 매출 합계와 당일 통장 입금액을 바로 비교하면 서로 다른 거래 묶음을 대조하게 될 수 있습니다. 같은 기간의 거래 명세를 내려받고 취소 · 수수료 · 기타 조정 금액을 분리합니다. 차액이나 지연의 사유와 다음 확인 시점을 기록하고 실제 반영 결과를 대조합니다. 예정 정산액과 실제 계좌 입금액을 같은 가맹점 · 회차로 대조합니다.

도입 뒤 어떤 자료를 모으나요?

첫 달 운영은 작은 차이를 찾는 기간입니다. 처음에는 고객 기기와 결제 수단, 실제 취소 · 정산 회차가 시험 때보다 다양해질 수 있습니다. 승인 · 주문 불일치와 반복 문의, 비용 적용을 짧은 주기로 확인하면 설정과 안내의 차이를 조기에 찾기 좋습니다. 월별 승인과 취소 합계, 수단 구성과 비용, 입금 · 유보 잔액을 모읍니다.

고객이 완료 화면을 찾지 못해 같은 주문을 반복한다면 결과 페이지와 조회 안내, 중복 요청 처리까지 함께 점검할 수 있습니다. 한 달 자료만으로 장기 실적이나 승인 수준을 과도하게 일반화하지 않습니다. 주문과 결제를 대조하고 첫 정산에서 공제 항목 · 입금액을 확인합니다. 이전 달과 기준이 같은지 확인한 뒤 필요한 설정 · 조건 재검토를 진행합니다. 수정한 내용과 재확인 결과를 남겨 이후 월간 점검 기준으로 씁니다.

시험키와 운영키는 다른가요?

시험용 키와 운영용 키를 분리합니다. 시험 환경의 성공은 실제 가맹점이 모든 결제 수단을 사용할 수 있다는 의미가 아닙니다. 계약 상태와 운영 상점의 권한, 환경별 키와 연결 주소를 구분해야 시험 결과를 운영 판단에 잘못 섞지 않을 수 있습니다. 접속 도메인과 인증서, 키 저장 위치, 관리자 목록과 접근 권한을 확인합니다.

개발자가 시험키로 만든 주문 화면을 넘겼다면 운영키 교체뿐 아니라 결과 수신 주소와 사용 수단도 함께 검토해야 합니다. 비밀키를 화면 코드 · 공개 저장소 · 상담 메시지에 붙이지 말고 노출이 의심되면 폐기 · 재발급 절차를 진행합니다. 브라우저에 공개 가능한 값과 서버에서만 보관할 비밀 값을 공식 문서에 따라 나눠 설정합니다. 공개 코드 · 기록 · 화면에 비밀 값이 없는지, 퇴사자 권한이 회수됐는지 점검합니다. 운영 전환 후 거래가 의도한 가맹점의 관리 화면에 나타나는지 확인합니다.

설정만 저장하면 개통되나요?

신청 정보와 관리자 설정을 대조합니다. 계약에서 확인한 상점 정보가 실제 사이트의 설정과 다르면 승인 오류나 잘못된 상호 표시가 생길 수 있습니다. 사업자 · 가맹점 · 환경 · 수단을 한 번에 대조해 의도한 계약으로 거래가 처리되도록 맞춥니다. 사이트 주소와 가맹점 식별자, 계약 주체와 담당자, 정산 계좌를 대응시켜 둡니다.

시험키를 운영 화면에 남기거나 다른 사이트의 상점 정보를 복사하지 않았는지 전환 전에 담당자가 함께 확인할 수 있습니다. 설정값이 저장되었다는 결과만으로 개통과 실제 거래 검증이 끝났다고 판단하지 않습니다. 공식 안내에 따라 값을 적용하고 오타 · 환경 혼용 · 이전 주소를 점검합니다. 첫 거래의 상호 표시와 관리자 조회 위치가 의도한 계약과 맞는지 확인합니다. 첫 거래를 조회해 올바른 가맹점과 금액 · 수단으로 기록되는지 확인합니다.

첫 승인만 되면 도입이 끝나나요?

첫 결제 뒤 첫 취소와 첫 정산도 확인합니다. 도입의 끝을 결제 버튼 노출에만 두면 운영에서 필요한 확인이 남습니다. 고객의 결제, 취소 요청과 사업자의 실제 입금까지 한 흐름으로 확인해야 담당자가 무엇을 어디에서 처리할지 알 수 있습니다. 최종 계약과 개통 수단, 관리자 · 정산 · 취소 경로 및 시험 결과를 모읍니다.

고객에게는 완료로 보이는데 관리자 주문이 대기로 남는다면 오픈 후에도 결과 수신 · 상태 반영 작업을 점검해야 합니다. 거래를 여러 번 재시도하기 전에 원거래 상태를 조회하고 불확실한 결과는 담당 창구에 확인합니다. 승인 · 취소 결과를 기록하고 첫 입금 때 명세의 합계와 통장 내역을 대조합니다. 권한과 자료 접근, 개인정보 · 비밀정보 보관이 적절한지 확인합니다. 남은 오류와 고객 문의를 정리해 실제 운영자가 처리할 수 있는 상태인지 확인합니다.

첫 상담에는 무엇을 준비하나요?

첫 상담은 상황을 좁히는 정보부터 시작합니다. 처음부터 모든 계약 서류를 보내기보다 무엇을 판매하고 어떤 경로로 결제를 받으려는지 설명하면 다음 확인이 빨라집니다. 현재 막힌 단계와 이전 안내가 있다면 사실 그대로 알려 주면 준비 범위를 나누기 좋습니다. 상호 · 업종과 연락 가능한 번호, 운영 사이트 또는 판매 방식의 개요를 정리합니다.

이미 계약 견적을 받았다면 금액만 말하기보다 확인하고 싶은 비용 · 정산 · 지원 항목을 알려 주면 비교할 범위가 구체적이 됩니다. 첫 문의란에는 카드번호 · 비밀번호 · 신분증 같은 자료를 적지 말고 필요한 경우 안내된 안전한 제출 경로를 이용합니다. 현재 상황과 희망 일정을 전달하고 추가 자료가 필요한 항목과 공식 제출 경로를 안내받습니다. 전달한 자료의 접수와 다음 진행 순서를 확인해 기록합니다. 다음 작업의 담당자 · 자료 · 순서를 확인해 상담 뒤에도 이어갈 수 있게 기록합니다.

이어서 확인할 것

BACK TO BESTPAY

PG결제 전체 안내

준비부터 운영까지, 전체 흐름을 이어서 살펴보세요.

PG결제 메인으로 ↗

베스트페이 고객센터

365일 친절한 상담원이 대기중입니다.

010-3970-2769전화 상담하기

BESTPAY / CONSULTATION

간편상담 신청

성함 · 연락처 · 업종을 남겨 주세요.
사이트 주소를 확인해 필요한 준비를 안내합니다.

전화 문의 010-3970-2769 ↗