BKG 2.0, EBL 3.0: SD-2714, SD-2713: Add extendedChargeName

[HenrikHL]

User description

SD-2713: Add extendedChargeName and deprecate chargeName
SD-2714: Add extendedChargeName and deprecate chargeName

chargeName is mandatory - so it still needs to be provided. Deprecating it and adding the extendedChargeName next to it with an explanation that extendedChargeName takes precedence over chargeName

---

PR Type

Enhancement

---

Description

• Add extendedChargeName property allowing up to 100 characters

• Deprecate chargeName while maintaining backward compatibility

• Mark chargeName as deprecated in schema documentation

• Update charge description fields across multiple API specifications

---

Diagram Walkthrough

flowchart LR
  chargeName["chargeName<br/>50 chars<br/>deprecated"]
  extendedChargeName["extendedChargeName<br/>100 chars<br/>new property"]
  precedence["Precedence Logic"]
  chargeName -- "deprecated, kept for<br/>backward compatibility" --> precedence
  extendedChargeName -- "takes precedence<br/>when provided" --> precedence
  precedence -- "determines which<br/>value to use" --> output["Charge Description"]

Loading

File Walkthrough

	Relevant files
Enhancement	EBL_ISS_v3.0.3.yaml Add extendedChargeName and deprecate chargeName                    ebl/v3/issuance/EBL_ISS_v3.0.3.yaml Mark chargeName property as deprecated Add deprecation notice explaining backward compatibility requirement Introduce new extendedChargeName property with 100 character limit Document precedence rule: extendedChargeName takes priority over chargeName +12/-0    EBL_PINT_v3.0.0.yaml Add extendedChargeName and deprecate chargeName                    pint/v3/EBL_PINT_v3.0.0.yaml Mark chargeName property as deprecated Add deprecation notice explaining backward compatibility requirement Introduce new extendedChargeName property with 100 character limit Document precedence rule: extendedChargeName takes priority over chargeName +12/-0    EBL_v3.0.3.yaml Add extendedChargeName and deprecate chargeName                    ebl/v3/EBL_v3.0.3.yaml Mark chargeName property as deprecated Add deprecation notice explaining backward compatibility requirement Introduce new extendedChargeName property with 100 character limit Document precedence rule: extendedChargeName takes priority over chargeName +12/-0    BKG_v2.0.4.yaml Add extendedChargeName and deprecate chargeName                    bkg/v2/BKG_v2.0.4.yaml Mark chargeName property as deprecated Add deprecation notice explaining backward compatibility requirement Introduce new extendedChargeName property with 100 character limit Document precedence rule: extendedChargeName takes priority over chargeName +12/-0
Configuration changes	styleguide.json Update styleguide configuration                                                    .stoplight/styleguide.json Configuration file modifications related to style guide updates +1/-1

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟡	🎫 #SD-2713 🟢 Extend the charge name capability by adding a new extendedChargeName property with maxLength: 100. Deprecate the existing `chargeName` property (which remains limited to 50 characters). ⚪ Confirm that chargeName is still required where mandated (and that any required-property lists have not been unintentionally changed), while extendedChargeName is optional. Confirm runtime/consumer precedence behavior (“if both provided, ignore chargeName”) is implemented/handled wherever payloads are processed (beyond documentation/schema text).
🟡	🎫 #SD-2714 🟢 Extend the charge name capability by adding a new extendedChargeName property with maxLength: 100. Deprecate the existing `chargeName` property (which remains limited to 50 characters). ⚪ Confirm that chargeName is still required where mandated (and that any required-property lists have not been unintentionally changed), while extendedChargeName is optional. Confirm runtime/consumer precedence behavior (“if both provided, ignore chargeName”) is implemented/handled wherever payloads are processed (beyond documentation/schema text).
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[Copilot]

Pull request overview

This PR deprecates the chargeName field and introduces a new extendedChargeName field across multiple API specifications (BKG 2.0, EBL 3.0, and PINT 3.0). The new field increases the maximum character limit from 50 to 100 characters and takes precedence when both fields are provided.

Changes:

• Marked chargeName as deprecated with clear migration guidance
• Added extendedChargeName field with 100-character limit and precedence rules
• Applied changes consistently across four YAML specification files

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 4 comments.

File	Description
pint/v3/EBL_PINT_v3.0.0.yaml	Added deprecation and extended field for charge names in PINT specification
ebl/v3/issuance/EBL_ISS_v3.0.3.yaml	Added deprecation and extended field for charge names in EBL issuance specification
ebl/v3/EBL_v3.0.3.yaml	Added deprecation and extended field for charge names in main EBL specification
bkg/v2/BKG_v2.0.4.yaml	Added deprecation and extended field for charge names in BKG specification

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

There is inconsistent trailing whitespace in the description. Line 3577 has trailing whitespace while similar lines in other files may not, which can cause inconsistencies in documentation formatting.

Suggested change

[Copilot]

There is inconsistent trailing whitespace in the description. Line 2824 has trailing whitespace while similar lines in other files may not, which can cause inconsistencies in documentation formatting.

Suggested change

[Copilot]

There is inconsistent trailing whitespace in the description. Line 8766 has trailing whitespace while similar lines in other files may not, which can cause inconsistencies in documentation formatting.

Suggested change

[Copilot]

There is inconsistent trailing whitespace in the description. Line 7015 has trailing whitespace while similar lines in other files may not, which can cause inconsistencies in documentation formatting.

Suggested change

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
High-level	Consider a simpler API evolution strategy Instead of adding a new extendedChargeName field with complex precedence logic, consider simply increasing the maxLength of the existing chargeName field. This change should be part of a new minor version release to ensure proper API versioning. Examples: bkg/v2/BKG_v2.0.4.yaml [7000-7017] type: string pattern: ^\S(?:.*\S)?$ maxLength: 50 deprecated: true description: | Free text field describing the charge to apply **DEPRECATED:** Because of backward compatibility it is required to provide a value in this property even though a value is provided in the `extendedChargeName` property. In case both properties are provided (`extendedChargeName` and `chargeName`) - `chargeName` must be ignored. example: Documentation fee - Destination extendedChargeName: ... (clipped 8 lines) ebl/v3/EBL_v3.0.3.yaml [8751-8768] type: string pattern: ^\S(?:.*\S)?$ maxLength: 50 deprecated: true description: | Free text field describing the charge to apply **DEPRECATED:** Because of backward compatibility it is required to provide a value in this property even though a value is provided in the `extendedChargeName` property. In case both properties are provided (`extendedChargeName` and `chargeName`) - `chargeName` must be ignored. example: Documentation fee - Destination extendedChargeName: ... (clipped 8 lines) Solution Walkthrough: Before: Charge: properties: chargeName: type: string maxLength: 50 deprecated: true description: "**DEPRECATED:** ... required for backward compatibility ... must be ignored if extendedChargeName is provided" extendedChargeName: type: string maxLength: 100 description: "**Note:** ... takes precedence over chargeName" # ... other properties required: - chargeName # ... After: # In a new minor version (e.g., v2.1.0, v3.1.0) Charge: properties: chargeName: type: string maxLength: 100 description: "Free text field describing the charge to apply" # ... other properties required: - chargeName # ... Suggestion importance[1-10]: 9 __ Why: This is a critical design suggestion that challenges the PR's core approach, proposing a cleaner, more maintainable long-term solution that avoids API complexity.	High
Possible issue	Clarify backward compatibility field handling Clarify the deprecation notice for chargeName by instructing users to provide a truncated version of extendedChargeName to meet the 50-character limit for backward compatibility. ebl/v3/issuance/EBL_ISS_v3.0.3.yaml [2816] -**DEPRECATED:** Because of backward compatibility it is required to provide a value in this property even though a value is provided in the `extendedChargeName` property. In case both properties are provided (`extendedChargeName` and `chargeName`) - `chargeName` must be ignored. +**DEPRECATED:** Because of backward compatibility it is required to provide a value in this property even though a value is provided in the `extendedChargeName` property. If `extendedChargeName` is provided, this field should contain a truncated version of the `extendedChargeName` value (first 50 characters). In case both properties are provided (`extendedChargeName` and `chargeName`) - `chargeName` must be ignored by consumers. Apply / Chat Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies an ambiguity in the API documentation regarding how to populate the deprecated chargeName field when its length limit is exceeded by extendedChargeName, preventing potential client-side validation errors.	Medium
Update