Summary

  • Stripe Radar의 빈도 속성은 평가 중인 결제를 세지 않는다. authorized_charges_per_email_hourly는 같은 이메일의 직전 한 시간 내 첫 시도에서 0이고, 첫 결제가 승인되면 두 번째 시도에서 1이 된다.
  • 앞선 두 건이 모두 그 한 시간 안에 승인됐다면 > 1은 세 번째 시도에서 처음 일치한다. >= 1이라면 두 번째부터 가능하다. 실제 결제 결과에는 다른 규칙과 카드 발급사의 결정도 작용한다.

카운터 앞에 서 있는 손님

상점 운영자는 같은 주소에서 결제가 연달아 오면 속도를 줄이고 싶다. 대시보드에 빈도 규칙을 만들 수 있는 Radar 요금제를 쓴다면 숫자와 부등호로 그 의도를 표현한다. 문제는 숫자가 어느 시점의 기록인가 하는 점이다. Stripe의 공식 가이드는 현재 처리하는 결제를 빈도 계산에서 빼라고 분명히 적었다. 지금 계산대에 선 손님은 아직 그 기록의 일부가 아니다.

가이드의 authorized_charges_per_email_hourly 예시는 이 차이를 보여준다. 같은 이메일에서 직전 한 시간 동안 성공한 승인 건이 없다면 첫 시도의 값은 0이다. 첫 시도가 승인되면 두 번째는 1을 본다. 두 번째도 승인되면 세 번째가 2를 본다. 이 순서에서 > 1은 세 번째에서야 처음 맞고, >= 1은 두 번째에서 맞는다. 한 시간은 고정된 시각 단위가 아니라 각 결제 시점부터 거슬러 올라가는 구간이므로, 오래된 승인 건이 빠지면 값도 내려간다.

무엇을 세는지도 중요하다. Stripe는 발급사가 승인한 결제, 청구 시도, 발급사의 거절, Radar 기계학습 모델의 차단을 따로 구분한다. 거절 시도가 여러 번 발생해도 성공한 승인 건수는 늘지 않는다. 상점이 만든 차단 규칙의 결과를 모델의 차단 건수로 곧바로 읽을 수도 없다. 운영팀이 시도 횟수를 걱정하면서 승인 건수만 살피면, 위험이 커지는 동안 숫자는 조용할 수 있다.

Stripe의 현재 규칙 문서는 기본 Radar 규칙이 모든 거래를 심사하며 사용자 정의 규칙은 해당 기능을 지원하는 요금제에서 만들 수 있다고 설명한다. 가이드는 허용, 차단, 검토 규칙의 우선순위도 밝힌다. 허용 규칙이 뒤의 차단보다 먼저 작동할 수 있다. 한 계수기가 0이라고 해서 결제가 자동으로 통과하는 것은 아니다.

공유 IP에는 서로 모르는 정상 구매자가 모일 수 있고, 이메일을 계속 바꾸는 사람은 이력을 여러 칸에 나눌 수 있다. 어느 상점이 실제로 어떤 규칙을 쓰는지, 몇 건의 정상 매출을 잃었는지는 공개 문서에 없다. 개별 결제를 판단하려면 적용된 규칙, 당시 계수기 값, 최종 처리 기록이 필요하다.

Sources