[bop-devel] Unifying the data sent to B:OP modules

[Ivan Kohler]

On Thu, Dec 07, 2006 at 09:08:52AM -0800, Jo Rhett wrote:
> Ivan Kohler wrote:
> >>Frankly, all the obvious questions.  What data formats are supported for 
> >>each and every method?  I'm one of those annoying programmers that 
> >>thinks that you shouldn't have to read the code to use a library :-)
> >>(I almost always end up doing so, but it annoys me)
> >
> >I don't think this is particularly well defined/constrained, other than 
> >the obvious (card numbers have to be card numbers, etc.), so it isn't 
> >surprising there isn't documentation.
> 
> Um, no.

I'm not sure what you're saying is incorrect here.  

These fields are not well defined/constrained by B:OP, in much the way 
you outline below, and thus there isn't good documentation on that.  I'm 
not sure how you misunderstood that to mean something else.

Perhaps you could stop assuming I disagree with you or are arguing 
against any of your ideas?  :)

>  Pretty much every single field I've had to read the gateway 
> modules to find out what is required.  Examples:
> 
> 1. Acceptable formats for expiration date
> 2. Whitespace/dashes in card number
> 3. Zip code formats accepted
> 4. First name, last name versus Fullname
> 5. Address numbers supplied in a different field
> 6. What AVS options are supported
> 7. What test options are supported
> 8. What values does the gateway accept for card type?
> 9. Does the gateway require card type?
> 
> Likewise, you have to read the module documentation to learn
> 
> 1. What the AVS return information will tell you
> 2. What the test options will tell you
> ...etc
> 
> All of these require if/then/else around the payment processor in your 
> main source code.  If we unified these answers and then let the payment 
> processor munge them as necessary, then it wouldn't matter.

Sounds good.  Why don't you start with one of the items on your list, 
discuss your implementation outline/ideas on the list and give it a 
shot?  :)

-- 
_ivan