Paypal Subscription problem.

[novacreative]

I'm trying to use the Paypal form plugin for recurring subscriptions.

What goes right:

1) The form goes to Paypal.

2) The price, duration and period variables are all set correctly and show up on the Paypal page (e.g. $14.99 for 3 months)

3) The page returns as set in the plugin.

What doesn't go right:

1) The Paypal success email arrives but multiple times. It shows the TXN-id in one email, but it's blank in the others.

2) The IPN returns multiple times for a single transaction as well. It returns "none" or blank or the actual TXN-id and result. The blank return overwrites the correct TXN-id.

When I turn off the subscription option in the plugin, the IPN works fine.

I left the invoice number option in the plugin blank.

I'm using Joomla 3.3.6, Fabrik 3.3.2 with an August update to GitHub. All the above results are with our Paypal Sandbox account.

 

[cheesegrits]

Not much we can do about support for the PayPal plugin in Community, there's just too many moving parts.

Have you checked the #_fabrik_log for clues?

I recently added a lot more logging to the plugin, especially in the IPN handling, so if you haven't updated in the last month or so, do a github update and see if that helps with leaving more clues in the log table.

-- hugh

 

[novacreative]

I've updated to the latest github and checked the logs.

Here's what is happening:

With subscription "turned off," the log is recording that the plugin is sending the "custom" value (not the Fabrik Paypal custom element value) as the record id. The Paypal response is listing the "custom" value as that same id and is updating the record with the TXN and status. All is well.

With subscription "turned on," the plugin is still sending the "custom" value as the record id. However, the Paypal response has a different "custom" value and the appropriate record is therefore not being updated. I cannot find where the value comes from that Paypal is returning as the "custom" value. It is not found in what the plugin is sending to Paypal.

Does that help highlight where the problem with this plugin comes from?

 

[cheesegrits]

I've confirmed this with a local test.

I can work on this, but I'd really appreciate it if you could take out a paid subscription, to help support the development work. As I said in my first response, it's not an easy plugin to work on.

-- hugh

 

[cheesegrits]

OK, I see the issue. Seems that PayPal's IPN no longer supplies the txn_id of the original transaction with a followup subscription event. So we're getting (for example) a "txn_type=subscr_signup" after the initial "payment_status=complete" which doesn't have the tx_id. It relies on the subscr_id it sends back with the payment completion.

I'll have to do some re-factoring of the IPN logic for this, which will take a few days, as I have to test any changes to the PayPal plugin to death before committing them into the wild.

-- hugh

 

[cheesegrits]

BTW, I couldn't replicate what you were seeing with the custom arg. I get the correct formid:rowid. I'm hoping that was some kind of non-issue.

I've gotten it working at my end. What I've done is added an "IPN Subcription ID Element", which is "strongly advised" if you are using subscription mode. On the subscr_payment, where we do get the txn_id ...

https://www.paypal.com/us/cgi-bin/webscr?cmd=p/acc/ipn-subscriptions-outside

... the main plugin will update the table as usual, including writing out the subscr_id.

For all other subscr_ transactions type (subscr_cancel, subscr_eot, etc), where we don't get the txn_id, no automatic updating will be done. All we will do is call any custom IPN handler for that transaction type, and it's up to you to do whatever you want to do, using the subscr_id to identify the row you need.

Let me know when you have some time to test the changes, and I'll commit them. I don't want to commit them until you can immediately test.

-- hugh

 

[novacreative]

I'm ready to test it now. Let me know what I should do.

Since then, the basic IPN function is working on my Test Site 1. There are still two responses, so the changes you're making seem to be needed, but it is finding the rowid. I changed nothing except turned it off "Subscription" and set "1" to "0", then turned it back on.

I moved on to test it on a different test site, and this one has a different issue. The response comes back "form.paypal.ipnfailure.custom_error" with detail "formid or rowid empty in custom:"

Now the formid and rowid are reported in the plugin's request:

{"opt":{"cmd":"_xclick-subscriptions","business":"XXXXXXXXX","shipping":"","item_name":"XXXXXXXXXXXX","p3":"6","t3":"M","a3":"149.99","no_note":1,"custom":"1:70:"

1:70 are the correct values.

So the messages sent by the plugin on the two test sites (both same J versions and latest F Github) are indistinguishable from the beginning through the return_url and }. But I get the error message on Site 2.

BTW, I have paid a supporter payment today.

 

[cheesegrits]

I've committed the changes. They are in both github, and the latest 3.4.1 ZIP, so update whichever way suits you.

-- hugh

 

[cheesegrits]

PS, thanks for the sub, I've moved this thread to the Standard forum.

-- hugh

 

[novacreative]

Downloaded today's github and uploaded the Paypal plugin.

Same result. Here's the outgoing (without the data) and incoming:

{"opt":{"cmd":"_xclick-subscriptions","business":"XXXXXXXXX","shipping":"","item_name":"XXXXXXXXXXXXXXX","p3":"3","t3":"M","a3":"99.99","no_note":1,"custom":"1:73:","invoice":"568d2096ae8db7.12806895","src":"1","currency_code":"USD","notify_url":"http%3A%2F%2FXXXXXXXXXXXXX.com%2Findex.php%3Foption%3Dcom_fabrik%26c%3Dplugin%26task%3Dplugin.pluginAjax%26formid%3D1%26g%3Dform%26plugin%3Dpaypal%26method%3Dipn%26renderOrder%3D0","return":"http%3A%2F%2FXXXXXXXXXXXXX.com%2Flanding-page"},"data":

//////////////

//////////////
cmd=_notify-validate
//////////////
formid or rowid empty in custom:
IPN custom function =
IPN custom transaction function =

Note that the value for "custom" is correct: formid = 1 and rowid=73.

 

[cheesegrits]

So that's with subscription enabled?

Sent from my HTC One using Tapatalk

 

[novacreative]

OK. Maybe this is what's going on.

Yes, it was with subscription enabled.

I cloned this site and moved it back to my test server (I've been working on the client's new server.) Back on my test server, all is well; at least the IPN is updating with the TXN-id and status.

One perhaps significant difference between my test server and the client's server is PHP version. Mine: 5.4.45. Client's: 5.5.30.

Could that be it?

 

[novacreative]

That was it, at least part of it. I backed the PHP version down to 5.4.45 and all is well, at least the IPN is updating the TXN # and status.

Thanks for your help. Hope that info was helpful to you as well.

 

[cheesegrits]

Hmmm, I'm running on 5.5.27, which works fine. Which makes this a battle of diminishing returns, which for now, I'm not going to fight. If you can get it working as expected with "not 5.5.30", we'll chalk it up as a win and move on.

The latest code should fix the systemic issue, of overwriting the IPN txn_id when the additional subscr_foo events are processed, and providing the "IPN Subscription ID Element" option, so custom IPN handlers can deal with those events.

-- hugh