Add-on [PAID $$$] Need plugin to provide Paypal recurring sub continuity after migration to xF

trizz

trizz

Active member
Looking for a talented developer to build a plugin to help ease the pain of big boards looking to migrate to xF with recurring subscriptions via Paypal.

See http://xenforo.com/community/threads/import-of-vb3-8-x-paid-subscriptions.63774 for a bit more color.

Basically, need something that will receive data from paypal IPN posts and update xF so a users subscription stays in place and doesnt expire at the end of a month/paid cycle. It needs to mimic vBulletin 3.X whereas paypal posts data in monthly/etc to say the recurring payment has been successful and to continue honoring the subscription. The paypal data url(s) tied to the subscription cannot be modified so if we want to prevent the user from having to re-sub, we have to mimic what vB was doing.

Lots of info on this across the community, but whoever takes on this development project will be a hero to the community and enable lots of big boards with paid userbases an easy migration strategy to xF.

Ping me privately or via this thread to talk further.
 
Some info for the brave soul that decides to be the hero of the xF community, and all those looking to rapidly migrate away from vB 3.x (or 4, or 5).

You will need to understand Paypal IPN operations - https://developer.paypal.com/webapps/developer/docs/classic/ipn/integration-guide/IPNOperations/

The Paypal IPN notification URL defined inside the recurring subscriptions is found inside your PP account here - https://www.paypal.com/cgi-bin/customerprofileweb?cmd=_profile-ipn-notify . Updating this url works for all future recurring subscriptions, but does *not* alter the defined url in already recurring payments. This is where we as a community get hog-tied to vB.

My current vB IPN notification url looks like - http://www.my-forum-url.com/payment_gateway.php?method=paypal

IPN transaction history logs within a PP account can be found here - https://www.paypal.com/us/cgi-bin/webscr?cmd=_display-ipns-history

I have tons of successful IPN transaction messages I can share in private to show what data Paypal is pushing to and into vBulletin via the payment_gateway.php url as defined above.

Things I dont yet know and will open a ticket with xF on :
1.) Can I just rewrite all incoming requests to payment_gateway.php to the new xF IPN handler, and everything work magically with no issue as long as subscription data is imported during a migration to xF from vB??
1a.) If the rewrite would work, would Paypals IPN system actually honor it and send all expected data appropriately?
2.) Can I use an IPN re-broadcaster like - http://codeseekah.com/2012/02/11/how-to-setup-multiple-ipn-receivers-in-paypal/
3.) Can I use an IPN "forwarder" like what is mentioned here - https://www.paypal-community.com/t5...otifications-posting-to-wrong-URL/td-p/484140 (2nd post is from a Paypal employee with an IPN forwarder).
 
Hello, @trizz !

We have reviewed this request and considered to take it, but we see the solution should be quite simple and you can implement it easily. You should just have a file on your server named "payment_gateway.php", which should just include the XenForo file, so its entire content will look like
PHP: 
<?php
include 'payment_callback.php';

Edit: This considers your XenForo and vBulletin will be on the same domain and directory, otherwise a forwarder script like you have mentioned will be needed.

We didn't test this solution, but looking at the code this should work for sure.

If you need any further assistance you can contact us at https://desk.xencentral.com and we will try to help you.

Thank you!
 
Last edited:
I'm willing to contribute to the development if this includes forwarding of AWC subscriptions / donations. Lite version here. All AWC payments go trough the same IPN forwarder. The principle of forwarding the IPN to XF payments should be the same.
 
its possible that this isnt as simple as redirecting incoming IPN data from Paypal.

@Mike has responded to a ticket I opened with the following info :

Mike said:
Hi,

Unfortunately, there isn't a solution for this at this time. It's not just a matter of redirecting the request over. There is data that needs to be translated in the request to have what XenForo expects. A potential problem with this is that it may lead to a validation failure with PayPal which would prevent the request from being processed.

As it stands, this would require some sort of custom solution.

Regards,
Mike
Click to expand...

and when asked if he believes it would be more involved than just forwarding IPN data :

Mike said:
Hi,

Generally speaking, that isn't sufficient. At the least, there is no guarantee that the IDs are the same. But further, there is data in the IPN callback to identify the correct user and upgrade, and the format/expected value will certainly be different between XenForo and any other software.

I would imagine it is doable, but there is more involved than just forwarding the IPN data.

Regards,
Mike
Click to expand...

Sooooo.... Does anyone have an IPN transaction log from Paypal for an upgrade on a xF community they can share so that we can compare the differences to what was/IS being submitted to the PoS vBulletin platform?

I will pay a $100 BOUNTY for any admin currently running an xF board with recurring subscriptions that migrated from vB for the following (uncensored) data :
1.) successful IPN post/log from Paypal to your xF board to keep their current recurring subscription in force.
2.) the same data from Paypal for the same exact user that was posted to your vBulletin board.

I do not care if the user had to cancel and resub. I just need to compare IPN data that xF is pushing to and thru Paypal for user upgrades to what was originally being submitted to vB.
 
Last edited:
This solution sounds do-able
1.) Can I just rewrite all incoming requests to payment_gateway.php to the new xF IPN handler, and everything work magically with no issue as long as subscription data is imported during a migration to xF from vB??
1a.) If the rewrite would work, would Paypals IPN system actually honor it and send all expected data appropriately?
-> They send the same data. They don't care what software you are running as long as the URL is able to accept HTTP request from Paypal.
 
I had actually just read this thread and was contemplating what would be needed when @DaveM replied.

The IPN itself wouldn't be a challenge. It's the converting of the vB subscriptions to XF user upgrades and being certain all user IDs match in vB and XF that would be the bigger challenge. Then there's the security hash that needs to be dealt with. One misstep in the conversion and the IPN would fail.

Something like this would require quite a bit of time and testing with dumps of vB IPN replies to be sure it would work. Even then the real acid test is using it on a live site and you never know what you'll run into there.

The intricacies of the IPN are why my donation add-on isn't released here. I prefer to keep all support/bug reports in one place in the event of a problem.
 
Aayush said:
This solution sounds do-able
1.) Can I just rewrite all incoming requests to payment_gateway.php to the new xF IPN handler, and everything work magically with no issue as long as subscription data is imported during a migration to xF from vB??
1a.) If the rewrite would work, would Paypals IPN system actually honor it and send all expected data appropriately?
-> They send the same data. They don't care what software you are running as long as the URL is able to accept HTTP request from Paypal.
Click to expand...
A simple rewrite would not work. Every IPN from a vB subscription would fail the security hash test.

If a proper IPN handler were written and redirected by rewrite to the new handler, PayPal would honor it.

They do not send the exact same data. There would have to be a conversion in the handler to properly process the transactions.
 
Snog said:
A simple rewrite would not work. Every IPN from a vB subscription would fail the security hash test.

If a proper IPN handler were written and redirected by rewrite to the new handler, PayPal would honor it.

They do not send the exact same data. There would have to be a conversion in the handler to properly process the transactions.
Click to expand...

Paypal would honor it as long as the handler returned the right 200 response to prevent failure detection in the IPN routine and auto-cancellation of the subscription.

Regarding the security hash, can you elaborate? Here is a somewhat obfuscated IPN transaction log for a recurring sub on our site :

mc_gross=1.99&protection_eligibility=Eligible&address_status=confirmed&recur_times=4146313365&payer_id=E5YXXXXXXBN&address_street=XXXX ScXXXXXXe Lane&payment_date=02:28:49 Jun 12, 2014 PDT&payment_status=Completed&charset=windows-1252&address_zip=7XXX2&first_name=BXXXh&mc_fee=0.15&address_country_code=US&address_name=BXXXh EXXXXXs&notify_version=3.8&echeck_time_processed=07:00:10 Jun 17, 2014 PDT&subscr_id=S-6N888XXXXXXX6914&custom=bXXXh.eXXXXs&payer_status=verified&business=pXXX@gXXXXXXs.com&address_country=United States&address_city=Killeen&verify_sign=Aa7EqZtD-oUCr6IXXXXXXXuAqQ9S3lr8F46xp9IGVFdEbrO&payer_email=eXXXXX92@hotmail.com&txn_id=0RL6440XXXXX6238&payment_type=echeck&last_name=EXXXXXXXXs&address_state=TX&receiver_email=pXXX@gXXXXs.com&payment_fee=0.15&receiver_id=XKMQ8XXXXXCY&txn_type=subscr_payment&item_name=XXXXXXXSubscription&mc_currency=USD&item_number=10cdXXXXXXXXX7d760d96ec85ad09&residence_country=US&transaction_subject=XXXXXXSubscription&payment_gross=1.99&ipn_track_id=1c81XXXXX911d

Picking apart each field in that IPN transaction log, Im curious if the below 2 fields might cause a continuity problem :
verify_signEncrypted string used to validate the authenticity of the transaction
txn_idThe merchant's original transaction identification number for the payment from the buyer, against which the case was registered.

Can the appropriate hash(es) be exported from a vB install and pulled into xF?
 
You are correct, the trick is to get the new handler to return a valid 200 response.

Most of the fields returned by PayPal aren't used by either vB or XF. There are only a select few that are used.

If I recall correctly, the important item for vB is the item_number. That is an md5 hash that identifies which subscription the transaction is for.

For XF the important items are custom and subscr_id. Custom contains a 4 part array of which the security hash part is a sha1 hash. Subscr_id is used to check if the subscription has a previous record to be updated (there might be more, I'm working off of memory).

So far as importing the hash from vB, I THINK you might be able to get away with that and making a new IPN handler confirm the existence of that hash. The trick is going to be to get the hashes to correlate to an XF user upgrade and user id. It might be wise to import the entire vB subscriptionlog table and use/modify that to interface it to XF and let the new IPN handler use it instead of the XF system. Doing so provides you with all of the needed info except the XF user upgrade ID so modifying the table to have that info shouldn't be too bad. Then you just need to update the XF user_upgrade_active table when the payment is received.

Again, these are just ideas off the top of my head and not guaranteed to work.
 
what data gets ported over during a vB->xF migration regarding subs? Could I leave my old vb instance hanging around just to receive IPN notifications for "legacy" subscribers, and then somehow sync that data manually/automatically to xF once a day to keep subscription continuity?
 
That's part of the problem with the conversion. So far as I know, the subscriptions aren't imported over to user upgrades.

The member information containing the fact that they have an active upgrade is imported into XF's user_upgrade_active table, but I don't think the actual subscription information is imported. So, there's nothing to link the two together.

With that said, if you modify the vB handler to update the end_date in the XF user_upgrade_active table, I don't see any reason what you want to do won't work.
 
You must log in or register to reply here.

Similar threads

Reflect
Cancel button missing on PayPal (native) recurring subscriptions
Replies
1
Views
60
Mr Lucky
Mr Lucky
Back
Top Bottom