antiwork/gumroad · error · StripeBeneficialOwnersManager::InvalidFieldError

#{label} must include katakana characters.

Error message

#{label} must include katakana characters.

What it means

InvalidFieldError from StripeBeneficialOwnersManager.validate_jp_kana_address_format! (StripeBeneficialOwnersManager.validate_jp_kana_address_format!). For Japanese beneficial owners, Stripe requires the kana address block; the town/cho-me (street_address_kana) and city/ward (city_kana) values must actually contain katakana — digits-and-dashes-only values like "1-1" pass the character whitelist but fail here. Blank values are skipped; the check mirrors the browser-side rules so client and server agree.

Source

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

    # request with a blank country would skip these checks and still be sent to Stripe as a
    # Japanese kana address.
    address_country = address[:country].to_s.strip.presence || user.alive_user_compliance_info&.legal_entity_country_code
    return unless address_country == Compliance::Countries::JPN.alpha2

    { building_number_kana: "Block / Building number (Kana)",
      street_address_kana: "Town/Cho-me (Kana)",
      city_kana: "City/Ward (Kana)" }.each do |key, label|
      validate_kana_param!(address[key], label, UserComplianceInfo::KANA_ADDRESS_REGEX, "katakana, latin characters, digits, spaces, dashes, and dots")
    end

    # The building number is often just digits and dashes (e.g. "1-1"), so only the town and
    # city fields must actually contain katakana — matching the browser-side rules.
    { street_address_kana: "Town/Cho-me (Kana)",
      city_kana: "City/Ward (Kana)" }.each do |key, label|
      value = address[key].to_s
      next if value.blank?
      next if value.match?(UserComplianceInfo::HAS_KATAKANA)
      raise InvalidFieldError, "#{label} must include katakana characters."
    end
  end
  private_class_method :validate_jp_kana_address_format!

  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

View on GitHub (pinned to afeacbd394)

Solutions

  1. Enter the town/cho-me and city/ward in katakana (e.g. "シブヤ" not "Shibuya") in the two kana fields and resubmit.
  2. Keep the other kana fields (block/building) consistent with the whitelist check — they only need valid characters, not actual katakana.
  3. If building a client, replicate the browser-side rule: require HAS_KATAKANA on those two fields before submit to avoid the round trip.
  4. For data imports, run a kana conversion (romaji->katakana) or leave the fields blank rather than duplicating latin values.

Example fix

# before
address = { street_address_kana: "1-1", city_kana: "Shibuya", ... }
# after (katakana in the two fields that require it)
address = { street_address_kana: "ジンヤマエ1-1", city_kana: "シブヤ", ... }
Defensive patterns

Strategy: validation

Validate before calling

KATAKANA = /[\p{Katakana}]/
return if value.blank?
raise InvalidFieldError unless KATAKANA.match?(value)

Type guard

def contains_katakana?(value)
  value.to_s.match?(UserComplianceInfo::HAS_KATAKANA)
end

Prevention

When it happens

Trigger: Submitting a JP beneficial owner with street_address_kana or city_kana filled in only with latin/digits/dashes/spaces (e.g. "1-1" or "Shibuya") with no katakana characters (UserComplianceInfo::HAS_KATAKANA does not match).

Common situations: Sellers pasting the romaji/latin address into the kana fields; IME left in latin mode so the kana conversion never happened; form prefill copying the kanji/latin address block into the kana block; automated imports using the latin address for all four address variants.

Related errors


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