I have a website where I want the form data to be submitted only if I know the customer has paid via the PayPal button. Right now I have it at the point where they can pay and I verify it (via IPN) and that's about it.
I'm looking for some ideas on the best way to approach this? I was thinking that when the IPN verifies I can insert a column into the DB saying "paid" and store some information in the session. You can then only access the form if that data is in the session. Once the form has been completed I can update the status from "paid" to "completed" and remove the session data. I would remove the session data because a customer can pay as many times as they like with different form data each time.
Any other ideas? Also, this isn't a site where you would log in.
To sum it up, I want the customer to pay first (and I know they paid) then fill out a form.
If you don't have any login mechanism, I would request an email aswell when paying, Store the email + paymentID (unique PK) in the DB, when payment comes back through IPN, email the customer with a secret passkey, you can only move forward with that passkey.
In my opinion sessions are a problem to use for paying user. what happens if that user's computer crashs right after he paid. He has no way to access his product. An email + secret passkey would enable him to
Related
I know that the recommended practice to use the custom variable of Paypal buttons is to pass an identifier which is a reference to some data in a database and then when Paypal returns a response, verified that id with its corresponding reference in the database in order to do extra processing,
But my question is, if I save data in the database when the user clicks on the Paypal button, the user gets redirect to the Paypal, how will I know that the transaction was never completed if the user clicks on the back button on his browser? Because if the user does that, I will get no response from Paypal (Completed or not). If I don't have any response from Paypal, then I just saved some data in my database for no reason.
How should I solve this issue?
I have a big form with a lot of fields, so I cannot send all that data in the custom variable since there is a limit.
Please help!
I would save them as "pending" status when they're unpaid. Then if the payment never completes you would have a record of the pending order and you could either follow up on those to try and convert them into an order or simply delete all pending orders to clean it up.
I am currently developing an E-Comm site that uses Paypals express check out system. The express checkout system works fine, I send the payments amount, the user logs in to confirm the shipping details, and returns back to my page where I confirm it and the payment is completed. The main issue I am having is that I have the username (email) saved in the session. Once the user clicks checkout with paypal and confirms his/her paypal account, my session is cleared. So I cannot keep a record of who purchased what item (unless I use the users paypals email address which could be different from the one the user used on my site).
So my question is, is there any way that I can preserve the session state throughout this confirmation action? Or is there another way to keep the users information? is this a documented problem (I have not seen it anywhere)?
If any more detail is required let me know.
Thanks for your time.
No, once the user leaves your domain the session will terminate.
Instead you can store the email address in a table before user leaves your site and pass the ID of the inserted record to paypal. As this ID is a custom field it will be returned in the call back url once the user completes the payment. You can get the ID from URL and retrieve the corresponding email from database.
Even if your PHP session didn't terminate (there is likely a different reason for it closing), it still isn't a good idea to depend on the session being unmodified between the time the user leaves for PayPal and returns. Consider a user with multiple tabs that starts poking around your website in another tab before finishing Express Checkout.
Instead, store everything that is important to your checkout completion in a database, and pass a unique identifier through the Express Checkout process via the CUSTOM or INVNUM parameters. Those will be juggled through the checkout process. Once the callback returns to your site, you can very easily identify which "incomplete" order in your database it is referring to and mark it "paid."
Am I correct in my understanding that I can only pass-through one custom variable from a form I create to PayPal using IPN?
I have my IPN script up and running with no issues. However, upon payment notification I need to store information input by the user from a form on my site into a MySQL database.
In this specific case its for a sports league registration form. The user fills out info regarding their team (i.e. Team name, League, ect..) then pays the league fee via PayPal. Upon verification I'd like to store their team name, the league they're signing up for and other info I need to collect in my database. But since I can only pass-through one custom variable from my form through the PayPal IPN process, I'm a bit stumped.
I've read other posts about storing the info immediately in the database, then marking it 'paid' upon verification. However, how could I accomplish this since when the user clicks Pay Now, the form action performed is the PayPal payment process (as opposed to an insert statement I create). Where would I perform a database INSERT with the posted form information?
Tips or advice would be appreciated!
However, how could I accomplish this since when the user clicks Pay Now, the form action performed is the PayPal payment process (as opposed to an insert statement I create). Where would I perform a database INSERT with the posted form information?
Perform the INSERT before sending the customer to PayPal. Before that, define a unique random key for the transaction. Put that key
into the database record that's being inserted and
pass it to PayPal's IPN.
Once notification comes back from PayPal, you can use the key to identify the record (with all the info already in it) and mark it paid.
One of the web applications I recently developed works like this:
User picks a subscription level
User enters various custom/personal data on the site as well as picking out certain options
User confirms their data
The system stores this data in an array with a flag set specifying that the data is incomplete
The user is directed to PayPal to pay
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 this 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.
I've implemented a paypal transaction before but this one has a twist that I'm not quite sure what's the best way to handle it.
The basic idea is I want to create an account for the user when he provides some details and makes a payment via PayPal. Until BOTH the user details are filled out correctly AND the payment is made correctly, I shouldn't create an account for the user.
The setup I've done before was simply a paypal button that the user clicks, makes a payment, and gets forwarded back to just a generic page "your order will be processed and shipped" so there was no pre-order form involved.
This one is different though because
before PayPal, I need to collect initial user data
after PayPal, I need to create the new user account and use in it the user data collected from the pre-paypal form
I'm sure there's a logical way to implement this, but I'm not quite sure what's the flow I should follow to do it.
I use the Zend framework by the way, which shouldn't matter but just in case Zend has an easier way to help me with what I'm trying to do.
I do the following (though I do this in ASP.NET):
User fills out form
Info is saved in Order table in db with a unique invoice number
Invoice number is passed to PayPal, along with the IPN Notify URL, when you do the redirect
User is sent to Paypal to pay and then comes back to a generic Success page
Behind the scenes, Paypal makes a call to the IPN Notify url once processing is complete. This page receives your invoice number which PP returns with its call, and then does the account creation processing for that order after retrieving the details from the db. [This is a page with no UI, since only PP is hitting it.]
An email is sent from that process which notifies the customer that their account has been created and gives them the details.
This is a simplified version of the process, but hits the highlights. You can check out PayPal's page about IPN, and do a search on google for IPN integration with PHP.