Jump to content
Sign in to follow this  
RAGE

NEW PAYPAL

Recommended Posts

The cart contents for all customers are stored in a DB table.

If that's the case, then I'd actually recommend passing an ID that corresponds to the contents through to PayPal. Then processing the IPN to match the payment to the cart contents and create the order.

 

Until, the PayPal payment is completed, it's probably best to treat the cart as "abandonable". Abandoning at PayPal is pretty similar to abandoning during osC checkout.


Patrick Breitenbach

Share this post


Link to post
Share on other sites
The cart contents for all customers are stored in a DB table.

If that's the case, then I'd actually recommend passing an ID that corresponds to the contents through to PayPal. Then processing the IPN to match the payment to the cart contents and create the order.

 

Until, the PayPal payment is completed, it's probably best to treat the cart as "abandonable". Abandoning at PayPal is pretty similar to abandoning during osC checkout.

This is actually how I usually do it and was surpised to learn that the current IPN's here work any other way..

 

Seems unnecessarily complicated to do it any other way, but I honestly haven't closely examined the payment processing files yet so I don't know if the complication is a matter of necessity.

Share this post


Link to post
Share on other sites
The cart contents for all customers are stored in a DB table.
If that's the case, then I'd actually recommend passing an ID that corresponds to the contents through to PayPal. Then processing the IPN to match the payment to the cart contents and create the order.
The problem is that each customer only has one cart. Using your method, they would not be able to order again until the IPN comes through. Also, one would have to change the current cart code to prevent changing the cart in the meantime (after sending for payment processing but before order confirmation from the processor -- PayPal in this case).

 

The way it works now, while in the cart, the order can be changed at any time. Once it is moved from the cart to the orders database, the order is fixed. Thus preventing someone for paying for one cart and getting another delivered (e.g. I pay for a DVD and then change my order to hold 20 video cards; order shows paid). There is a system to check for crack attempts that might catch this if the cart ID (which is just the customer ID) were submitted, but if there is a long (i.e. more than a few seconds) interval between payment submittal and the notification (approved/declined), then this might block *legitimate* attempts to start a new order. This is undesirable because it angers customers. Also, this could end up with the same problem as happens with the default PayPal module: payment could be approved but the order could be rejected, which causes payment to arrive without any indication for what it is meant (i.e. the order contents is lost).

 

Using the orders table solves this by creating a new order ID that only corresponds to this order. The change that may be made in the future (in the default osC) would be to create orders in a Payment Pending status *prior* to submittal to a gateway. This has nothing to do with saved carts, which are currently stored in the database for logged in users (and all customers log in prior to check out -- Purchase Without Account creates a dummy account for this purpose).

 

An alternate solution would be to create a third set of tables which would hold the static information of the order but not be considered final until the order is placed. This would be created during the checkout process and be eliminated when payment is made. The advantage of this is that the orders table would only hold actual orders then. The disadvantage would be that it is essentially wasteful as it would hold the same info as the orders table.

 

Cheers,

Matt


Always back up before making changes.

Share this post


Link to post
Share on other sites

That makes sense. Thanks for the explanation.

 

So for hosted payment methods (like PayPal, PayFlow Link, AuthNet SIM) there should be a temporary lock on the cart (for a few minutes) while a payment attempt is made. Then a time out or some customer action indicating they wish to continue shopping would unlock it.

 

It does sound like it can get tricky.


Patrick Breitenbach

Share this post


Link to post
Share on other sites

Ok, I might be missing something here, but my first question is how can you generate an order soley from the customers_shopping_basket and customers_shopping_basket_attributes db tables, it's current structure *only* stores the carts contents, namely products, and nothing about the payment type, shipping address or customer comments - as far as I can tell this information is retrieved from the session vars (see my last post)?

One issue I somewhat imagine is what happens when the customers cart has to be locked for an overly extended period, they'd be stuck, that is unless PayPal is guranteeing that the IPN is sent immediately and that you have a good webhost, in the above Patrick are you implying that this is within 10 seconds (maybe sooner if the redirect is forced to occur).

My point/question here is that if the IPN is not processed immediately something has to happen so that if the customer looks at their cart-box (etc) they are not being shown previous information. So if you tell them to come back later what do you do with their current cart and session information without causing any confusion and preventing them from another purchase?


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

The IPN comes in < 3 secs 99% of the time. I'd optimize for that.

 

The cart doesn't need to be shown on the page the shopper immediately returns to. It can just say "Thanks for your order". Maybe it provides a link to order status. Maybe it provides upsell.


Patrick Breitenbach

Share this post


Link to post
Share on other sites

Being an idiot in coding and all of this IPN stuff.. I'm rather confused and read the first three pages of this post and had to stop..

 

The new "Return" feature works great......

 

I just sent a test sale through and the customer NO LONGER HAS TO HIT THE FINAL CONTINUE BUTTON TO RETURN TO YOUR SITE.....

 

Worked like a charm......

 

Does this mean theres something I can do to stop all these damned uncofnfirmed orders! Tell me! I'm rather despeerate. I was going to configure some kind of popup reminding them of some sort with a GIF but Iunno, if it's easier let me know! This is extremely urgent!

Share this post


Link to post
Share on other sites

Olorin-

 

The way I am getting around the uncomfirmed orders is to rip out the process payment page completely. I am sending Paypal a new return page that basically only clears out the customers cart and tells them that their order is in processing. No DB tables are processed at this point. In others words the return page is very similar to the success page.

 

For processing the order I am relying on IPN 100 percent. I have a separate Perl script in my cgi-bin that takes the notification and then creates the order and deducts from my product inventory. I only process the "completed" IPN notifications. I made modifications to the paypal.php script to send the entire cart to PayPal with the product numbers so this can happen.

 

Even with PayPal's new autoreturn feature there are still ways for a customer to not return to the OSC site which would create incomplete orders. To me it looks like the OSC payment gateways are more setup for services that do not make a customer leave a website.

 

I am hoping to finalize my solution in the next month and will post my result when complete. Lately things have been crazy as my wife and I just had a baby girl.

 

Hope this clears up some of the confusion.

Edited by shughes

Shannon Hughes

Share this post


Link to post
Share on other sites

Wow, thanks! If you can remember, please email me when you've got it posted, this sounds like an excellent setup!

mhanson at v3leds dot com

 

Everything sounds like it'd work real clean and well, it'd be great for PayPal to recognise the orders as what they were so if it's confonfirmed by some strange thing, we'll still know what was ordered.

 

Thanks again, you're great!

 

M.Hanson

v3leds

Share this post


Link to post
Share on other sites

Mark Evans

osCommerce Monkey & Lead Guitarist for "Sparky + the Monkeys" (Album on sale in all good record shops)

 

---------------------------------------

Software is like sex: It's better when it's free. (Linus Torvalds)

Share this post


Link to post
Share on other sites

Whoah, Hold on horsey....

 

I've got to admit, linking in our existing CC payment was easier than trying to accept PayPal payments... We've had it enabled for one day, received our first notification of a Paypal ...you have cash... (substitute you most obnoxious sound for this), and found that we now have a transaction in the twilight zone (du-du-du-du-du-du-DU-du). I _stupidly_ assumed that the core paypal module would actually _allow_ me to view the order, fulfill it and track it... I was wrong (not the first, not the last, but getting fewer in-between)... Paypal has a transaction for a "personalized mementos" and shipping, no item detail, etc. (now, I did have some help setting up the account - ok, actually, I didn't set it up - but she's sharp as a frigg'n scalpal, so I know it's not like drawing stick figures.

So, cutting through all the *fun*, any robust paypal users out there who can friggin hold my hand while I get this working?

 

I'd love some help here,

 

thanks & Cheers,

 

mark


---

Mark Halloran

mhalloran@personalizedmementos.com

Quality Embroidery, Affordable Apparel & Screen Printing

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×