antiwork/gumroad · error · StripeBeneficialOwnersManager::InvalidFieldError

Your Cédula de Ciudadanía or Cédula de Extranjería must be 6

Error message

Your Cédula de Ciudadanía or Cédula de Extranjería must be 6-10 digits. Enter it exactly as it appears on your document — do not add leading zeros, as the number has to match the document you may later be asked to upload.

What it means

InvalidFieldError from StripeBeneficialOwnersManager.validate_colombia_id_number! when a Colombian seller's beneficial owner/representative submits an id_number that fails Compliance::ColombiaIdNumber.valid? (Cédula de Ciudadanía / Cédula de Extranjería must be 6-10 digits, no leading zeros added by the user). It only runs when the user's alive compliance info country is CO, and it exists because the form's maxLength counts characters, so a formatted "1.123.456.789" can pass the input while carrying too few digits — Stripe would reject it after a rolled-back create. Blank values are skipped.

Source

Thrown at app/business/payments/merchant_registration/implementations/stripe/stripe_beneficial_owners_manager.rb:228

  def self.validate_kana_param!(value, label, regex, allowed_description)
    value = value.to_s
    return if value.blank?
    return if value.match?(regex)
    raise InvalidFieldError, "#{label} may only contain #{allowed_description}."
  end
  private_class_method :validate_kana_param!

  # The form's maxLength counts characters so a pasted "1.123.456.789" fits, which means a value can
  # satisfy the input and still carry too few digits. Checking digits here — and normalizing in
  # build_person_params — keeps this path from handing Stripe a number it will refuse, which is the
  # rolled-back-create failure that left one seller with eight silent attempts.
  def self.validate_colombia_id_number!(params, user)
    return unless user.alive_user_compliance_info&.legal_entity_country_code == Compliance::Countries::COL.alpha2
    id_number = params[:id_number].to_s
    return if id_number.strip.blank?
    return if Compliance::ColombiaIdNumber.valid?(id_number)
    raise InvalidFieldError, Compliance::ColombiaIdNumber::ERROR_MESSAGE
  end
  private_class_method :validate_colombia_id_number!

  def self.representative?(person)
    relationship = person.is_a?(Hash) ? person[:relationship] || person["relationship"] : person[:relationship]
    !!(relationship && (relationship[:representative] || relationship["representative"]))
  end
  private_class_method :representative?

  def self.symbolize(value)
    case value
    when Hash then value.deep_symbolize_keys
    when Stripe::StripeObject then value.to_hash.deep_symbolize_keys
    else value
    end
  end
  private_class_method :symbolize

View on GitHub (pinned to afeacbd394)

Solutions

  1. Enter the Cédula exactly as printed on the document: 6-10 digits, no extra leading zeros, then resubmit.
  2. If building the form, validate with the same rule client-side (strip separators, count digits, reject outside 6-10) instead of relying on maxLength.
  3. Normalize (strip dots/spaces) before sending — build_person_params normalizes, but the value must still be a valid document number afterwards.
  4. Do not upload/pad zeros to reach 6 digits — the number must match the physical document the seller may later be asked to upload.

Example fix

# before
params[:id_number] = "1.123.456"   # 7 digits, dots counted by maxLength
# after
params[:id_number] = "1023456789" # exactly the digits on the Cédula, 6-10, no added zeros
Defensive patterns

Strategy: validation

Validate before calling

digits = id_number.to_s.gsub(/[^0-9]/, "")
Result.invalid(Compliance::ColombiaIdNumber::ERROR_MESSAGE) unless (6..10).cover?(digits.length) && !digits.start_with?("0")

Type guard

def valid_colombia_cedula?(id_number)
  Compliance::ColombiaIdNumber.valid?(id_number.to_s)
end

Prevention

When it happens

Trigger: Creating/updating a beneficial owner for a user whose legal_entity_country_code is "CO" with params[:id_number] present but not 6-10 digits — e.g. "1.123.456" (7 digits after normalization fails the range) or with user-added leading zeros.

Common situations: Sellers typing the document number with dots/commas and dropping digits; users padding with leading zeros believing the document stores them; front-end maxLength giving false confidence; the historical rolled-back-create incident (eight silent attempts) this guard now prevents.

Related errors


AI-assisted analysis of antiwork/gumroad@afeacbd394 (2026-08-21). Data as JSON: /api/errors/2a92ef009d01ea5b. Report an issue: GitHub.