본문으로 건너뛰기
2026. 8. 9·약 11분

카드번호를 저장하지 않고 어떻게 매달 결제할까요?

유의해 주세요

본 글은 제도 이해를 돕기 위한 교육용 참고 자료이며, 법률 자문이 아닙니다. 본문의 법령은 최종 수정일 기준으로 요약 및 발췌되었으므로, 이후 개정되거나 해석이 달라질 수 있습니다. 실제 업무에 적용하기 전 반드시 현행 법령(국가법령정보센터)을 직접 확인하고 전문가(세무사·노무사 등)의 자문을 거치시기 바랍니다. 본 글의 정보를 활용해 발생한 어떠한 결과나 법적 문제에 대해서도 작성자는 책임지지 않습니다.

구독 서비스를 처음 신청할 때는 카드정보를 입력하지만, 다음 달부터는 다시 입력하지 않아도 결제가 됩니다. 가맹점이 카드번호를 직접 보관하지 않는다면, 무엇으로 매달 결제를 요청하는 걸까요?

정기결제에 쓰는 빌링키는 카드정보를 대신하는 식별자입니다. 이 글에서는 카드정보 보관에 적용되는 규칙, 빌링키의 발급과 사용, 최초 인증과 서버의 승인 확인을 차례로 살펴봅니다. 예시 API는 토스페이먼츠를 기준으로 하며, 다른 PG에서는 필드 이름과 발급·인증 방식이 다를 수 있습니다.


카드정보는 어디까지 보관할 수 있을까​

온라인 카드 결제에서 카드사에 승인을 요청하려면 무엇이 필요한지는 PG(Payment Gateway, 전자지급결제대행업자)가 공개한 연동 문서에서 그대로 확인할 수 있습니다. 토스페이먼츠 용어집이 정리한 키인 결제는 카드번호와 유효기간, 방식에 따라 생년월일과 카드 비밀번호를 입력받습니다. 실물 카드 없이 승인을 요청하는 방식이지만, 실제 승인 여부는 카드의 유효성·한도와 카드사 정책 등에 따라 결정됩니다.

여기서 문제가 생깁니다. 매달 자동으로 결제를 일으키려면 그 값을 매달 어딘가에서 꺼내 와야 하는데, 그 조합은 이미 그 자체로 결제를 낼 수 있는 열쇠입니다. 전자금융거래법은 이런 성질의 수단과 정보를 접근매체라는 이름으로 따로 규율합니다.

전자금융거래법 제2조(정의) 10. "접근매체"라 함은 전자금융거래에 있어서 거래지시를 하거나 이용자 및 거래내용의 진실성과 정확성을 확보하기 위하여 사용되는 다음 각 목의 어느 하나에 해당하는 수단 또는 정보를 말한다.

가. 전자식 카드 및 이에 준하는 전자적 정보

접근매체는 이용자의 신청과 본인 확인을 거쳐 발급해야 하고(제6조 제2항), 다른 법률에 특별한 규정이 없으면 누구든지 양도·양수할 수 없습니다. 대가를 주고받으면서 대여하는 것과 질권의 목적으로 삼는 것도 금지됩니다(같은 조 제3항). 카드 자체는 이 정의의 첫 목에 그대로 들어맞습니다. 카드번호와 유효기간의 조합을 "이에 준하는 전자적 정보"로 볼 수 있는지는 해석에 달려 있습니다.

카드정보를 손에 넣는 쪽에는 형벌 조항이 따로 있습니다.

여신전문금융업법 제70조(벌칙) ① … 6. 거짓이나 그 밖의 부정한 방법으로 알아낸 타인의 신용카드 정보를 보유하거나 이를 이용하여 신용카드로 거래한 자

주목할 곳은 "보유하거나"입니다. 그 정보로 실제 결제를 하지 않았어도 갖고 있는 단계에서 이미 구성요건에 닿습니다. 다만 이 조항이 걸리는 대상은 "거짓이나 그 밖의 부정한 방법으로 알아낸" 정보로 한정됩니다. 구매자가 스스로 입력한 카드정보를 가맹점이 저장하는 행위를 이 조문이 직접 금지하는 것은 아닙니다. 정상적으로 받은 카드정보의 보관에는 별도의 개인정보 보호 의무와 감독 기준, 카드사·PG 계약 등을 살펴야 합니다.

그렇다면 정상적인 사업자는 어떨까요. 전자금융거래법은 금융회사와 전자금융업자에게 안전성 확보의무를 지우고, 금융위원회가 정하는 기준을 지키도록 합니다(제21조, 안전성의 확보의무). 그 기준이 전자금융감독규정이고, 카드정보를 어디까지 보관할 수 있는지는 이 감독 체계 안에서 정해집니다.

여기서 법령과 감독당국의 정책을 갈라 둘 필요가 있습니다. 2014년 7월 28일 금융위원회가 발표한 「전자상거래 결제 간편화 방안」은 기술력·보안성·재무적 능력을 충분히 갖춘 PG사가 카드정보를 저장할 수 있게 하는 방향을 제시했고, 그에 따라 여신금융협회가 신용카드 가맹점 표준약관을 개정했습니다. 저장을 허용한 수단이 법 개정이 아니라 표준약관 개정이었다는 점에서 법령과 정책이 따로 움직인다는 것을 알 수 있습니다. 같은 해 8월 13일 후속조치는 카드정보를 보유하는 PG사의 검사 주기를 규모별 2~6년에서 최소 2년에 1회로 단축했습니다. 이는 당시 국내 PG사의 저장 허용 범위를 넓힌 조치입니다. 이 정책의 도입 경위만으로 모든 사업자의 현재 저장 가능 여부를 판단할 수는 없습니다.

일반 가맹점이 PG의 정기결제를 연동할 때는 원본 카드정보 대신 빌링키를 저장하는 구조를 사용합니다. 포트원도 고객사가 카드정보를 저장하지 않고 빌링키로 결제를 요청하도록 안내합니다. 직접 카드정보를 다루려면 가능한 연동 방식과 보관 범위를 계약·보안 요건에 따라 별도로 확인해야 합니다.

Recap​

  • 온라인 카드 승인에는 카드번호·유효기간 등이 필요하고, 그 조합은 실물 카드 없이도 결제를 낼 수 있는 값입니다.
  • 전자금융거래법은 접근매체의 발급과 양도·양수를 규율하고(제2조 제10호, 제6조 제2항·제3항), 여신전문금융업법은 부정한 방법으로 알아낸 카드정보의 보유 자체를 처벌합니다(제70조 제1항 제6호). 정상적으로 받은 카드정보의 저장 가능 여부를 정하는 것은 이 조문들이 아닙니다.
  • 일반적인 PG 정기결제 연동에서는 원본 카드정보를 가맹점에 보관하지 않고 빌링키를 사용합니다.

법령·보안 표준·계약을 구분해야 하는 이유​

카드정보를 다룰 때 지켜야 하는 규칙은 만드는 곳과 강제하는 방식이 서로 다릅니다. 이를 섞어 말하면 "법으로 금지되어 있다"는 문장이 어디까지 참인지 알 수 없게 됩니다.

층만드는 곳어기면
법률(전자금융거래법, 여신전문금융업법)국회형벌 · 과태료
감독규정(전자금융감독규정)금융위원회감독 · 제재
PCI DSSPCI SSC(국제 카드 브랜드가 만든 협의체)계약상 제재
가맹점 심사 · 연동 승인카드사 · PG서비스 거절

이 가운데 PCI DSS가 자주 오해를 부릅니다. PCI DSS는 법령이 아닙니다. PCI Security Standards Council은 2006년 American Express, Discover, JCB International, MasterCard, Visa 다섯 카드 브랜드가 세운 업계 협의체이고, PCI DSS는 그 협의체가 만들어 관리하는 표준입니다. 위원회는 자기 표준의 준수를 스스로 집행하지 않습니다. 공식 안내는 준수 여부를 요구하고 검증하는 주체가 카드 브랜드나 매입사처럼 준수 프로그램을 운영하는 조직이라고 못 박아 두었습니다. 즉 PCI DSS를 지키게 만드는 힘은 공권력이 아니라 계약입니다.

그렇다고 이 표준이 느슨한 것은 아닙니다. 현행 PCI DSS(v4.0.1)는 저장된 계정 데이터를 보호하도록 요구하고, 승인이 끝난 뒤에는 민감 인증 데이터를 갖고 있지 못하게 합니다. PCI SSC의 용어 정의에 따르면 민감 인증 데이터에는 카드 검증값, 트랙 데이터 전체, PIN과 PIN 블록이 들어갑니다. 승인 전에 잠시 보유하는 경우에도 암호화해야 하고 필요한 기간을 넘겨 두지 못합니다.

카드번호와 CVC는 저장 규칙이 다릅니다. 카드번호는 보관 필요성과 보호 요건을 갖추어 저장할 수 있지만, 가맹점은 CVC를 승인 후에 보관해서는 안 됩니다. 정기결제에는 CVC를 다시 사용할 필요가 없습니다. PCI DSS가 모든 카드정보의 재사용을 금지해서 빌링키가 필요한 것이 아니라, 가맹점이 원본 정보를 직접 다루는 부담을 줄이고 PG가 정한 방식으로 결제를 요청하기 위해 빌링키를 쓰는 것입니다.


빌링키: 원본 대신 가리키는 이름​

빌링키는 가맹점이 등록된 결제수단으로 청구할 때 사용하는 식별자입니다. 가맹점에서는 카드번호를 복원하려 하지 않고, PG가 발급한 값을 그대로 저장해 승인 요청에 사용합니다. 이를 단순히 “CVC까지 암호화해 저장한 값”으로 이해해서는 안 됩니다. 빌링키의 구현 방식과 원본 정보의 보관 방식은 별개의 문제입니다.

토스페이먼츠에서는 빌링키를 발급할 때 사용한 customerKey(구매자 식별자)를 승인 요청에도 함께 보냅니다. 서버는 해당 가맹점의 시크릿 키로 API 요청을 인증합니다. 빌링키는 이 가맹점과 PG의 연동 범위에서 쓰는 값이므로, 다른 가맹점에서 카드번호처럼 사용할 수는 없습니다.

이 차이는 사고가 났을 때 드러납니다.

보관하는 값유출 시 위험대응 예일반적인 PG 연동에서 보관
카드번호 + 유효기간 + CVC다른 가맹점에서도 부정사용을 시도할 수 있음카드 이용 정지·재발급이 조합을 승인 후 저장할 수 없음
빌링키 + customerKey가맹점 시크릿 키까지 유출되면 승인 요청 가능PG에서 빌링키 삭제, 유출된 시크릿 키 교체접근을 제한해 보관

빌링키가 유출되면 PG가 제공하는 삭제 API 등으로 해당 키를 무효화해야 합니다. 가맹점 데이터베이스에서 값만 지워서는 이미 유출된 키를 막을 수 없습니다. 시크릿 키도 유출됐다면 함께 교체하고, 부정 청구 여부를 확인해야 합니다.

물론 빌링키에도 대가가 있습니다. 한 번 발급되면 고객이 매번 개입하지 않아도 계속 결제가 나갑니다. 그래서 카드사는 빌링키 발급 자체를 심사 대상으로 봅니다. 포트원 문서는 빌링키를 이용한 결제가 결제수단이 본인 소유인지 확인하기 어려운 구조라서, 카드사 심사에서 비정기적인 결제 용도로는 허용되지 않을 수 있다고 적어 두었습니다. 빌링키는 정기적인 청구를 전제로 발급되는 값입니다.


인증결제와 비인증결제: 사람을 누가 확인하는가​

여신전문금융업법 제19조(가맹점의 준수사항) 제2항은 가맹점에게 신용카드로 거래를 할 때마다 그 카드를 본인이 정당하게 사용하고 있는지 확인하도록 합니다. 오프라인에서는 단말기와 서명·비밀번호가 이 확인을 맡습니다. 온라인에는 단말기도 서명도 없습니다. 그래서 온라인 카드 결제는 이 확인을 어떻게 대신할지에 따라 두 갈래로 갈립니다.

인증결제는 결제 도중에 카드사가 사람을 확인합니다. 카드사 앱이나 SMS로 본인인증을 거친 뒤 승인이 진행되고, 국내 온라인 결제의 일반적인 방식입니다. 비인증결제(키인결제)는 그 확인 없이 카드번호와 유효기간 등을 입력받아 곧바로 승인을 요청합니다. 콜센터 주문이나 법인카드 결제처럼 인증 절차를 끼우기 어려운 경우에 쓰이고, 도용 위험이 있어 카드사 심사가 까다롭습니다. 지원 여부와 필요한 심사는 PG의 상품·계약에 따라 확인해야 합니다. 비인증결제라고 해서 가맹점의 정당한 사용 확인 의무까지 사라지는 것은 아닙니다.

인증 방식은 부정사용 사고의 책임을 판단할 때도 고려됩니다.

온라인 카드 결제의 본인인증은 국제적으로 3-D Secure라는 프로토콜로 정리되어 있습니다. 지금 세대의 규격은 EMV 3-D Secure이고, EMVCo가 이 규격과 승인 절차를 관리합니다. 흐름은 가맹점과 발급사 사이에 거래·결제수단·기기 정보를 주고받아 발급사가 위험을 평가하고, 위험해 보이는 거래에만 일회용 비밀번호나 생체인증 같은 추가 확인(challenge)을 요구하는 식입니다.

부정사용 책임의 이전(liability shift)은 EMV 3DS 기술 규격만으로 정해지지 않습니다. 적용 조건은 카드 브랜드의 운영규정과 거래 유형에 따라 다르고, 국내 거래는 카드사·가맹점 계약도 확인해야 합니다. 인증에 성공했다는 이유만으로 가맹점의 모든 책임이 없어지는 것은 아닙니다.

안심클릭과 ISP는 구분해서 읽기

오래된 국내 PG 문서에는 안심클릭(MPI), ISP 같은 인증 방식이 등장합니다. 안심클릭은 3-D Secure와 관련된 방식이지만, ISP를 그 규격의 다른 이름으로 보아서는 안 됩니다. 브이피의 공식 연혁도 ISP와 3-D Secure를 별도 서비스로 구분합니다. 연동할 때는 해당 카드사와 PG가 지원하는 인증 방식을 확인해야 합니다.

정기결제는 등록 때 결제수단을 확인하고 이후 청구 때마다 구매자가 다시 인증 화면을 거치지 않는 방식입니다. 다만 최초 인증의 구현은 등록창과 직접 API 방식에 따라 다릅니다.

등록 단계에서는 본인 확인과 함께 정기 청구에 대한 동의를 받아야 합니다. 그 뒤에도 청구 금액·주기·해지 여부에 맞게 결제를 요청할 책임은 남습니다. PG의 등록창을 쓰면 카드정보를 PG 영역에서 처리할 수 있고, 직접 API 방식은 가맹점이 카드정보를 일시적으로 전달하게 됩니다. 후자의 경우 로그 등에 원본 정보가 남지 않도록 해야 하며, 필요한 심사와 계약을 먼저 확인해야 합니다.

Recap​

  • 여신전문금융업법 제19조 제2항은 가맹점에게 거래마다 본인의 정당한 사용을 확인하도록 하고, 온라인에서는 이 확인을 어떻게 대신하느냐에 따라 인증결제와 비인증결제로 나뉩니다.
  • 3-D Secure의 현행 규격은 EMVCo가 관리하는 EMV 3DS이고, 발급사가 위험을 평가해 필요할 때만 추가 확인을 요구합니다. 인증 여부에 따라 부정사용 책임을 누가 지는지가 달라지는데, 그 배분은 카드 브랜드 운영규정과 카드사·가맹점 계약이 정합니다.
  • 정기결제에서는 매번 인증 화면을 거치지 않지만, 최초 인증과 청구 동의, 이후 해지·청구 관리를 함께 확인해야 합니다.

승인이 났다는 말은 누가 하는가​

결제창 방식의 흐름을 보면 승인이 나기 직전에 브라우저가 한 번 끼어듭니다. 구매자가 결제창에서 인증을 마치면 가맹점이 지정한 성공 URL로 리다이렉트되고, 그 URL의 쿼리 파라미터에 결제 키·주문번호·금액이 실려 옵니다.

이 값들은 브라우저를 지나온 값입니다. 주소창의 문자열은 누구든 고칠 수 있으니, 990,000원짜리 주문의 금액 파라미터를 9,900원으로 바꿔 서버에 던지는 것도 가능합니다. 그래서 토스페이먼츠 연동 문서는 두 가지를 요구합니다. 서버가 결제 요청 시점에 저장해 둔 금액과 넘어온 금액이 같은지 대조하고, 승인 API는 서버에서 호출하라는 것입니다. 값이 다르면 승인을 진행하지 않아야 하며, 승인 API 호출에 쓰는 시크릿 키는 클라이언트나 저장소 등 외부에 노출되면 안 된다고 못 박아 두었습니다.

자동결제로 넘어오면 이 원칙이 더 선명해집니다. 2회차 이후에는 브라우저가 아예 없습니다. 서버의 스케줄러가 정해진 날짜에 빌링키로 승인 API를 호출합니다. 토스페이먼츠는 자체 스케줄링을 제공하지 않으므로 그 주기를 가맹점이 직접 구현해야 한다고 안내합니다. 따라서 스케줄러의 중복 실행을 막고, 해지된 구독이 청구 대상에 포함되지 않도록 관리해야 합니다.

승인 요청을 보냈는데 응답이 오지 않는 경우도 있습니다. 이때 결제가 성립했는지 아닌지를 판정하고 되돌리는 문제는 취소는 왜 두 종류인가요?에서 망취소와 멱등성으로 다룹니다.


구독 한 건을 끝까지 따라가 보기​

첫 달은 무료이고 이후 월 9,900원을 내는 구독을 예로 들어 보겠습니다. 구매자는 1월 5일에 결제창에서 카드를 등록하고, 2월부터 매달 5일에 청구하는 데 동의했습니다.

1월 5일, 등록. 결제창에서 카드정보를 입력하고 등록창이 제공하는 본인인증을 마칩니다. 결제창 방식에서는 카드번호·유효기간·CVC가 PG와 카드사 영역에서 처리되고, 가맹점 서버로 넘어오지 않습니다. 인증 결과로 서버에서 빌링키를 발급받고, 이것을 구매자를 특정하는 customerKey와 짝지어 저장합니다. 화면에 다시 보여 줄 용도로 카드사 이름과 마스킹된 뒷자리 정도가 함께 옵니다.

2월 5일, 첫 자동결제. 스케줄러가 빌링키와 customerKey로 승인 API를 호출하고, 구매자는 아무것도 하지 않습니다. 구매자가 인증 화면을 다시 거치지는 않지만, 청구 전 구독 상태와 금액을 확인해야 합니다. 서버는 응답으로 승인 결과를 확인한 뒤 이용권을 연장합니다.

3월 5일, 승인 거절. 구매자가 카드를 재발급받아 유효기간이 바뀌었습니다. 이때 빌링키가 더 이상 승인을 받아 오지 못하는 경우가 있고, 그러면 재등록을 받아야 합니다. 갱신된 원본을 PG가 대신 반영해 주는지는 계약과 구현에 따라 갈립니다. 바뀐 것은 원본 쪽이므로, 가맹점이 카드정보를 직접 들고 있었더라도 저장해 둔 값이 더 이상 맞지 않게 되는 것은 마찬가지입니다.

넷째 시점은 예정에 없던 청구입니다. 구매자가 3월에 해지했는데 4월 5일에 결제가 나갔다고 해봅시다. 이 청구가 전자금융거래법상 "오류"로 다뤄진다면 이용자는 제8조(오류의 정정 등)에 따라 정정을 요구할 수 있고, 요구를 받은 금융회사 또는 전자금융업자가 2주 이내에 원인과 처리 결과를 알려야 합니다. 그 2주 의무를 지는 쪽은 가맹점이 아닙니다. 다만 조사에 답하려면 해지 요청과 청구 중단을 언제 처리했는지, 어느 청구가 어느 빌링키로 나갔는지가 가맹점 기록에 남아 있어야 합니다.

네 시점에 서버에 남는 것을 늘어놓으면 이렇습니다.

날짜일어난 일서버에 남는 것남지 않는 것
1월 5일결제창 인증 후 빌링키 발급빌링키, customerKey, 카드사명, 마스킹 뒷자리카드번호 전체, 유효기간, CVC
2월 5일빌링키로 승인 요청승인 응답(결제 키, 승인 금액, 승인 시각)-
3월 5일카드 재발급으로 거절거절 응답, 빌링키 재등록 이력-
4월 5일해지 후 잘못된 청구와 정정 요구해지·청구 중단·키 폐기 이력, 해당 거래 식별자-

가맹점은 등록된 결제수단을 가리키는 빌링키와 API 인증 수단으로 매달 청구합니다. 원본 카드정보를 직접 보관하지 않으면서도 결제를 요청할 수 있지만, 올바른 금액을 올바른 시점에 청구하는 일은 여전히 가맹점의 몫입니다.

승인된 이 9,900원이 장부의 매출과 세금으로 옮겨 가는 과정은 카드 매출은 어떻게 장부와 세금이 될까요?에서 이어집니다.

Recap​

  • 정기결제 한 건에서 가맹점 서버에 남는 것은 빌링키와 customerKey이고, 결제창 방식에서는 카드번호·유효기간·CVC가 처음부터 넘어오지 않습니다.
  • 등록 후에는 구매자가 인증 화면을 다시 거치지 않습니다. 카드가 재발급되거나 만료되면 PG 안내에 따라 결제수단을 다시 등록합니다.
  • 잘못 나간 청구에 대응하려면 빌링키의 발급·폐기 시각과 청구별 이력이 남아 있어야 합니다. 정정 요구에 2주 이내로 원인과 결과를 알릴 의무를 지는 쪽은 금융회사와 전자금융업자이고(전자금융거래법 제8조), 가맹점은 그 조사에 답할 기록을 갖는 쪽입니다.

References​

Wonkook Lee
좋은 사람들과 재미있는 일을 하며 열정적이고 즐겁게 살고 싶은 개발자