Need to write fee handler for Paypal Web Payments Standard

Comments

univate’s picture

StatusFileSize
new24.78 KB

Here is an attempt to get Paypal WPS working. I haven't tested on a real paypal account, rather I have written some simpletests to simulate the IPN messages from paypal. The IPN messages I'm using are from a real working site using paypal wps.

If you are able to test this, the IPN messages are logged to the watchdog, so if you can post these with any bug reports it should help when trying to fix issues.

univate’s picture

Status: Active » Needs review
univate’s picture

StatusFileSize
new23.13 KB

Re-rolled this patch for the current dev

I can't see a way to implement this gateway without doing one of:
1) creating an new module - even if we add hooks into the existing paypal module it needs another module to invoke those hooks on.
or
2) having additional hacks in uc_reucurring just for this module
or
3) including the code directly into the existing ubercart paypal module - I think this should be the eventual goal, but for the moment I think that the cleanest solution is just to have a separate module that lives within the uc_recurring project.

amitaibu’s picture

@univate,
won't it be enough to add in uc_paypal module just a module_invoke_all('uc_paypal_ipn', ...)? I don't think we have to implement the IPN listener, as uc_payapl does it already, we just want to act upon it's data.

univate’s picture

I haven't tested this, but the inc files are only loaded if the get recurring info function called. So will a hook in these files be found and called if the files not loaded?

drupalninja99’s picture

Pardon me for asking a perhaps dumb question, but I don't get how you would support payments standard bc I thought you had to checkout through paypals checkout, I don't get how you would be able to re-bill someone - is there documentation on this somewhere?

drupalninja99’s picture

I guess what this would be supporting is the existing paypal subscription which rebills from paypal and sends a message via IPN. I guess that makes sense. Lm_paypal I know uses this

univate’s picture

Recurring payments at its core is just charging X amount every Y interval which can be setup using paypals subsriptions as you stated. Its not the most ideal way to accept recurring payment, but it is a simple and cheap payment option to setup.

tobedeleted’s picture

I would be very keen to see support for Paypal WPS just as soon as possible. I've got an Ubercart based site for a customer that wants to offer complex subscription products, and this module is just what I need to make it all hang together and avoid clunky approaches to getting customers to set up recurring payments. Any thing I can do (given that I'm not a coder) to help it along, please let me know.

drupalninja99’s picture

I am having trouble patching the dev version of this module with the patch in #3. I guess you didn't really patch any existing files, these are all new files - that being the new paypal module? Eclipse created an A and B folder and so I just copied the new paypal module files to the main folder which I guess is the idea.

So the argument in #3 is that there are too many hooks we need to support the paypal recurring functionality? Anywho I will have a look. I am trying to find a place where I can contribute here so I will try testing out some of this code.

univate’s picture

I've integrated this paypal stuff into the new uc_recurring_hosted module which has been committed, so enable that new module and you can start testing this functionality.

As with all hosted gateways, testing that they setup the recurring payment is easy, but testing the renewal features takes time while you wait for them to process it and see what happens, so I'm not certain that is all working.

drupalninja99’s picture

interesting..moving into its own module i will check out

drupalninja99’s picture

1. one note, you've got some print_r()'s in there, that might have been intentional since this is a dev version, just fyi - sometimes i forget to remove debug info.

2. also I think the arb/paypal code needs to be split up into at least separate inc files, if not separate modules

3. i thought that the ipn url needed to be a static url, you have 'uc_recurring_hosted/paypal/ipn/%' like it's expecting an order id but the setup in paypal asks for one url, i thought they did a post to that url, not a get request - am i wrong?

i was able to successfully checkout against the paypal sandbox but i need to try to test out the ipn functionality. looking good so far. if i can figure out the ipn thing id like to test that out more against the sandbox. i suppose even sandbox instances will still send out ipn messages.

is this connected to the role assignment feature? i would think it would need to be - i wasn't sure if that has to be explicitly set up in your module or if that's somehow handled for you by another module.

thx, good work so far.

univate’s picture

1. one note, you've got some print_r()'s in there, that might have been intentional since this is a dev version, just fyi - sometimes i forget to remove debug info.

Removed.

2. also I think the arb/paypal code needs to be split up into at least separate inc files, if not separate modules

The reason for a seperate module is that these hosted gateways need to use various drupal/ubercart hooks, so that is why these gateways cannot just be done using the *.inc files that have been created for the other gateways (uc_authorizenet CIM, test_gateway etc...).

I would actually like to encourage the gateways specific code to go back into the actual gateway modules (i don't want to maintain code that I'm not using), so I am hoping that over time this module will get removed anyway or at least become a very small module that just calls the specific functions in the actual gateway.

I also consider these hosting gateways second class citizens compared to gateways that allow us to trigger the payments like Authorize.net CIM and this module is really just for putting in hacks that I don't want to see in uc_recurring (as I want to keep that module a clean API)

3. i thought that the ipn url needed to be a static url, you have 'uc_recurring_hosted/paypal/ipn/%' like it's expecting an order id but the setup in paypal asks for one url, i thought they did a post to that url, not a get request - am i wrong?

It is a static url for each recurring order, the url is created that includes the order id when the recurring order is setup and used by Paypal's IPN.

i was able to successfully checkout against the paypal sandbox but i need to try to test out the ipn functionality. looking good so far. if i can figure out the ipn thing id like to test that out more against the sandbox. i suppose even sandbox instances will still send out ipn messages.

If the order is marked as payment received or completed the you have already test part of the IPN, the other part to test is the renewals.

is this connected to the role assignment feature? i would think it would need to be - i wasn't sure if that has to be explicitly set up in your module or if that's somehow handled for you by another module.

uc_role handles role assignments which occur on a order status changing (depending on what is setup in CA)

drupalninja99’s picture

I am confused ab the IPN, you're saying paypal will pass an order id to the IPN? I wasn't aware of this. I need to set this site up on our testing server to test IPN..

drupalninja99’s picture

should i be testing dev?

i saw in beta that line 419 had a wrong url for the ipn

$data['notify_url'] = url('uc_recurring_hosted/ipn/'. $order->order_id, array('absolute' => TRUE));

in the menu hook we have:

$items['uc_recurring_hosted/paypal/ipn/%'] = array(

so when i tested the checkout the ipn hit failed bc it got a page not found.

UPDATE:

ok sorry i should have been testing dev, this has already been fixed

drupalninja99’s picture

did the dev changes get pushed to beta 3?

univate’s picture

Status: Needs review » Fixed

Closing this issue, any further issues with this gateway should be posted in a new issue.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.