Bug #50757 for Business-OnlinePayment-PayflowPro: Support for Recurring Billing

Thu Oct 22 13:24:02 2009 olaf [...] wundersolutions.com - Ticket created

Subject:

Support for Recurring Billing

Are there any plans to support Recurring Transactions? As it stands, I had to subclass the module to be able to create recurring transactions. It would be a matter of allowing some more fields in: my %params = $self->get_fields and the _map_fields method would need to handle the "action" a little differently. Olaf

Thu Oct 22 14:40:47 2009 PLOBBES [...] cpan.org - Correspondence added

Suggested patches are certainly welcome. Or if you prefer you could just send/attach your subclass/module and I see what we can work out.

Thu Oct 22 14:40:48 2009 The RT System itself - Status changed from 'new' to 'open'

Thu Oct 22 14:57:21 2009 olaf [...] wundersolutions.com - Correspondence added

On Thu Oct 22 14:40:47 2009, PLOBBES wrote: Show quoted text

> Suggested patches are certainly welcome. Or if you prefer you could > just send/attach your subclass/module and I see what we can work out.

Great! I'm just in the middle of this now, so I'll send you something early next week when I have more confidence that I've handled things correctly. Can I fork the source on GitHub or should I just send sample code/patch?

Thu Oct 22 15:03:25 2009 PLOBBES [...] cpan.org - Correspondence added

Show quoted text

> Can I fork the source on GitHub or should I just send sample code/patch?

Your call. This will probably be simple and small enough that I'd probably just attach a patch to this bug, but I'm not too picky.

Tue Oct 27 12:18:25 2009 olaf [...] wundersolutions.com - Correspondence added

On Thu Oct 22 15:03:25 2009, PLOBBES wrote: Show quoted text

> > Can I fork the source on GitHub or should I just send sample code/patch?

> > Your call. This will probably be simple and small enough that I'd > probably just attach a patch to this bug, but I'm not too picky. >

Here is my subclassed module. I've tried to document my changes. I'm not sure if it would be better to patch the current module or to subclass it and create a new module on CPAN. The issue with subclassing it is that the submit() method is fairly long and there are only a few things which need to be tweaked, so keeping up with future changes to submit() would be troublesome. If there were accessor/mutator methods for the fields, that would make it a lot easier. So, patching the current code is probably a better fit for now, but the info you submit for recurring transactions is different enough that it might warrant a new module to cut down on confusion. To deal with this, I've added the _is_recurring() method, which could be used to distinguish transaction types if they both occur in the same module. Let me know if you have any questions or need anything else from me. I've only tested this with adding new profiles so far, but I've added support for other kinds of recurring transactions based on what is available in the PayFlow docs. I expect to use some of those in production in future as well.

Message body is not shown because it is too large.

Tue Oct 27 12:35:38 2009 ivan-pause [...] 420.am - Correspondence added

Suggest reworking this to use the B:OP standard interface for recurring transactions. See the Business::OnlinePayment manpage and Business::OnlinePayment::AuthorizeNet for an example implementation. Otherwise, what's the point? CPAN already has a PayflowPro.pm for a non-standardized interface. :)

Tue Oct 27 12:40:45 2009 olaf [...] wundersolutions.com - Correspondence added

On Tue Oct 27 12:35:38 2009, IVAN wrote: Show quoted text

> Suggest reworking this to use the B:OP standard interface for recurring > transactions. See the Business::OnlinePayment manpage and > Business::OnlinePayment::AuthorizeNet for an example implementation. > > Otherwise, what's the point? CPAN already has a PayflowPro.pm for a > non-standardized interface. :)

I'll have another look. The AuthorizeNet example is more helpful. The recurring info on Business::OnlinePayment didn't really make me any wiser.

Tue Oct 27 13:58:03 2009 olaf [...] wundersolutions.com - Correspondence added

On Tue Oct 27 12:40:45 2009, OALDERS wrote: Show quoted text

> On Tue Oct 27 12:35:38 2009, IVAN wrote:

> > Suggest reworking this to use the B:OP standard interface for recurring > > transactions. See the Business::OnlinePayment manpage and > > Business::OnlinePayment::AuthorizeNet for an example implementation. > > > > Otherwise, what's the point? CPAN already has a PayflowPro.pm for a > > non-standardized interface. :)

>

I've had a closer look and I have some questions now. :) Looks like PayflowPro has some recurring types which are not listed in Business::OnlinePayment. I've tried to map all recurring actions here: # for recurring TRXTYPE can be one of: # my %trxtype = ( # add => 'A', # modify => 'M', # reactivate => 'R', # cancel => 'C', # inquiry => 'I', # payment => 'P', # ); # # recurring ACTION is always "R" my %recurring_actions = ( 'recurring authorization' => 'A', 'modify recurring authorization' => 'M', 'reactivate recurring authorization' => 'R', 'cancel recurring authorization' => 'C', 'inquire recurring authorization' => 'I', 'reattempt recurring authorization' => 'P', ); Any suggestions as for naming conventions? "inquire" doesn't make sense to read it in that way. Payflow's PAYPERIOD allows the following params: PAYPERIOD: (WEEK|BIWK|SMMO|FRWK|MONT|QTER|SMYR|YEAR) Any suggestion on how to do handle that?

Thu Nov 05 14:33:21 2009 ivan-pause [...] 420.am - Correspondence added

Subject:	Re: [rt.cpan.org #50757] Support for Recurring Billing
Date:	Thu, 5 Nov 2009 11:32:26 -0800
To:	Olaf Alders via RT <bug-Business-OnlinePayment-PayflowPro [...] rt.cpan.org>
From:	Ivan Kohler <ivan-pause [...] 420.am>

On Tue, Oct 27, 2009 at 01:58:04PM -0400, Olaf Alders via RT wrote: Show quoted text

> I've had a closer look and I have some questions now. :) > > Looks like PayflowPro has some recurring types which are not listed in > Business::OnlinePayment. I've tried to map all recurring actions here:

That's okay, we'll just extend the interface to the new operations and note that not all processors (that support recurring billing) support all operations. Show quoted text

> my %recurring_actions = ( > 'recurring authorization' => 'A', > 'modify recurring authorization' => 'M', > 'reactivate recurring authorization' => 'R', > 'cancel recurring authorization' => 'C', > 'inquire recurring authorization' => 'I', > 'reattempt recurring authorization' => 'P', > ); > > Any suggestions as for naming conventions? "inquire" doesn't make sense > to read it in that way.

info? Nothing in particular comes to mind. Show quoted text

It looks like the "interval" specification in B:OP is more flexible than what Payflow supports here. I'd say handle the cases you can ("7 days" => 'WEEK', "14 days" => 'BIWK', '1 month' => 'MONT', etc.) and throw an error for the cases you can't. In the base B:OP documentation, we should put a warning and list the common cases currently handled by all recurring-capable modules. -- _ivan

Tue Nov 17 11:53:27 2009 dsteinbrunner [...] pobox.com - Correspondence added

From:

dsteinbrunner [...] pobox.com

I emailed Olaf about his progress privately since I am looking to get PayflowPro recurring billing working for a project. He let me know that he has move to a different solution and hence put off working on this but did send me his latest code. So it appears I am picking up where Olaf left off. So far I have encounter the following note worth bits: The pay period SMMO that PayFlowPro defines does not appear to fit how intervals are currently defined. Here is what the docs say: SMMO: Twice Every Month - The 1st and 15th of the month. Results in 24 payments per year. SMMO can start on 1st to 15th of the month, second payment 15 days later or on the last day of the month. Any suggestions on how this should be invoked via the interface? PayFlowPro has what it calls a profile name. It is a non-unique identifying text name for use in searching for a profiles. Since a profile and subscription in B:OP match up I'm guessing subscription_name would be the proper interface name to use? Currently there is the idea of a trialamount with trialperiods which AuthorizeNet uses. PayFlowPro has the concept of a initial setup fee which I was thinking to put into trialamount but the more I think about it I'm not sure this is the right thing to do. First off, the proper interface name for this, to me, would be start_amount. Secondly, the association of trialamount, trialperiods and periods confuses the the simple version of this that PayFlowPro offers. At first, I was going to throw an error when trialperiods was set above one but then realized that the periods could be set to a month but the start date for them could be 2 weeks out so trialperiods even being set to 1 would not be valid. Thoughts? When the initial setup fee is used or the CC is checked for validity on when a profile is being created there are actually two transactions being done so the results have the CC results along with the profile/subscription results. I can see someone, possibly even me, wanting access not only to the subscription order_number but the CC order_number. Is this a case where extra methods outside of the standard interface would be advisable?