Support CVV with leading zeroes

Support CVV with leading zeroes
Trim whitespace from string values
If you consider the real use-case here… it’s how the Client responds to
invalid user input (input that can’t be parsed as the appropriate type).

All objects have toString() so the use-case doesn’t apply to StringOrNull -
every Object can be rendered as a String.

But if you pass a non-integer to IntegerOrNull - you’ll receive a
NumberFormatException. So for integer properties, the Client is validating
the input and throwing an Exception if it doesn’t pass validation.

I agree with you that my PR’s behavior should be changed - we shouldn’t
simply ignore the input. But currently CVV is validated as an Integer &
converted to an Integer before calling the Recurly API - which is incorrect
because leading zeroes are valid input - so the options are:

   1. Validate CVV as a numeric (allow leading zeroes) and throw
   a NumberFormatException on failure
   2. Simply accept a string for CVV and let Recurly throw an error for the
   invalid input

As a user of the Client - I’d prefer #1 as it seems more consistent with
how Integer parameters are already handled.






On Sat, Aug 16, 2014 at 11:37 AM, Pierre-Alexandre Meyer <
notifications@github.com> wrote:

> In src/main/java/com/ning/billing/recurly/model/RecurlyObject.java:
>
> >
> > +        String value = object.toString().trim();
> > +        return value.matches("[0-9]+") ? value : null;
>
> This implementation of *OrNull is a bit different as it has logic to
> discard corrupted data (e.g. CVV == 'xyz'). I'm not quite comfortable with
> this. Instead, since the CVV will be a String in the Java model, I would
> simply use stringOrNull.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/killbilling/recurly-java-library/pull/44/files#r16325301>
> .
>



-- 
Eric Simmerman
President | Tempest Strings Enterprises, Inc.
ets@tempeststrings.com
US Tollfree: (888) 568-8585