Post by JNeuhoff » Fri Nov 14, 2008 1:06 am

- Put the order into the order table in a pending/unconfirmed state
- then continue on to paypal or any other off-site gateway
- then depending on the gateway, whatever the final step is to tell the store to update the order can be triggered to change pending/unconfirmed to processing/accepted
I think PayPal workflow should be similar to that of Google checkout:

1)The checkout_confirm transfers control to the PaymentPayPal.process function
2)The PaymentPayPal.process function retrieves the order details
  and stores them in local variables
3)It then sets the order_status to'Paid Unconfirmed'
4)It clears the shopping cart, the order is stored into the database
5)Then it submits the local variables with the order details via POST or GET and transfers to the PayPal payment gateway.
   This step must include the notify_url variable to let PayPal know the callback function
6)PayPal calls back the PaymentPayPal.callback
7)This callback function sends a _notify-validate to PayPal and gets a 'VERIFIED' else assume non-verified
8)If 'VERIFIED' set the order status to 'pending'

Steps 6. to 8. are optional, we don't have to rely on PayPal to call back. The store owner always can log into his PayPal account to see for himself whether payment has been made or not before processing an order via OpenCart's admin panel.

I might add I haven't studied PayPal's API yet, but I believe above mentioned steps should work and make the system more robust.
Last edited by JNeuhoff on Fri Nov 14, 2008 1:26 am, edited 1 time in total.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by Qphoria » Fri Nov 14, 2008 1:14 am

JNeuhoff wrote: 1)The checkout_confirm transfers control to the PaymentPayPal.process function
I think this is the key. Instead of setting the confirm button to be the form action that goes directly to paypal, it needs to be handled internally first. This is actually the plan for 0.8 for the checkout confirm button for all payment modules to either POST back to checkout_confirm page or to some other internal handler like payment.process. This means all the 0.7.x contribbed payment modules will need to be updated, but that was expected anyway since its a new version number. But it gives opencart some additional security and validation for checking that the confirm button was actually pressed.
Last edited by Qphoria on Fri Nov 14, 2008 1:16 am, edited 1 time in total.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by JNeuhoff » Fri Nov 14, 2008 1:22 am

Agreed. If I have time, (not before next week) I might give it a try with the creation of a more robust payment module for PayPal. As I said, IMHO it should work similar to how the Google payment module does it for GoogleCheckout.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by Qphoria » Fri Nov 14, 2008 2:14 am

Looking at your google module, (without actually installing it) how are you forcing it to go to another page? I see "fields()" function returns empty. I would think you'd need to return the path of the process function.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by JNeuhoff » Fri Nov 14, 2008 2:34 am

The customer is transfered to Google's payment page from the process function:

Code: Select all

			// Have OpenCart process the order and remove its cart from the session.
			// OpenCart will store it in the database with a 'Paid Unconfirmed' order status.
			$this->order->process($results['order_status_id']);
			$this->cart->clear();

			// This will do a server-to-server Google cart post and send an HTTP 302 redirect status
			// More info http://code.google.com/apis/checkout/developer/index.html#alternate_technique
			list($status, $error) = $cart->CheckoutServer2Server();
Note that $cart is an instance of GoogleCart class, provided by Google's PHP libraries. This object has the order details, which are extracted directly from OpenCart's $this->order in the same process function. That's why there is no need to have the fields() function create the elements for the HTTP GET form.

The path, or rather the URL, for the check_confirm action is taken from here:

Code: Select all

	function getActionUrl() {
		return $this->url->ssl('checkout_process');
	}
Also, Google knows about the URL of the callback function, because that information is configured in the Google Checkout seller accout itself (Settings > Integration > Callback URL).
Last edited by JNeuhoff on Fri Nov 14, 2008 2:38 am, edited 1 time in total.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by Qphoria » Fri Nov 14, 2008 3:12 am

oh because google doesn't use the confirm button on the checkout_confirm page so it is doin its own thing

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by JNeuhoff » Fri Nov 14, 2008 5:49 am

The checkout_confirm does use a 'Continue' button which is only available when the checkbox for 'I agree to Terms & Conditions' has been set. It then submits a form with, unlike PayPal, no fields from hidden elements, because there none specified in the PaymentGoogle.fields() function. The action URL for this form submission refers to PaymentGoogle.process() which does the magic as described in my previous posts.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by Qphoria » Fri Nov 14, 2008 6:46 am

ah yea I totally forgot about the action address

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by SoCal » Fri Nov 14, 2008 7:15 am

Q,

your losing me guys    ???  .... is this dialogue about PayPal IPN ,  addessing the same issues I'm having as posted on the other topic  forums/modual/paypal_shopping cart feature plugin

that is ...

I've yet to put in Q's code to fix my error message on  checkout_process    (which when hit gives me an error)
and as also mentioned,  nothing through paypal shows up on my sales/orders  in opencart

New member

Posts

Joined
Fri Nov 07, 2008 3:23 pm

Post by Qphoria » Fri Nov 14, 2008 10:44 am

that issue with the order status is in the other thread. this thread is discussing a better way for the paypal module to work a bit similar to the way the google checkout works.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by codecreator » Fri Nov 14, 2008 6:57 pm

Since this appears to be a long-standing issue with Opencart, I am curious how others are working around this problem. What are you doing to mitigate the potential administrative headache for shop owners? ???

New member

Posts

Joined
Mon Aug 04, 2008 6:39 pm

Post by codecreator » Mon Nov 17, 2008 11:41 pm

Hello,

I feel like I am whistling into the wind. Is anyone else having issues with Paypal payments not being recorded unless the user clicks the "Return To Merchant" button? (OpenCart 0.79 RC3)  If so,  how are you working around this issue? 

Any thoughts, helpful suggestions, etc.  are greatly appreciated.

Thanks in advance.

New member

Posts

Joined
Mon Aug 04, 2008 6:39 pm

Post by Qphoria » Mon Nov 17, 2008 11:59 pm

you can always follow the development by looking at the open issues on the bug tracker located at the sticky topic at the top of the 0.x development forum

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by codecreator » Tue Nov 18, 2008 3:05 am

Are you suggesting that something is there that addresses this issue?  If so, can you provide a reference since I seem to be missing it.

Thanks.

New member

Posts

Joined
Mon Aug 04, 2008 6:39 pm

Post by Qphoria » Tue Nov 18, 2008 3:47 am

http://code.google.com/p/open-cart/issues/detail?id=109

There are a few issues here, all colliding into one.

1) The way that a lot of payment modules are designed, as well as the core paypal module, is simply poor. It leaves lots of potential for security holes and lost orders

2) The fix for the security holes is along the same lines as the fix for the prevention of lost orders.

Instead of using the checkout_confirm page to launch the form directly to paypal, we are going to change it to transfer control back to the checkout_process page with a new function that does some security validation to ensure that the confirmation button was clicked, and that the user didn't just manually enter the checkout_process page in the address bar to fool the system.

In doing this, we will then have the paypal->process() function handle pre-processing of the order, any additional validation, and finally send the customer to the offsite payment area. At this point, the order will have already been processed and set to a "Paid Unconfirmed" state. When the IPN callback then gets called after payment is made, it will run the callback and if the payment was successful, it will update the order status to "Processing".

This should then :
- Allow opencart to validate the checkout process before going to the payment site
- Prevent losing an order
- Perform proper validation on an order and its payment status
- Send the form behinds the scenes (which also adds security as the form cannot be tampered with at the client level.
- Remove the need for the user to click "Return to Merchant" to update the order state (IIRC)
- Work much more properly overall!

Other modules that use the "direct form" method should really be upgraded to do it this way too to be more secure.
Last edited by Qphoria on Tue Nov 18, 2008 3:53 am, edited 1 time in total.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by codecreator » Tue Nov 18, 2008 1:26 pm

Qphoria,

Thank you for your very thorough and clear explanation!  It was informative and game me hope that this issue will be resolved soon. 

I will keep an eye out for the fix.

Thanks again.

New member

Posts

Joined
Mon Aug 04, 2008 6:39 pm

Post by JNeuhoff » Tue Nov 18, 2008 5:22 pm

Other modules that use the "direct form" method should really be upgraded to do it this way too to be more secure.
The GoogleCheckout payment module already does it behind the scenes, the PayPal could be easily changed to use a similar more robust workflow.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by Qphoria » Tue Nov 18, 2008 7:38 pm

zat be da plan  :D

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Qphoria » Thu Nov 20, 2008 6:37 am

OK, I have a fix. We are looking to put it into RC4 but I also don't want to hold up RC4 so I'd like a few volunteers to PM me if they'd like to test it out.

Whats new?
Checkout_confirm now sends to checkout_process. There is a new validation function there that does a security check to ensure that you submitted the checkout_confirm form with the submit button, and checks that the post value from the form matches with the session version. This prevents hackers from loading the checkout_process page directly from the address bar and circumventing the payment part.

After that, the paypal->process() function is called. In this function, the order is processed into the order table with a state of "Paid Unconfirmed". This then redirects to a new landing page called checkout_pending. If there were any errors at this point, it would be displayed here. This is also where the form fields are set and sent to paypal.

To prevent making it an extra step, I've used javascript to auto-submit the form for them. If javascript is turned off, they will see a page explaining that they need to click the button to continue.

Once they pay, if IPN is enabled, it should hit the callback function and update the order to "Pending". At this point, they can stop. They won't need to click Return to Merchant.
If IPN is not setup correctly, then if the customer hits Return to Merchant, it will update the order status to "Pending". If they do not click Return to Merchant, then the order will stay in Paid Unconfirmed state and the store admin will need to follow up and check if they received money.

Did we reach our goals?
- Allow opencart to validate the checkout process before going to the payment site - YES
- Prevent losing an order - YES
- Perform proper validation on an order and its payment status - YES
- Send the form behinds the scenes (which also adds security as the form cannot be tampered with at the client level. - YES
- Remove the need for the user to click "Return to Merchant" to update the order state (IIRC) - YES (In most cases)
- Work much more properly overall! - YES

PM me if you'd like to test it.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Qphoria » Thu Nov 20, 2008 8:27 am

Im also thinking maybe I don't need the checkout_pending page, and I could just POST back to the confirm page and handle it all there. I will work on this now, but it will still work the same functionally.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am
Who is online

Users browsing this forum: No registered users and 6 guests