Repository navigation
Add NxtSupport::Iban - #172
Merged
Merged
Conversation
Upstreamed from payment-service, where the iOS app sends IBANs with a space every four characters and nothing between the controller and the PSP normalised them. The stored value then differed from the same IBAN entered without spaces, which broke last4 derivation and exact-string comparisons against a ban list. The normalisation itself is generic — upcase, drop whitespace — and every service that stores an IBAN wants it, so it belongs here rather than in one app. It does not validate: callers keep using their own IBAN validator. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
nsommer
force-pushed
the
add-iban-normalization
branch
from
September 16, 2026 08:13
09330cc to
d7006ca
Compare
All three read from the normalized form, so they answer the same for an IBAN typed with spaces as for one typed without — which is the bug that motivated the class: payment-service derived last4 from the raw string, and a German IBAN ending "0130 00" yielded "0 00". country_code and last4 return nil rather than an empty string for a missing IBAN, so a blank value cannot silently reach a field that shows the last four digits. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
An IBAN is personal data and regularly ends up in a log line, an error message or a support tool. Masking it at the call site is easy to forget and easy to get wrong, so give the class a reader that cannot leak. It masks the whole value rather than the usual all-but-last-four when the IBAN is four characters or shorter, where revealing the last four would reveal all of it, and returns an empty string for a missing IBAN so that "****" never implies a value that is not there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A redacted IBAN is mostly read by someone trying to tell two accounts apart in a log or a support tool, and the country code does that work without giving up anything that identifies the account. The threshold for masking the last four characters as well moves up accordingly: the country code is now visible, so four more characters would reveal the whole of a six character IBAN rather than a four character one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
nsommer
requested review from
AkihikoITOH,
a-berg-gs,
bigzoo,
chiibis,
mitnal,
mrid-l and
turhaug
September 16, 2026 08:31
chiibis
approved these changes
Sep 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
References
Upstreamed from payment-service IX-3421 (payment-service#4898)
Problem
The iOS app sends IBANs with a space every four characters. In payment-service nothing between the controller and the PSP normalised them, so the stored value differed from the same IBAN typed without spaces —
last4was derived from the spaced string, and exact-string comparisons against the ban list silently missed those rows.The normalisation itself is generic. Every service that stores an IBAN wants the same five lines, so it belongs in the gem rather than in one app.
Solution
NxtSupport::Iban.normalize(iban)upcases and strips all whitespace:It does not validate — callers keep using their own IBAN validator (payment-service uses
SEPA::IBANValidator). Non-strings are returned unchanged, and the input is not mutated.#to_s,#country_code,#last4and#redacted_sall read from the normalized form, so they answer the same for an IBAN typed with spaces as for one typed without:#redacted_sis for anywhere an IBAN would otherwise reach a log line, an error message or a support tool. It keeps the country code and the last four characters — enough to tell two accounts apart — and masks everything between. On an IBAN of six characters or fewer, the last four would give the rest away, so only the country code survives.#to_sand#redacted_sreturn''for a missing IBAN;#country_codeand#last4returnnilrather than'', so a blank value cannot silently reach a field that shows the last four digits.Changes
NxtSupport::IbanunderNxtSupport/Util, next toBirthDate#to_s,#country_code,#last4and#redacted_sderived from the normalized formIbanNormalizerspec, plus coverage for the four readersVERSION→0.7.0, CHANGELOG entryOnce this is released, payment-service drops its own
IbanNormalizerand points its 13 call sites here.🤖 Generated with Claude Code