원래 결제 양식을 사용하는 것이 중요한 이유
결제 양식은 사용자가 가장 민감한 데이터 (카드 번호, CVC, 지갑 로그인) 를 입력하는 지점입니다. 양식이 독창적이지 않은 경우 (가짜 사이트, 공급자가 호스팅하는 양식 대신 판매자의 "자체 작성" 카드 필드, 통합 중단) 데이터 유출, 은행 고장, 청구 취소 및 잠금 위험이 있습니다. 원래 양식은 보안 인증을 통과했으며 올바른 시나리오 (iFrame/Hosted Fields/redirect) 에 따라 연결된 결제 제공 업체 (PSP/bank) 의 페이지/위젯입니다.
"원래 지불 양식" 은 무엇입니까?
PSP 주최: PAN/CVC/용어 필드-공급자의 iFrame/Hosted Fields 내부 또는 해당 도메인 (리디렉션).
PCI DSS에 해당: 판매자는 "원시" 카드 데이터를 보지 않고 저장하지 않으며 토큰 만받습니다.
SCA/3-D Secure 2: 은행을 통한 지불 확인 (푸시/SMS/생체 인식) 을 지원합니다.
프로토콜에 의해 보호됩니다: 엄격한 SL, HSTS, CSP, 클릭 재킹 보호.
식별 가능: 판매자 세부 정보가있는 올바른 도메인/인증서 및 예측 가능한 UX.
왜 중요한가 (사용자 및 비즈니스에)
사용자를 위해
카드 데이터 보호: 카드 필드의 토큰 화 및 격리는 판매자 및 스크립트에 의한 "엿보기" 를 제외합니다.
피싱 및 계정 도난 감소: 수령인의 이름과 3-DS2는 은행에 대한 지불을 확인합니다.
성공적인 결제 가능성: 올바른 통합 = 적은 기술적 실패.
비즈니스
규정 준수 및 처벌 감소: PCI DSS 준수는 감사 책임과 비용을 줄입니다.
적은 요금 환급: 3-DS2는 분쟁에서 발행자에게 책임을 이전합니다.
더 많은 전환: 빠른 SCA, Apple/Google Pay, 한 번의 클릭을 위해 토큰을 저장했습니다.
브랜드 보호: "formjacking" (악성 스크립트 포함) 및 누출 없음.
적절한 통합은 어떻게 생겼어야합니까
1. 판매자 페이지 내에서 PSP 또는 Hosted Fields/iFrame 도메인으로 리디렉션했습니다.
2. 카드 필드 (PAN/CVC/만료) 는 기술적으로 공급자에 속합니다. 판매자는 토큰을받습니다.
3. SCA/3-DS 2는 자동으로 시작합니다: 은행 응용 프로그램, 생체 인식, SMS 코드로 푸시.
4. 페이지 수준 보호: HSTS, CSP (Content Security Policy), X 프레임 옵션, nonce/스크립트 해시.
5. 순수한 UX: 단일 글꼴/레이아웃 또는 독점 PSP 위젯, 판매자의 올바른 설명자.
원본이 아닌 형태가 위험한 이유
Formjacking (Magecart): 악의적 인 JS가 PAN/CVC를 즉시 제거합니다.
피싱/도메인 대체: 유사한 맵, 가짜 로고, "잠금" 자체는 아무것도 보장하지 않습니다.
PCI 비준수: 벌금, 강제 감사, 차단 획득.
면제 및 원천 징수: 발행자는 회색 통합을 줄이고 더 많은 것을 존중하지 마십시오.
KYC 유출: "양쪽에 사진 카드" 및 전자 메일로 여권을 요청하는 것은 중대한 위반입니다.
원래 양식의 기능 (사용자 용)
맵 필드는 내장 iFrame (작은 창 "커서 및 프레임" 내부) 에 있거나 잘 알려진 PSP/뱅크의 도메인에 도달합니다.
주소 표시줄: HTTPS, 유효한 인증서, 오타가 없는 올바른 도메인.
3D Secure/SCA가 자동으로 나타납니다 (은행의 푸시/SMS/생체 인식).
채팅/메일로 PAN/CVC/사진 카드를 보내라는 요청이 없습니다.
개인 정보 보호 정책 및 지불 조건은 개방되어 있으며 읽을 수
붉은 깃발 (바로 멈춤)
iFrame/Hosted Fields가없는 판매자 사이트에 직접지도 작성
전자 메일/메신저 또는 "양쪽의 사진 카드" 로 PAN/CVC를 요청하십시오.
도메인은 이상합니다: '지불 안전. 상점 브랜드 확인. 브랜드/PSP 도메인 대신 net '.
이 페이지는 결제 단계에서 비밀 리소스 (http) 를 가져 오거나 인증서에서 "맹세" 합니다.
깨진 현지화, 픽셀 로고, 철자 오류, "2:59 지불" 타이머.
사용자 점검표 (1 분)
- 지불은 PSP 또는 iFrame/Hosted Fields로 리디렉션됩니다.
- HTTPS/인증서가 유효하고 도메인 대체가 없습니다.
- SCA/3-DS2가 작동했습니다 (푸시/SMS/생체 인식).
- 채팅/메일로 PAN/CVC/사진 카드를 보내지 않습니다.
- 개인 정보 보호 정책 및 연락처를 유지하십시오.
비즈니스 점검표 (통합/보안)
- Hosted Fields/iFrame 또는 PSP 리디렉션 사용; 판매자는 PAN/CVC를 볼 수 없습니다.
- PCI DSS: 통합 유형, 토큰 화, 네트워크 세분화에 의하여 SAQ A/SAQ A-EP.
- CSP/HSTS/XFO 활성화; 외부 스크립트 - 해시/노스가있는 허용 목록으로.
- 3-DS 2/SCA on; 대체 неOTP/푸시; 지갑 지원 (Apple/Google Pay).
- 전면 변경 사항 모니터링 (SRI, 카나리아 스크립트), 폼 재킹 방지.
- 명확한 텍스트: 누가 획득자/PSP이며, 데이터 처리 방법, 반환 날짜.
- 정기적 인 침투 테스트 및 종속성 제어 (SCA-소프트웨어 구성 분석).
일반적인 문제와 신속하게 해결하는 방법
FAQ (짧은)
주소 막대 잠금 = 안전합니까?
아니요, 그렇지 않습니다. 이것은 단지 암호화입니다. 도메인, 호스팅 된 양식, 3-DS2 및 정책을보십시오.
사이트의 필드보다 iFrame이 더 나은 이유는 무엇입니까?
PAN/CVC는 PSP로 직접 이동하여 판매자 전선에 닿지 않기 때문에 위험과 PCI 요구 사항이 적습니다.
전화/채팅으로 카드 정보를 얻을 수 있습니까?
아니요, 그렇지 않습니다. 이것은 총 PCI 위반입니다. 호스팅 된 양식과 함께 결제 링크/송장을 사용하십시오.
SCA없이 양식이 "매달린" 경우?
다시 부팅하고 네트워크/브라우저를 확인하십 PSP 팝업/스크립트를 차단하지 않도록하십시오.
회사의 미니 정책 (기성품 프레임 워크)
1. PAN/CVC 전용 필드 만 호스팅/리디렉션.
2. 3-DS 2/SCA는 카드에 필수입니다. Apple/Google Pay로 연결됩니다.
3. CSP/HSTS/XFO/SRI + 엄격한 허용 목록 도메인.
4. 전면 모니터링 및 스크립트 대체 경고.
5. 매년 SAQ/PCI 감사; 일정에 따른 펜 테스트.
6. 지원은 PAN/CVC/사진 카드를 요구하지 않습니다. KYC 채널 만 보호했습니다.
원래 지불 양식은 미학이 아니라 보안 및 합법성입니다. 호스트 필드, 토큰 화 및 SCA는 카드 소지자를 보호하고 전환을 증가 시키며 비즈니스에서 위험의 상당 부분을 제거합니다. 사용자 - 도메인, 양식 및 SCA 확인; 비즈니스-하드 프론트 방어와 함께 인증 된 통합 만 사용하십시오. 이 규칙에 따라 데이터 유출 및 지불 실패 시나리오의 90% 를 닫습니다.