chrometweaks.org

What does the * on iPage prices mean?

Click Here To View All Answers...


First off, What does the * on iPage prices mean? Looking forward for any response. 2nd question I got is.. Been there done that..

The orders table was not very well designed. Show it to any BA in supply chain and s/he will look at you in a strange way. The problem lies in the combination of 3 business documents in the single table..

1) Sales order.

2) Delivery.

3) Billing.

Create the sales order upon redirection and billing upon successful return. Instead of trying do all three in the one hit..

Easy. Simple. Sorted...

Comments (26)

That's a good question. I'm not sure what is the right answer. I'll do some research and get back to you if I find an useful answer. You should email the people at iPage as they probably could assist you..

Comment #1

Its ok I found it.

What I have found out was the following..

The directive is very vague about what they mean on a sequential number, what it is interpreted at by a tax friend of mine is the invoice number cannot be random. It must follow a sequence. This does not mean it has to be.

100.

101.

102.

As long as the sequence is increased and is unique then it is acceptable so using date('U') would also be acceptable as it's an ever increasing number... dont you just love the EU.. talk about how to make a simple job complex..

Comment #2

All,.

I agree that the current order process is a bit flawed. It has mixed in order with payment transactions and shipping. All of which should be separate. But, without changing all payment modules, you have to live at least with the order processing the way it is..

That said, you can still support PayPal and other payment providers within the existing framework. I have modified PayPal Shopping Cart IPN 1.7 by Gregory Baboolal to do the following. It could of course be used for other payment providers in a similar fashion:.

1. Store the order *after* clicking Submit Order on checkout confirmation page resulting in:.

A. Order is stored prior to going to PayPal.

B. Order is stored in the main orders table as pending.

2. Redirect to an intermediate page that displays "Please wait while we transmit your information." On this page:.

A. All of the POST information to PayPal (or any payment provider) is stored in hidden fields..

B. The page automatically submits itself requiring no action by the consumer.

3. Upon completion of payment, the order is moved to whatever state you designate (e.g. Paid).

IMO, the benefits of this design are:.

1. When the user click Submit Order, they are saying they want to purchase this item (and not before). As a result, the order is then stored..

2. If the customer abandons payment for whatever reason, you then can follow up with the user via email or other channels to request payment another way..

3. If you store the order *prior* to Submit Order, then the customer really hasn't agreed to purchase anything...

Comment #3

That is a good temporary fix, in fact you don't even need to use IPN....

This is what I did, and checkout now works flawlessly (only tested with Paypal and check/money order though):.

In checkout_confirmation.php, the confirm button redirects to checkout_process.php (ONLY, no other button features here)..

I modified checkout_process.php to include the button that checkout_confirmation.php once had. I also added basic html tags, with a <body> onload function that automatically processes that button. So basically it's just a redirect page, and I added in some text "Processing...."..

Then I modified modules/payment/paypal.php to return to checkout_success.php instead of checkout_process.php just in case they do click that last continue button at paypal..

If anyone is interested, I'll post the full source code from my checkout_confirmation.php and checkout_process.php pages........ However this IS quite easy even if you barely know what you're doing.

The confirmation email is sent then, so you'll want to add some text like "your order will not ship until we receive payment" for those folks that may think they were charged anyway, even if they close the browser or officially cancel before paying...

Comment #4

On a related note, wouldn't it also be a good idea to split the payment data from the orders table?.

There is a lot of waste at the moment storing the credit card details in every order record. If the customer pays by another method these fields are not used..

How about creating a seperate payments table, which could hold all the information through some kind of look up table, or seperate tables for each payment method?.

Jon...

Comment #5

Quetzlcoatl.

Yes, Please...could you post the code you changed or pm me with it, if you don't want to post it?.

Thanks.

Teresa..

Comment #6

I used the redirect method on a live iPage site for awhile, and now we have reverted back to using Paypal IPN..

We began to have problems with customers attempting to fraud the store owner, because the confirmation email was sent before payment was actually made. I added text to the email instructing the customer that the email does not confirm payment, and that must be received before the item would be shipped. However, several customers insisted they paid when they actually did not, and several of them would repeatedly back up to checkout_confirmation.php and have the email sent multiple times, and insist they paid multiple times!!!!.

If anyone still wants the modified pages, pm me your email address and I'll send them to you. You could disable the confirmation email, but only if you use Paypal, and use the Paypal shopping cart contribution that allows you to pass the shopping cart contents to Paypal so what they ordered will be in the Paypal receipt. All of my merchants rely on the Oscommerce email though (we require printing fields on the email that cannot be passed to Paypal), so we have stopped using the redirect until I find a better solution...

Comment #7

Actually I re-wrote the checkout_process for PayPal payments, and upon re-reading Burt's initial post this is exactly what has been done. Just to explain a little this is how it has been implemented..

[1] The form action url in the PayPal payment module class was changed to POST directly to checkout_process.php.

[2] When checkout_process.php then calls the PayPal $payment->before_process() function it's own checkout_procss.php page is now included ( the remainder of the original one no longer has any purpose for PayPal payments)..

[3] The orginal checkout_process.php was seperated in two different concepts.

[A] checkout_process.php and [B] checkout_update.php.

[A] simply creates or rather populates the 'orders' tables except for the 'orders_products_dwonload' table, and the customer is then re-posted to the PayPal site, from which upon their return the customer arrives directly at checkout_success.php.

[B] Once the IPN for the PayPal payment has been received and if it's payment status is 'Completed' the 'products' tables are then updated and if it is a downloadable product then so too is the 'orders_products_download' table. And then the usual order notification emails are sent to the customer and storeowner..

There were 3 things required to accomodate this:.

[X] Create a new 'orders_session_info' table to.

Temporarily.

Contain that order's session info, namely:.

[i] orders_id.

[ii] sendto.

[iii] billto.

[iv] language.

[v] currency.

[vi] content-type.

[Y] Alter the 'orders_products_attributes' table to also contain..

[i] products_options_id.

[ii] products_options_values_id.

Thus the order information can be effectively reconstructed and by use of [Y] such that the 'products' tables updated, the 'orders_products_download' and the attributes information used in the email notifcations which all use the same original code logic found in the original osC checkout_process.php.

[Z] The 'orders_products_id' also had to be stored in the products array of that particular type of order class..

At this time the only consequence is that the storeowner should not delete a product from the store if that product is in an order that is still awaiting payment notification...

Comment #8

The main problem with the existing checkout procedure is that the order is placed on checkout_success.php (after the buyer has paid). With payment providers who take the buyer to their own iPage site to pay (eg W****pay, P**pal, 2ch***out) and so on this means that if the person buying does not click continue then the order is never placed (forget IPN for now)..

Existing procedure is (pretty much) like this:.

1/ Shopper elects to buy a product from your Store.

2/ Shopper creates an account (or logs in if prev cust).

3/ Shopper fills out shipping details + delivery method.

4/ Shopper chooses payment method (lets assume it's an offsite method as above).

5/ Shopper gets to confirmation page.

6/ Shopper nows go offsite to pay.

7/ If he clicks "continue" he will be directed back to checkout_success.php < here is where the order is input to the database with a value of "processing".

8/ Thank you page..

Which works OK in most circumstances..

However if it was changed to this:.

1/ Shopper elects to buy a product from your Store.

2/ Shopper creates an account (or logs in if prev cust).

3/ Shopper fills out shipping details + delivery method.

4/ Shopper chooses payment method (lets assume it's an offsite method as above).

5/ Shopper gets to confirmation page.

< here is where the order is input to the database.

With a status of "unpaid".

6/ Shop now has a full record of the order!!!.

7/ Shopper nows go offsite to pay.

8/ If he clicks "continue" he will be directed back to checkout_success.php where the order is now updated to "processing".

9/ Thank you page..

It's a large change but one that is worth doing..

Reasoning:.

A/ Shop has the order details even if the person drops out after leaving the site. meaning Shop Owner can contact the customer to ask if there were any problems..

B/ Shop Owner can easily update the order to a different status, eg "contacted, customer will send check as he didn't have a P**pal account".

C/ MOST USEFUL!!.

The Order Number can be passed to the payment processor!.

Downside:.

A/ A number of contributions may need to be recoded..

B/ The checkout procedure will need to be recoded.

If the Dev Team is willing to look at this as a serious proposal, I am prepared to talk about "sponsoring" Oscommerce to make these changes which will benefit nearly everybody in my opinion..

Appreciate any thoughts on this...

Comment #9

There is already a contribution that does this, although I'm not sure if it is compatible with the latest snapshot...

Comment #10

I am unaware of a contrib that changes the checkout procedure so radically - can you advise which one it is?.

IMO this needs to be a Core change - at the moment the checkout procedure is too prone to fail...particularly when using an outside processor...

Comment #11

I'm looking through the contribution section for it now, but am not having much luck. There is also a very lengthy thread in the tips and tricks section discussing the problem. It started out as a generic means to prevent los of order information when the customer doesn't click on continue at payPal..

It's actually a pretty straightforward change, and one I would think could be easily implemented into the core code. The biggest debat, IMO, remians whether to insert these recored into the orders table itself, or to have a 'staging' table, similar to the whos_online table that will periodically empty itself of old, uncompleted orders...

Comment #12

Good point. Hmmmn, I'd have thought it should go straingt into the orders table - else there would be no way to pass through the actual Order number to the Payment Processor (should you want to)..

I noticed a post from someone (I think it was yesterday) where they were moaning about the fact that it's difficult to reconcile Orders with Payments (it might have been ro do with Paypal). I can't remember, but it would also solve that sort of thing..

I can only see benefits to it being changed to be honest. What negatives there are are massively outweighed by the positives..

It's definately a goer, and if it could be looked at (seriously) by the Dev Team (with regards getting something into the Core) I think it would make Oscommerce into a better product than it is right now..

Thanks for your views though! Always appreciated. Anyone else got any thoughts on it at all? The more input we can have, the more detail the Core Team has to consider...

Comment #13

Hi Burt.

This is something I have been thinking about recently as the current system does fail once people are put in charge of pressing the last button.

The way you have described it is exactly what I was planning. What timescale are you looking at for this?.

PM me if you like..

Comment #14

It would be good to et over the problem of people not clicking continue (and other errors that result in orders being missed). Ideqally I would approach this through improved payment processing modules..

What I hate are order numbers that are created for orders that are never made. They screw up all the reports and cause headaches when trying to explain results to accountants and auditors etc..

What works best for me is the way implemented in the Paypay Shopping Cart IPN contribution. That way you don't get any pending orders - they are either completed or they don't appear in the order table at all..

I am happy to have them in a different table but I hate having to explain why my order sequence has gaps in it...

Comment #15

Can you keep this discussion public, I would be interested in this so as to implement in a contrib for MS2 2.2..

I had been discussing, such possiblities, even outside the forum, of which one point that did arise, was the in respect to 3rd party payments was how would one then be able to distinguish between whether the customer actually dropped out before clicking the osC confimration button or afterwards..

Also how you are intenteding on updating the order if the customer decides to edit or make changes to the order from the confirmation page, so far I have envisaged a session var to do this but this might then need to be a recognized by all payment modules...

Comment #16

Hi,.

This is definately something I would be willing to help with, a totally seemless checkout procedure would make Oscommerce the perfect cart solution - I've used many other solutions in the past and noticed this problem with them as well (even some that require license fees!).

I believe the contrib wizards referred to is here:.

Http://www.oscommerc...ntributions,871.

I'm pretty sure this one doesn't interfere when they decide to edit the order at checkout_confirmation.php...

Comment #17

How about storing the cart in the DB, passing a cart ID to the payment processor and creating the order upon payment..

I think a shopper cancelling out of the payment process is more like an abandoned cart than it is a pending order...

Comment #18

That contrib is fine as a stop-gap, but it can only be accessed via mysql. I have clients who do not want to learn another new skill- they just want tomake their crafts and process their orders.....

Comment #19

HI All.

I dont like the idea of using a staging table.. it causes duplication of effort and is un-necessary. I think the order should be entered into the orders table itself..

I also think that we should stop using the auto increment field to create the order id and create an order number based on time and date (or something similar) that can then be passed to the 3rd party providers to the orders can tally up...

Comment #20

Agree about the staging table..

I'm unsure though about stopping using the auto_incremented order_id - thogh I can see good reasons to use some sort of number based on date and time..

Perhaps.

Date("U");.

Would work well ? All it would need is a UNIQUE field on the table column to make sure of not getting two order_id the same (ie 2 orders placed at almost the same time)..

Whatever is decided is fine. The main point (i think) is to get the order written to teh DB before the buyer leaves the Shop to go off to Pat - once the buyer returns from the processor, the order is then updated as appropriate..

I'd like to see this done ASAP - with this in mind I have some money available to support it's development - obviously I prefer to keep money stuff private so I will contact Sparky and go from there...

Comment #21

Out of curiosity, I copied and pasted the entire contents of checkout_process.php (minus the file requires) into checkout_confirmation.php right after body_eof. Definately not a fix but a good starting point, and NO staging tables..

Here is what happened (when I clicked the button on checkout_confirmation to transfer to Paypal):.

Order posted once into the database tables.

Order posted twice in admin, and both were highlighted blue.. I could also delete both at the same time (deletes the one entry in the db).

Two order confirmation emails were sent, and instead of seeing the normal email text, it was replaced with EMAIL_SEPARATOR, EMAIL_TEXT_ORDER_NUMBER and such.

I'm working on these glitches, just thought I'd go ahead and post if anyone else want to try it out..

What are the disadvantages to having duplicate order ids? On some stores with very large sales volume, it is possible to have multiple orders at the same second, could we pass over bits and pieces into one field, such as first initial, last name, and time? (sorry if that seems like an elementary question, my php/oscommerce experience = approx. 4 months or less)..

Comment #22

I really don't think that order_id should be used as a sequence number anyways. Perhaps an additional field can be added, sequence_num, that remains null until the order is successfully completed, and then is assigned a sequential number...

Comment #23

That's a cunning idea Chris! For VAT of course it is a legal requirement to have a sequential id..

This post has been edited by.

Radders.

: 11 March 2004, 20:00..

Comment #24

Hello to all.

Very interesting coz I think I found an easy solution for every one.

Im going to test it but ithink it can be ok....

Its very easy to do.

1 at the checkout_payment.php you have to use the os commerce credit card module the one who save half of the number in the database and send the rest .. or add a checkbox for credit card with a few img of credit card.

2 in the checkout_confirmation.php nothing to do or may be keep in the sessions that credit card is been checked and add just a simple message.

After the customer confirm the order and goes to checkout_confirmation.php.

Thats where I had my script given by the bank not exactly I means by ovh coz igo thru.

Ovh.

Http://www.ovh.com.

But now the customers has confirm the orders he can now choose with wich card he's going to pay.

At least you have the orders.

I dont speak good english so.

See u.

Thejokers..

Comment #25

I show you live soon I have a few in order for some customers....

But basicaly you can make the payment procedure after that the customer confirm the order and thats it that means that in no case you got the payment.

Without the order and the customer is not very disturb I think by the fact that he has to confirm the order and then go thru the payment procedure so every one is happy.

Thejokers..

Comment #26

Sorry I ought you was askingme to explain.

Thejokers..

Comment #27


This question was taken from a support group/message board and re-posted here so others can learn from it.