[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