Data integrity when data is stored on our site and the user is taken to PayPal and back?

One of the web applications I recently developed works like this:

1. User picks a subscription level
2. User enters various custom/personal data on the site as well as picking out certain options
3. User confirms their data
4. The system stores this data in an array with a flag set specifying that the data is incomplete
5. The user is directed to PayPal to pay
6. PayPal makes an IPN request and we grab the row ID containing their information and complete the rest of the fields, effectively completing the process.

Now, obviously there are a few problems with this approach.

1. These rows are created whenever a user visits the form and can quickly add up

I solved t开发者_如何学Gohis issue by adding a last_touched column which is a timestamp, and I routinely delete records older than 48 hours (more than enough time to complete a PayPal transaction).

2. Because of the above, it's possible that a user could checkout successfully with PayPal and there is no row in the database

I transmit the essential information such as the ID of the subscription package with the PayPal custom field, and if the row doesn't exist when I'm doing my IPN request, I fill in the blanks using the data supplied to PayPal and from the custom field.

3. The username the user entered could theoretically be taken by the time they checkout

I've solved this by checking to see if the username is taken and if it is, I add a number to it and keep incrementing the number until I get an available username.

I'm not sure if this is the best way to handle the given situations or if there is a better alternative (Not involving PayPal Payments Pro). At which point would the potential issues with a system like this outweigh the cost of PayPal Payments Pro?

Your best bet is to store all account information on your database as if the user created the account before sending them to PayPal.

So store everything including the username before allowing them to proceed to the checkout. This enables you to validate their information and username before they go to PayPal. Then you cache it all for 48 hours just to make sure they don't lose the username while checking out. You could also take advantage of PHP's session support to track the user if they happen to come back the next day to make the purchase. As long as they didn't clear their cookies/cache and your session lifetime hasn't expired the session server-side, they should be able to resume the session right where they left off and go straight to PayPal.

I would still send all vital data to PayPal just in case the user somehow manages to sit on PayPal's payment page for a week and then decides to put in CC info.

You could also use this system to "check" if the user has already started paying. Perhaps ask them to enter an email address first. Associate all data to that email and the user's IP address ($_SERVER['REMOTE_ADDR']). If you don't have session concurrency for a user, but they enter an email address already in the database. Check their IP (and maybe even browser too if you want to be really anal about it) and if it's a match, tell the user "looks like you started checking out before and never finished. want to continue?" and let them pick up where they left off. Obviously don't store any sensitive information this way, and only cache it in the temp table for paypal stuff so it only lasts for 2 days at best.

This way the user can click "Yes" and they don't have to choose their subscription again and go through all that picking/deciding a second time. If the user says "No, I'd like to start over" then just delete the row in the temp table and make a new one for them.