Fwd: Re: [bop-devel] V2 and postback processors

[Charlie Piper]

Sorry, my reply bounced to the list I think.  Sorry if this is a dupe.

> Hi Ivan,
> 
> --- ivan <ivan at 420.am> wrote:
> > On Tue, Feb 22, 2005 at 03:10:37PM -0800, Charlie Piper wrote:
> > > Greetings all,
> > > 
> > > I've been browsing through the Business::OnlinePayment namespace over the
> > > past few days looking for a new solution for a cart that I am developing.
> > > One thing that I am noticing is that there isn't an example of a backend
> > > that processes via a postback from the payment processor.  Does anyone have
> > > any have any experience with postback processing or is it completely 
> > > taboo to do via Business::OnlinePayment?
> > 
> > By "postback" do you mean something like PayPal IPN, where the gateway
> > triggers notification of a completed transaction rather than responding
> > to a authorization/capture/whatever request?  I certainly wouldn't rule
> > it out, but so far none of the other B:OP:* modules work like that, and
> > it does seem like it would require a serious rethink of the way the
> > interface works...
> 
> I'm not too familiar with PayPals IPN but it doesn't sound exactly the same.
> 
> > Or by "postback" do you mean the user's browser is redirected to the
> > gateway site and then redirected back to your site?  That model is
> > probably not something Business::OnlinePayment is appropriate for, it is
> > more about "backoffice" transactions that don't necessarily involve 
> > an end-user browser...
> 
> Yes, more in this fashion but still not quite.  You have a form in your CGI that posts to the
> itransact processor.  If the form is set up correctly, the results are posted back to the
> location
> you defined.  My original thought was passing in a CGI object to the module to verify and
> collect
> the info returned from the processor.  It definitely doesn't fit the current model in that
> fashion.
> 
> My other idea was more in line with current modules but requires a helper script to capture info
> from the postback then return it as if it were a direct request from the processor.  But, that
> requires a helper script and still doesn't fit 100% into your current model.  Nor am I 100% sure
> of the security involved with this method
> 
> I think what I'll do is stick with option one and either use a different namespace
> (Business::iTRansact perhaps) or just not put it on CPAN.
> 
> > > I've been mainly working with iTransact[1] which uses postback[2] by
> > > default.  I've come up with a couple of possibilities but I want to get some
> > > feedback on the postback issue before I go too much farther.
> > > 
> > > I also looked into how interchange handles this (Vend::Payment::iTransact)
> > > and while it's an interesting solution there are pieces of the puzzle
> > > missing.  You either find out if the transaction succeeded or you get the
> > > errors back.  If the transaction succeeded, don't end up with any
> > > authorization details.
> > > 
> > > And finally, I do have some code for the iTransact XML[3] direct version.
> > 
> > This does look more like the way other B:OP modules work, in which a 
> > transaction is submitted to the gateway and the results are returned.
> 
> I'll put this together and submit it.  Is it safe to post a link to the code here for a review
> prior to uploading to CPAN?
> 
> > > Is there a problem converting this to a module compatible with
> > > Business::OnlinePayment series and uploading to the namespace after review?
> > 
> > Of course not!  Contributions are always welcome.
> > 
> > > [1] http://www.itransact.com/
> > > [2] http://www.itransact.com/support/connect_html.html
> > > [3] http://www.itransact.com/support/connect_xml_fe.html
> > 
> > -- 
> > _ivan
> 
> I appreciate your input on this.  I've definitely got a direction to move in now.
> 
> Thanks,
> Charlie
>