광고 계정 여러 개에 같은 카드를 등록하면 생기는 일 — 대행사 결제 수단 분리 기준
여러 광고 계정에 동일한 결제 카드를 등록했을 때 실제로 어떤 증상이 나타나는지, 그리고 대행사가 쓸 수 있는 결제 수단 분리 기준과 운영 절차를 정리했습니다.
카드 한 장이 계정 열두 개를 묶어버린 날
대행사에서 계정을 관리하다 보면 결제 수단은 가장 늦게 신경 쓰는 항목입니다. 저도 그랬습니다. 브라우저 환경이나 IP, 로그인 시간대까지는 꼼꼼히 챘는데, 정작 광고비 결제는 "법인카드 한 장으로 다 돌리면 정산이 편하니까"라는 이유로 계정 열 개 넘게 같은 카드를 등록해 뒀습니다.
문제가 터진 건 그중 한 계정이 소재 심사 누적으로 제한을 받은 다음이었습니다. 그 계정만 멈추는 게 아니라, 같은 카드가 붙어 있던 다른 계정들에서 하루 이틀 사이에 심사 거절률이 눈에 띄게 올라갔습니다. 어떤 계정은 집행 중이던 캠페인이 검토 상태로 되돌아갔고, 두 개는 결제 수단 재확인 요청을 받았습니다. 플랫폼이 "당신들 같은 조직이죠?"라고 직접 말해주지는 않습니다. 그냥 조용히 같은 묶음으로 취급합니다.
그날 이후 저희 팀은 결제 수단을 계정 분리 설계의 1순위 항목으로 올렸습니다. 이 글은 그 과정에서 정리한 기준입니다.
결제 정보는 왜 그렇게 강한 연결 고리인가
쿠키나 브라우저 지문은 바꿀 수 있는 값입니다. 반면 결제 정보는 금융기관이 검증한 값이라는 점에서 성격이 다릅니다. 플랫폼 입장에서는 비용을 거의 들이지 않고 얻을 수 있는, 신뢰도가 높은 신호인 셈이죠.
광고 계정에 카드를 등록하면 보통 아래 정보가 함께 남습니다.
| 남는 정보 | 계정 연결에 쓰이는 방식 |
|---|---|
| 카드 BIN(앞 6~8자리) | 발급사·카드 종류 단위 묶음 |
| 카드 지문(해시) | 같은 카드가 여러 계정에 쓰였는지 대조 |
| 청구 명의자 이름 | 표기 차이까지 유사도로 비교 |
| 청구 주소·사업장 주소 | 동일 주소 다계정 판단 |
| 사업자 등록번호 | 가장 명확한 동일 조직 신호 |
| 결제 실패·환불 이력 | 조직 단위 위험도 점수에 반영 |
| 결제 시각 패턴 | 같은 시간대 일괄 결제 → 한 운영 주체 추정 |
여기서 많이들 놓치는 게 마지막 두 줄입니다. 카드를 다르게 써도 매달 같은 날 같은 시간에 여러 계정 결제를 몰아서 처리하면 그 자체가 패턴이 됩니다. 저희도 월초에 몰아 결제하던 습관을 바꾸는 데 시간이 걸렸습니다.
실제로 겪은 세 가지 증상
1) 심사 거절의 동시 발생
한 계정에서 정책 위반이 누적되면, 같은 결제 수단을 공유한 계정들의 소재 심사가 같이 보수적으로 바뀌는 흐름을 여러 번 관측했습니다. 평소 자동 승인되던 소재가 수동 검토로 넘어가고, 검토 대기 시간이 길어집니다. 인과를 단정할 수는 없지만, 저희 내부 기록에서는 상관관계가 반복적으로 나타났습니다.
2) 정지 전파
이게 가장 아픕니다. 한 계정이 비활성화되면서 "관련 계정"으로 분류된 다른 계정까지 같이 묶여 버리는 경우입니다. 이의 제기를 넣어도 심사자는 두 계정을 한 사안으로 봅니다. 그러면 멀쩡했던 계정의 운영 이력을 따로 소명해야 하는데, 결제 수단이 동일하다는 사실 자체를 뒤집을 방법이 없어서 설명이 길어집니다.
3) 환불·이의제기 연쇄
클라이언트가 이탈하면서 카드사 이의 제기(차지백)를 걸면, 그 카드가 붙어 있던 모든 계정이 한꺼번에 결제 위험 대상이 됩니다. 저희는 한 번 이 일을 겪고 나서, 클라이언트별 카드 분리를 계약서 수준으로 끌어올렸습니다.
대행사 결제 수단 분리 기준
모든 계정을 다 다른 카드로 만들 수는 없습니다. 카드 발급에도 한도가 있고, 경리 업무도 무한하지 않으니까요. 그래서 저희는 분리 강도를 세 단계로 나눠 운영합니다.
| 단계 | 적용 대상 | 분리 수준 |
|---|---|---|
| A (완전 분리) | 매출 비중 큰 클라이언트, 정지 이력 있는 계정, 서로 경쟁 관계인 브랜드 | 카드·명의·청구 주소·결제일 전부 분리 |
| B (부분 분리) | 같은 클라이언트의 복수 브랜드, 테스트용 계정 | 카드는 분리, 명의·주소는 공유 가능 |
| C (공유 허용) | 자사 운영 계정, 소액 리서치 계정 | 카드 공유, 대신 소액 한도로 제한 |
단계를 가르는 질문은 하나입니다. "이 계정이 묶여서 같이 죽으면 회사가 아픈가?" 아프다면 A, 불편하지만 복구 가능하면 B, 없어도 되면 C입니다. 이 기준이 좋은 이유는 담당자가 바뀌어도 판단이 거의 같게 나온다는 점입니다.
실무에서 쓰는 분리 수단
- 클라이언트 명의 카드 직접 등록: 가장 깔끔합니다. 저희 명의가 아예 안 들어가니 연결 고리가 생기지 않습니다. 대신 클라이언트 설득이 필요하고, 카드 정보 취급 범위를 계약서에 명시해야 합니다.
- 법인카드 복수 발급: 같은 법인 번호를 공유하므로 완전 분리는 아닙니다. 다만 카드 지문 단위 대조는 끊어줍니다. B 단계에 적합합니다.
- 기업 선불·충전식 수단: 한도 통제가 쉬워서 C 단계나 신규 계정 초기에 유용합니다. 일부 플랫폼이 선불 수단을 선호하지 않는다는 점은 감안해야 합니다.
- 계정별 담당자 명의 분리: 청구 명의를 다르게 할 수 있지만, 사람이 퇴사하면 승계가 번거롭습니다. 저희는 이 방식은 최소한으로만 씁니다.
분리할 때 가장 많이 나오는 실수
카드만 바꾸고 나머지는 그대로 두는 것. 카드를 나눠도 청구 주소가 동일한 사무실 주소면 연결은 남습니다. 저희도 처음엔 카드만 교체하고 안심했다가, 주소 필드가 전부 같다는 걸 뒤늦게 발견했습니다.
정지된 계정의 카드를 새 계정에 재사용하는 것. 가장 위험한 선택입니다. 새 계정은 이력이 없는데, 카드에는 이력이 남아 있습니다. 신규 계정이 시작부터 불리한 상태로 출발하는 셈이죠.
카드는 분리했는데 로그인 환경은 한 덩어리인 것. 이게 핵심입니다. 결제 수단은 여러 신호 중 하나일 뿐입니다. 같은 PC, 같은 브라우저, 같은 IP에서 계정을 번갈아 들어가면 결제 분리의 효과가 크게 줄어듭니다. 반대로 브라우저 지문과 접속 경로를 계정마다 나눠 두고도 결제 수단이 하나면, 그 한 줄 때문에 전부 묶입니다. 어느 한쪽만 하는 건 반쪽짜리입니다.
저희 팀은 그래서 계정 단위로 프로필을 만들고, 그 프로필에 브라우저 환경·접속 경로·결제 수단·담당자를 한 세트로 묶어 기록합니다. 안티디텍트 브라우저를 쓰는 이유도 거창한 게 아니라, "이 계정은 이 환경에서만 들어간다"를 사람이 기억하지 않아도 되게 만들기 위해서입니다. 사람 기억에 의존하면 바쁜 날 반드시 실수가 납니다.
지금 바로 확인할 체크리스트
1. 관리 중인 모든 계정의 등록 결제 수단을 한 시트에 뽑는다 (카드 끝 4자리 기준).
2. 같은 카드가 2개 이상 계정에 붙어 있는 조합을 전부 표시한다.
3. 그 조합 중 A 단계(묶이면 아픈) 계정이 있으면 우선 분리 대상에 올린다.
4. 청구 명의·청구 주소도 같은지 함께 확인한다. 카드만 보면 놓칩니다.
5. 정지 이력이 있는 계정의 카드가 다른 곳에 재사용되고 있는지 본다.
6. 월별 결제일이 한 날짜에 몰려 있으면 계정별로 분산한다.
7. 변경은 한 번에 몰아서 하지 않는다. 계정 하나씩, 며칠 간격으로.
마지막 7번을 강조하고 싶습니다. 결제 수단을 하루에 열 개 계정에서 동시에 바꾸면, 그 변경 자체가 이상 행동으로 읽힙니다. 저희는 보통 2~3일에 한 계정씩, 운영 흐름이 한가한 시간대에 처리합니다. 급하게 고치려다 더 큰 신호를 만드는 일이 생각보다 흔합니다.
정리하면, 결제 수단 분리는 기술이 아니라 운영 규칙의 문제입니다. 카드 몇 장을 더 발급하는 게 귀찮아 보이지만, 계정 하나 되살리는 데 드는 시간과 비교하면 비교가 안 됩니다. 아직 결제 수단 기준이 없는 팀이라면, 위 세 단계 표만이라도 먼저 만들어 두시길 권합니다. 저희는 그 표 하나로 팀 내 논쟁이 많이 줄었습니다.