E-Commerce Help

[Javizy]

I'm making a little site that sells photo prints and uses PayPal as a payment gateway. The problem I have is with making orders reliable.

I was thinking of something like follows for the table structure:
[img src=\"http://homepage.ntlworld.com/thebomb/pics/erd.jpg\" border=\"0\" alt=\"IPB Image\" /]
The N:M would create a table OrderItem.

Here's the flow of the system:

[!--fonto:Courier New--][span style=\"font-family:Courier New\"][!--/fonto--]User adds items to basket
User clicks 'checkout'
PayPal processes payment
PayPal sends data via IPN to one of my scripts[!--fontc--][/span][!--/fontc--]

It's necessary to store order information before the IPN stage for verification and I can't think of a good way of doing this. The checkout button submits a form to PayPal with the order data, so where is there time to add to the Order table?

What I would prefer would be when the user clicks checkout they're forwarded to a script that makes an Order row with field 'has_paid' set to 'N' and then sends them to the PayPal page along with the post data, allowing the IPN script to set 'has_paid' to 'Y' if all is valid. However, this doesn't seem to be possible without using a form.

Any help/suggestions would be much appreciated.

[wickning1]

I don't think you can redirect to paypal with POST data. You could try an http redirect with GET data, if it isn't a lot of data.

Other than that, you'd just have to lengthen your checkout and make them click through one more page.

[Javizy]

[!--quoteo(post=360926:date=Apr 2 2006, 07:01 PM:name=wickning1)--][div class=\'quotetop\']QUOTE(wickning1 @ Apr 2 2006, 07:01 PM) [snapback]360926[/snapback][/div][div class=\'quotemain\'][!--quotec--]
I don't think you can redirect to paypal with POST data. You could try an http redirect with GET data, if it isn't a lot of data.

Other than that, you'd just have to lengthen your checkout and make them click through one more page.
[/quote]

Yeah I don't think there's a way around forms with PayPal, but it's possible to encrypt them so it should okay.

So after clicking Checkout, the user is taken to a page that adds the unpaid Order row and has a 'Continue with payment' option?

I don't like the idea of doing that because of users not continuing and me being left with a redundant row in the table, but it would work. I just wondered how other people do this, I don't want to be reinventing the wheel in areas that could lose people money if not done right :-s

[fenway]

You must be able to POST to PayPal -- that's the only reliable way to send encrypted data. This would be trivial in Perl (via LWP), but I have no idea how to do this in PHP.

[Javizy]

Apparently it's possible to simulate a POST form using cURL, but I don't think this will be an option as my web host doesn't support it :-\

With the updating 'has_paid' to 'Y' when IPN is verified, what if there is an error like 'too many connections' or something similar? The user will have transferred the money, but it won't be recorded in the Orders table. I really don't like putting anything down to chance when it comes to money.

[fenway]

Not much you can do about that -- same thing could happen if the PayPal script happens to abort before it run the callback script too! The only way to "handle" this would be to mark has_paid as "in process" so that you can at least identify these aborted situation (to distinguish it from "N").

[Javizy]

[!--quoteo(post=361161:date=Apr 3 2006, 10:30 AM:name=fenway)--][div class=\'quotetop\']QUOTE(fenway @ Apr 3 2006, 10:30 AM) [snapback]361161[/snapback][/div][div class=\'quotemain\'][!--quotec--]
Not much you can do about that -- same thing could happen if the PayPal script happens to abort before it run the callback script too! The only way to "handle" this would be to mark has_paid as "in process" so that you can at least identify these aborted situation (to distinguish it from "N").
[/quote]

What I mean is, if the database can't be accessed for some reason or another, the fact that IPN was sent won't be recorded, even if the order is completely verified.

I'm thinking of recording such things in an XML file, with a report to go along with it that has an option to change has_paid to Y for that order after verification.

[fenway]

All that I meant was that you can mark it as sent different than not sent -- it doesn't solve your problem, but at least you'll be able to locate the offending records later.