본문으로 건너뛰기
2026. 8. 9
© WONKOOK LEE

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

음악 스트리밍이나 클라우드 구독료는 매달 같은 날짜에 카드에서 빠져나갑니다. 그날 카드를 다시 꺼내 번호를 입력한 사람은 아무도 없습니다.

그런데 카드로 승인을 받으려면 카드번호와 유효기간은 있어야 합니다. 아무도 다시 입력하지 않았는데 승인이 났다면 그 값은 어딘가에 남아 있다는 뜻입니다. 한편 카드정보는 아무나 보관할 수 없다는 말도 자주 들립니다.

두 이야기가 동시에 참이라면, 매달 결제를 일으키는 그 값은 대체 무엇일까요?

이 글은 정기결제(빌링)가 놓인 이 긴장을 다룹니다. 카드정보 보관을 제약하는 근거가 어디에 있는지, 그 제약 아래에서 빌링키(billing key)가 원본을 어떻게 대신하는지, 인증결제와 비인증결제가 무엇으로 갈리는지, 그리고 승인 결과를 왜 브라우저 대신 서버가 확인해야 하는지까지 따라갑니다. 승인·매입·정산·입금의 4단계 자체는 카드를 긋는 순간 무슨 일이 벌어질까요?에, 통신이 끊겼을 때의 보상 처리와 멱등성은 취소는 왜 두 종류인가요?에, 결제액이 어떻게 쪼개지는지는 결제 수수료는 누가 얼마를 가져가나요?에 있습니다.


1. 정기결제가 요구하는 것과 규제가 막아 둔 것​

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

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

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

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

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

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

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

주목할 곳은 "보유하거나"입니다. 그 정보로 실제 결제를 하지 않았어도 갖고 있는 단계에서 이미 구성요건에 닿습니다. 다만 이 조항이 걸리는 대상은 "거짓이나 그 밖의 부정한 방법으로 알아낸" 정보로 한정됩니다. 구매자가 스스로 입력한 카드정보를 가맹점이 저장하는 행위를 이 조문이 직접 금지하는 것은 아닙니다. 정상적으로 받은 카드정보를 어디까지 들고 있을 수 있는지는 감독당국의 정책과 카드사 계약이 정합니다.

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

여기서 법령과 감독당국의 정책을 갈라 둘 필요가 있습니다. 2014년 7월 28일 금융위원회가 발표한 「전자상거래 결제 간편화 방안」은 기술력·보안성·재무적 능력을 충분히 갖춘 PG사가 카드정보를 저장할 수 있게 하는 방향을 제시했고, 그에 따라 여신금융협회가 신용카드 가맹점 표준약관을 개정했습니다. 저장을 열어 준 수단이 법이 아니라 표준약관이었다는 점이 이 층위를 그대로 보여 줍니다. 같은 해 8월 13일 후속조치는 카드정보를 보유하는 PG사의 검사 주기를 규모별 2~6년에서 최소 2년에 1회로 단축했습니다. 그 이전에는 저장 자체가 열려 있지 않았고, 이후에도 "누구나 저장할 수 있다"가 된 것은 아닙니다. 자격을 심사받은 곳만 예외적으로 들고 있을 수 있는 값입니다.

일반 가맹점 입장에서 이 구조가 뜻하는 것은 단순합니다. 카드정보를 직접 들고 있는 선택지가 애초에 없습니다. 포트원 연동 문서도 이 사정을 그대로 적어 두었습니다. "고객사가 고객의 카드정보를 저장할 수 없기 때문에, 해당 카드에 대응하는 빌링키를 발급 받아 저장하고, 결제 시점에는 결제 정보 대신 빌링키를 이용하여 요청하는 방식을 씁니다."

Recap​

  • 온라인 카드 승인에는 카드번호·유효기간 등이 필요하고, 그 조합은 실물 카드 없이도 결제를 낼 수 있는 값입니다.
  • 전자금융거래법은 접근매체의 발급과 양도·양수를 규율하고(제2조 제10호, 제6조 제2항·제3항), 여신전문금융업법은 부정한 방법으로 알아낸 카드정보의 보유 자체를 처벌합니다(제70조 제1항 제6호). 정상적으로 받은 카드정보의 저장 가능 여부를 정하는 것은 이 조문들이 아닙니다.
  • 카드정보 저장이 열린 것은 2014년 금융위원회의 정책과 표준약관 개정으로 일정 요건을 갖춘 PG사에 한정된 예외이고, 일반 가맹점에는 그 선택지가 없습니다.

2. 규칙이 한 층이 아니다​

카드정보를 다룰 때 지켜야 하는 규칙은 출처가 서로 다른 네 층으로 쌓여 있습니다. 이 층을 섞어 말하면 "법으로 금지되어 있다"는 문장이 어디까지 참인지 알 수 없게 됩니다.

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

세 번째 층이 자주 오해를 부릅니다. 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는 승인이 끝난 뒤에는 아무도 들고 있을 수 없습니다. 그래서 카드정보를 그대로 보관해 매달 재사용하는 방식은, 설령 저장 자격을 갖춘 곳이라도 표준이 허락하는 모양이 아닙니다. 원본이 아닌 다른 값이 필요해집니다.

Recap​

  • 카드정보를 둘러싼 규칙은 법률·감독규정·카드 브랜드 표준·카드사 심사의 네 층이고, 어겼을 때의 결과가 각각 다릅니다.
  • PCI DSS는 법령이 아니고 PCI SSC라는 국제 카드 브랜드 협의체의 표준이며, 준수를 요구하고 검증하는 주체는 카드 브랜드와 매입사입니다.
  • PCI DSS는 승인 이후 CVC·트랙 데이터·PIN의 저장을 금지하므로, 원본 카드정보를 재사용하는 정기결제는 표준 안에서 성립하지 않습니다.

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

빌링키는 카드정보를 대신하는 식별자입니다. 토스페이먼츠 개발자센터는 빌링키를 결제 타입에 따라 "카드번호, 유효기간, CVC, 계좌번호 등 결제 정보를 암호화한 값"으로 설명하고, 포트원은 "고객사가 원하는 시점에 결제를 일으키기 위한 결제용 비밀 키"로 설명합니다. 표현은 다르지만 하는 일은 같습니다. 원본은 자격을 갖춘 쪽에 남고, 가맹점은 그것을 가리키는 이름만 받습니다.

빌링키만 있으면 결제가 되는 것은 아닙니다. 발급받을 때 사용한 customerKey(구매자 식별자)를 승인 요청에도 함께 보내야 합니다. 두 값이 짝을 이룰 때만 "이 고객의 이 결제수단"이 특정됩니다. 빌링키는 발급받은 가맹점의 맥락 안에서만 뜻을 갖습니다. 카드번호는 그런 제약 없이 어디서나 통합니다.

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

보관하는 값유출되면 어디까지 쓰이나무르는 방법일반 가맹점이 보관
카드번호 + 유효기간 + CVC카드가 통하는 어느 가맹점에서든카드 재발급불가
빌링키 + customerKey그 가맹점의 시크릿 키가 함께 있어야 승인 요청 가능빌링키 폐기 후 재발급가능

카드번호를 잃어버리면 카드를 다시 만드는 것 말고는 되돌릴 길이 없고, 그 부담은 카드를 쓴 사람에게 갑니다. 빌링키는 서버에서 지우고 다시 발급받으면 끝입니다. 되돌릴 수 있는 값으로 바꿔 놓았다는 점이 빌링키가 가져온 실질적인 변화입니다.

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

Recap​

  • 빌링키는 카드정보를 대신하는 식별자이고, 원본은 저장 자격을 갖춘 PG·카드사 쪽에 남습니다.
  • 빌링키는 단독으로 쓸 수 없습니다. 발급 때 쓴 customerKey와 짝을 이루고, 승인 요청에는 가맹점의 시크릿 키가 필요합니다.
  • 카드번호는 유출되면 카드 재발급밖에 답이 없지만 빌링키는 폐기 후 재발급으로 끝납니다. 다만 고객 개입 없이 결제가 나가므로 카드사 심사에서 용도를 따집니다.

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

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

인증결제는 결제 도중에 카드사가 사람을 확인합니다. 카드사 앱이나 SMS로 본인인증을 거친 뒤 승인이 진행되고, 국내 온라인 결제의 일반적인 방식입니다. 비인증결제(키인결제)는 그 확인 없이 카드번호와 유효기간 등을 입력받아 곧바로 승인을 요청합니다. 콜센터 주문이나 법인카드 결제처럼 인증 절차를 끼우기 어려운 자리에서 쓰이고, 도용 위험이 있어 카드사 심사가 까다롭습니다. 토스페이먼츠는 카드정보만 입력받는 "카드번호 결제"를 도용과 사기 위험이 높다는 이유로 제공하지 않는다고 밝혀 두었습니다.

인증이 옮기는 것은 확인 절차 하나로 끝나지 않습니다. 책임이 함께 움직입니다.

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

책임 전가(liability shift)는 이 규격이 정하는 것이 아닙니다. 어떤 인증을 거친 거래에서 부정사용 손실을 누가 지는지는 카드 브랜드의 운영규정이 정하고, 국내 거래의 책임 분배는 카드사와 가맹점 사이의 계약을 따릅니다. EMVCo가 공개한 규격 설명에는 책임의 이동을 다루는 대목이 없습니다. 인증을 거쳤는지가 책임이 놓이는 위치를 바꾼다는 방향까지가 이 층위에서 말할 수 있는 전부입니다.

안심클릭과 ISP는 3-D Secure의 국내 이름

3-D Secure는 국내에 들어오면서 안심클릭(MPI), ISP(인터넷 안전 결제) 같은 이름으로 불렸습니다. 서로 다른 기술처럼 보이지만 같은 계보의 프로토콜이고, 그 뒤 카드사 앱 인증으로 사용자 경험이 바뀌면서 이름의 존재감이 옅어졌습니다. 오래된 PG 연동 문서나 코드에서 이 단어를 만나면 온라인 본인인증 단계를 가리킨다고 읽으면 됩니다.

정기결제는 이 두 갈래 사이에 앉아 있습니다. 매달 결제할 때마다 본인인증을 요구하면 자동결제라는 말 자체가 성립하지 않습니다. 그래서 빌링키 발급 시점에 인증을 한 번 몰아서 받습니다. 토스페이먼츠 문서의 표현대로 "최초의 본인인증으로 발급된 빌링키가 이후의 본인인증 과정을 대신합니다".

그 결과 최초 1회가 유일한 인증 지점이 됩니다. 이후 모든 청구의 정당성이 그 한 번의 확인 위에 얹히므로, 발급 단계를 어떻게 통과시켰는지가 나중의 분쟁에서 그대로 되돌아옵니다. 결제창으로 발급하면 인증은 PG와 카드사가 처리하고, 카드정보는 가맹점 화면을 지나지 않습니다. API로 직접 발급하는 길도 있습니다. 이때는 자체 화면에서 카드번호와 유효기간 등을 입력받으므로 카드정보가 가맹점을 경유하는데, 경유가 열렸다고 저장까지 열리는 것은 아닙니다. 원본을 남겨 두는 것은 여전히 막혀 있고, 그래서 이 방식에는 별도 심사와 추가 계약이 붙습니다(2026년 8월 확인 기준의 연동 관행입니다).

Recap​

  • 여신전문금융업법 제19조 제2항은 가맹점에게 거래마다 본인의 정당한 사용을 확인하도록 하고, 온라인에서는 이 확인을 인증결제와 비인증결제 중 무엇으로 대신하느냐가 갈립니다.
  • 3-D Secure의 현행 규격은 EMVCo가 관리하는 EMV 3DS이고, 발급사가 위험을 평가해 필요할 때만 추가 확인을 요구합니다. 인증 여부가 부정사용 책임의 위치를 바꾸는데, 그 배분은 카드 브랜드 운영규정과 카드사·가맹점 계약이 정합니다.
  • 정기결제는 빌링키 발급 시점의 본인인증 한 번으로 이후 청구를 대신하므로, 발급 단계의 인증 방식이 곧 분쟁 시의 책임 위치가 됩니다.

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

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

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

자동결제로 넘어오면 이 원칙이 더 선명해집니다. 2회차 이후에는 브라우저가 아예 없습니다. 서버의 스케줄러가 정해진 날짜에 빌링키로 승인 API를 호출합니다. 토스페이먼츠는 자체 스케줄링을 제공하지 않으므로 그 주기를 가맹점이 직접 구현해야 한다고 안내합니다. 승인을 낼 수 있는 지점이 서버 한 곳으로 좁혀지는 셈이고, 그래서 빌링키를 보관하는 위치가 그대로 신뢰 경계가 됩니다.

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

Recap​

  • 성공 URL의 쿼리 파라미터는 브라우저를 지나온 값이므로 위·변조를 전제하고 다뤄야 하고, 금액은 서버가 저장해 둔 값과 대조해야 합니다.
  • 승인은 서버가 승인 API를 호출해 PG의 응답을 받은 시점에 확정되며, 시크릿 키는 클라이언트로 내려가지 않습니다.
  • 자동결제는 2회차부터 클라이언트가 없고 서버 스케줄러가 빌링키로 호출하므로, 빌링키의 보관 위치가 신뢰 경계가 됩니다.

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

월 9,900원 구독 하나를 앞 단원들의 규칙에 차례로 통과시켜 보겠습니다. 구매자는 1월 5일에 결제창에서 카드를 등록하고, 이후 매달 5일에 청구가 나갑니다.

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

2월 5일, 첫 자동결제. 스케줄러가 빌링키와 customerKey로 승인 API를 호출하고, 구매자는 아무것도 하지 않습니다. 이 청구의 본인 확인은 1월 5일의 인증 한 번으로 대신됩니다. 서버는 응답으로 승인 결과를 확인한 뒤 이용권을 연장합니다.

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

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

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

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

매달 빠져나간 9,900원을 끌어낸 값은 카드번호가 아닙니다. 1월 5일 단 한 번의 본인 확인을 대신 들고 있는 식별자 하나와, 그 식별자를 쓸 자격이 있는 서버의 시크릿 키입니다.

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

Recap​

  • 정기결제 한 건에서 가맹점 서버에 남는 것은 빌링키와 customerKey이고, 결제창 방식에서는 카드번호·유효기간·CVC가 처음부터 넘어오지 않습니다.
  • 2회차 이후 청구의 본인 확인은 최초 발급 시점의 인증 한 번으로 대신되고, 원본 카드가 바뀌면 무엇을 저장했든 그 값은 낡습니다.
  • 잘못 나간 청구에 대응하려면 빌링키의 발급·폐기 시각과 청구별 이력이 남아 있어야 합니다. 정정 요구에 2주 이내로 원인과 결과를 알릴 의무를 지는 쪽은 금융회사와 전자금융업자이고(전자금융거래법 제8조), 가맹점은 그 조사에 답할 기록을 갖는 쪽입니다.

References​

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