[bop-devel] Python gateway module

[mock]

On Fri, Aug 25, 2006 at 12:42:59PM -0700, Ivan Kohler wrote:
> On Wed, Aug 23, 2006 at 08:54:21PM -0700, Jo Rhett wrote:
> > On Aug 23, 2006, at 5:20 PM, Ivan Kohler wrote:
> > >>Given that BOP is roughly halfway done
> > >
> > >Personally, I thought it was reasonably complete when I took it over
> > >four or five years ago, and I've always felt it needed maintenance,  
> > >some
> > >refactoring/cleanup and refining rather than any sort of major
> > >development.  What did you have in mind?
> > 
> > Well frankly, a more unified interface would be good.  I'm honestly  
> > not a user of this.  I developed our own common interface to all of  
> > the different payment gateways we support.  When I found that there  
> > was a open source project trying to do this, I jumped on it ready to  
> > get out of the business of being the sole maintainer of ours.
> > 
> 
> FWIW, I don't have any if/the/else logic for different payment gateways 
> in my use of B:OP.  You may want to get involved more and at least let 
> us know the specific differences that you're running into here.
>

I wrote and use Business::OnlinePayment::Multiplex to make some of this a
little saner for me.  Essentially it adds a call back to the content method
which can be used to present a bunch of B:OP modules with the same
interface as one (or you can round robin them, or whatever).
 
> > That said, you've got better support for shipping options, the  
> > security codes, and stuff that I still haven't gotten around to  
> > implementing.  So I still need to go forward.
> > 
> > bleh, not an answer is it?  Sorry.  I guess I'm saying that to make  
> > BoP a real obvious no-brainer, it really should do a better job of  
> > hiding the destination API from the application.  (which is hard for  
> > all of the human-source and silly banking stuff that I mentioned  
> > before, but I think it could be done better)
> 
> A better job in what way, specifically?  As I said, my application 
> doesn't have any idea about the destination API, and I've used it with 
> dozens of gateways.  If your specific usage isn't finding things 
> sufficiently abstracted by B:OP, it would be great if you could tell us 
> specifically what problem with that you're running into with that rather 
> than speak about it only general terms.
>

Third party payment systems would be nice to handle.  I think that's been
kicked around at least once before.  Also the name, firstname, lastname
thing is pretty annoying if you have to switch between two modules that
don't do the same thing.  Breaking down all the data one could reasonably
ask for into their smallest components would be nice...  Also it would be
nice if somebody thought a bit more about spoofing issues - though this is
more a problem of LWP and the things that rely on it.
 
> > [...]
> > 
> > But personally, I'd rather toss another major revision into the BoP  
> > stuff and really hide as much of the "which payment module are you  
> > using" in the modules, and less in the application.  It will require  
> > a major version change because the invocation methods would probably  
> > all change, etc and so forth.
> 
> A new major version and API change seem to be a common request, but I'm 
> having trouble understanding what we gain by this.  Why do the 
> invocation methods have to all change?  I would really prefer to support 
> new functionality in a backwards-compatible fashion.
>

I don't think being backwards compatible is that big a deal.  It would be nice
if there was a standard way to do refunds, but that's kinda more down to bank
suckness.

mock