CiviCRM Community Forums (archive)

Hey Jason:

Thanx for stepping up and taking this on. Will be a great addition to CiviCRM. At the top level, i'd recomment you keep the "payment processor" interface as abstract as possible since we can reuse it for other payment processors too a a later stage. Some responses inline, you can chat with some of the developers on IRC at: http://embed.mibbit.com/?server=irc.freenode.net&channel=%23civicrm&forcePrompt=true

• 1.  Write recurring subscription functionality for Authorize.Net using ARB API

Does Auth have a recurring API? there is code to handle the recurring email sent by auth (we've eliminated it in 2.1 since this was community contributed but not supported) check: bin/ProcessAuthorizeReport.php in your distribution.

• 2.  Assume that subscriptions renew X days before end of current period.  The period is the same as set in the Membership Type (Day, Month, Year) (haven't figured out what X is going to be yet) Possibly add configuration for X later.

Yeah, during development we make X a constant and once we have it working, we make it a config variable or a property of the membership type etc

In the recurring billing model you have now, do you create an "unpaid" transaction and then update it's status to "paid"?

Only the first transaction is created and set to "pending". All subsequent transactions / records are created when we receive a notification. Note that in our current model, the payment processor "pings CiviCRM' with all the info needed to process a transaction

What do you guys do with failed transactions?  Are they entered into the transaction tables with "failed" statuses and a reason code?  Is there any notification code that sends an email to an admin when a failure occurs?

This is handled at the payment processor end. We just switch the status of those transactions to failed. No mail is sent (but i assume paypal sends out an email also to the admin about the failed transaction)

Is there functionality built into CiviCRM at this time to allow a member to cancel an existing recurring payment schedule?

No. We generate a link to the paypal page that deals with cancelling a recurring payment and send the user to that page

lobo

Hi, I am starting to work on recurring membership payments and I have a development question:

• I was taking a look at the Contribution and Payments APIs and I noticed the function CRM_Contributte_Form_Contribution::postProcess(), but I can't find a call to it anywhere in CiviCRM.  Is this function still used?

Thanks.

I can't wait for this to become available. We switched to Authorize.net because of the hassle of trying to do recurring payments with Paypal. It wasn't until afterwards that we realized that it doesn't work with Authorize.net either.

I'm hoping to put together a how-to for them to be able to do it for now until we can automate it.

Hi-

I am just about to start on a project involving recurring memberships, and was wondering about the status of this effort? Is the Authorize.net module a good starting point or is it still incomplete?

One bit of personal feedback regarding recurring membership processing: I feel it is pretty important to handle the payment exceptions in a graceful fashion - I am talking about:

 *declines
 *refunds
 *cancellations
 *expirations - only case handled currently by CiviCRM?
 *chargebacks

Especially with the downturn in the economy, you are bound to encounter cases where people change their mind or simply don't have the cash - the payment processing code needs to handle these cases.

One bit of personal feedback regarding recurring membership processing: I feel it is pretty important to handle the payment exceptions in a graceful fashion - I am talking about:

 *declines
 *refunds
 *cancellations
 *expirations - only case handled currently by CiviCRM?
 *chargebacks

Especially with the downturn in the economy, you are bound to encounter cases where people change their mind or simply don't have the cash - the payment processing code needs to handle these cases.

Would be great if you/your org steps up and handles these cases. Would help quite a few folks in the community. Alternatively if you dont have developer resources, consider hiring someone to do the needed work

lobo

Hi, I haven't updated this thread in a while, so I thought I would update it with my progress on PayPal automatic recurring membership billing...

So at the moment I am pretty close to having basic recurring billing in place for PayPal Website Payments Pro. 

Basically, the idea is that if a Membership is marked as "Auto-Renew", then when the user gets to the membership payment page, they don't see the recurring billing section - it is automatically filled for them on the server end once the recurring membership payment page is submitted. 

That creates a new PayPal recurring billing profile using the PayPal Direct HTTP API using the CreateRecurringPaymentsProfile function (dpesn't send the user over to a PayPal webpage - all processing is done by CiviCRM).  Then the PayPal IPN process kicks in and sends the recurring payment info to CiviCRM each time a new payment is sent where CiviCRM uses it's PayPal IPN code to update the payment info and the membership is renewed as usual.

I am still testing to see how error handling works out for the various payment errors.

Making these changes was not easy and required making modifications to the Membership configuration page, Contribution Configuration page, and modifying a bunch of the payment code that was tailored for PayPal Express recurring billing setup.

In making my changes I was pretty careful to re-use as much existing CiviCRM payment code as possible, so adding in recurring billing for Authorize.Net should not be too difficult once I am done.  The biggest part to getting Authorize.Net ARB to work I think would be implementing the CiviCRM IPN code to handle the ARB IPN requests - I don't think there is currently an Authorize.Net ARB IPN processor in CiviCRM.

If anyone would like to contribute some $$$ to the development and testing for the PayPal Pro recurring billing modifications I am currently working on - they would be greatly appreciated and would speed up my timeline.  Having some sponsors would also speed up my process of creating version 3.x patches for contribution back to the project.

Anyway, I will keep you all posted once I have my testing complete.

I am l trying to figure out what to do in CiviCRM when the Payment Processor IPN's telling CiviCRM that the Recurring Billing Subscription Profile was successfully created (but has not yet processed the first payment). 

Should I have the membership start off Pending when it is initially created and then have the IPN update it to New once the Recurring Billing Subscription is successfully created? 

If the Recurring Billing Profile is NOT successfully created, should I Cancel the Membership and mark the pending Contribution as Failed as if the first payment has failed?