[bop-devel] AuthorizeNet MD5 Check

Bill Moseley moseley at hank.org
Tue Sep 25 14:43:01 PDT 2007


On Tue, Sep 25, 2007 at 02:18:25PM -0700, Ivan Kohler wrote:
> > Looks like you should pick some odd character (tilde?) as the
> > delimiter and remove it from imput.
> 
> No.
> 
> Take a look at the bug report; the submitter makes a good case for *not* 
> modifying the input.  It might not be a priority for me personally, but 
> I'm convinced enough that we should avoid it if possible.

Sorry, I mean "you" as "one" should (the application using B::OP::AN).
;)

Yes, the delimiter should be set (or default to something unlikely)
and die if used in input.

Since you have to pick some a delimiter that isn't used in input (or
in the response) then I don't really see a need for using
x_encap_char.

I'm still scratching my head on that one -- if they provide a way to
define x_encap_char then wouldn't there also need to be a way to define
a way to escape that char?

I need to get a test account setup so I can test to see if that's
still the case.  Seems like a glaring hole.

For CSV the point of the quotes is to allow embedded commas.  And CSV
provides a way to escape the quotes.  That's the part that's missing
from the AIM interface.

> Ideally, the module should scan the input and pick a delimiter 
> on-the-fly that isn't contained in the input data.  That way the only 
> case where we would have to throw a fatal error would be the rare case 
> where the input contained every possible character.

Seems reasonable.  At least as a work-around for A.net.


> > Authorize.net is scaring me.
> 
> I see you haven't worked with gateways before.  Authorize.net is one of 
> the better ones.

Maybe I'll propose that we only accept cash payments in the web
application.

-- 
Bill Moseley
moseley at hank.org



More information about the bop-devel mailing list