I have a custom built shopping cart that is double charging clients credit card when they click the back button. My thought is to make them shopping cart empty when they click the back button. Any ideas will be highly appreciated.
There are multiple ways to solve this problem:
Your form passes a unique GUID as a hidden form field on the submission page. Then your app stores this GUID in the session object on the server. Before you process the payment, you can check to see if this value is already stored in the session.
Your application is not responsible for processing orders... only storing order info in a database. Another application daemon on the server looks for orders waiting to be processed on the server and processes them offline. Advantage here is you won't have HTTP timeout problems, as well as avoiding the refresh problem.
Post/Redirect/Get
Related
OK. I have my connection to my database allowing content to be posted to my website from users.
I'm missing a key function that will allow me to charge users before they post a posting to my website.
I have been searching for a course or solution example for weeks now and have been unsuccessful. Can anyone help me or lead me in the right direction?
Here is an example:
dummydata form image example
This will work to take you to a payment portal but will not submit my form data to database after payment is complete. If I change action to action="" the data will be sent to my database but no payment will be required.
Thank you in advance!
There are three essential steps:
collect and verify payment
collect content to be posted/displayed
enable post for display on website
Steps (1) and (2), the collection steps, can happen in either order. And probably sequentially, one right after the other. But importantly, they CANNOT happen simultaneously. They are separate processes that occur one after the other.
I'm trying to develop a checkout system for a customer site, and I want to know the best way to do this. Please let me know of any alternatives to what I've tried below.
Currently I have:
1) Items in cart saved to $_SESSION variable
2) When a user presses 'checkout', they are taken to a page with an invisible form that POSTs the information saved in $_SESSION to https://www.paypal.com/cgi-bin/webscr
3) When payment is confirmed, they are redirected to confirm.php on the site that triggers an email to the client and the store containing the information from the cart (stored in $_SESSION) and the address data passed back (as I cannot pass all of the attribute information in the cart to paypal in the first POST) from PayPal.
The issue with my solution is that it doesn't appear to work on mobile safari, iPads, iPhones or older systems. So I'm looking for an alternative, or for a way for the data to remain persistent, as the emails sent out at the end contain no data when performed from one of these devices.
Using a database you can store the entire cart as temporal or incomplete before calling the PayPal payment, and then get all the info via confirm.php, modify the state of the cart, etc.
Also in your PayPal account you can activate automatic IPN upon every payment.
An IPN is a listener that runs on your site and makes calls to paypal. You can find a lot of examples of these on the web.
The idea is that you pass all the fields you want on the PayPal form, and paypal will send it back using the IPN call.
In the PayPal form you can add a custom hidden input:
<input type="hidden" name="cart_id" value="<?php echo $id ?>">
And in the IPN listener you will get cart_id = 4, so you can automatically know which cart payment is done, and which user the cart belongs, change the cart status and email user.
Hope this helps you.
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."
I'm e-commerce developer and have a problem, at certain part of the purchase my code generate a submit form with the purchase info. And send to payment gateway.
This form is generated on PHP and after its generate he write
document.getElementById('formnid').submit();
I'm having problem because somebody are sending discount value to gateway, and i don't know how.
At certain point my project save a log, after generate this form and submit it. And on my log everything is allright. So i suppous he change the value between my send information and gateway geting the info.
Somebody can give me a light i need discovery how he doing this.
Ty in advance
When the payment confirmation comes back from the gateway you should check that the actual amount paid matches the amount that should have been paid.
Only then has the user paid. It's fine to post prices along with your form but it must always be checked upon completion.
If the pricing / discount information is hidden on the DOM (via hidden inputs, for example), manipulating the DOM using Chrome's "Developer's Toolbar" or Firefox's "Firebug" is trivial, allowing for any end user to make changes to those hidden inputs without reprieve.
Never trust the values that come on the form, the value must be always be set\validated on the server side. From what I gathered you are passing the value as a hidden field on the form, and the user is simply altering that.
So I have a multi paged checkout system that relies on sessions to store the contents of the shopping cart. I'm also using a third party system to process credit cards, which hosts the actual payment page on their servers. I just have to POST to the page the final total.
The problem I foresee is what if someone clicks to go to the hosted pay page, and then for some legitimate or nefarious reason changes the shopping cart contents in another tab. I had initially planned that when the hosted pay page redirects back to my receipt page I would then INSERT the order into my database. But, if the session is changed at that point, the order will be different from the total cost charged.
What would be a solution to this problem. I can see this sort of thing being an issue for all cart systems, so I'm wondering how they do it.
Maybe when the user clicks the button to go to the hosted paypage I can make a temporary order entry in a temp_order table in the database, and then when the payment goes through I can transfer that temp record into the permanent record table? That way I don't insert the record from the session information that has changed. But if I have to POST to the hosted pay page, where do I have the opportunity to save the shopping cart to the temp table?
Also, the temp order id must be unique across both temp and permanent tables since I don't want any overlap.
Lastly, I should want to clear the temp order table frequently as they are just temp records. Some might not go through as the user could change their mind on the hosted pay page.
I'm really confused as to what I should do!
I see no need to create a separate table. Just add one column into existing table, say, payment_in_progress and analyse it when client submits any changes to the cart.
The requirement to clear out unprocessed outdated orders remains
When the payment gateway returns just store the amount received against the shopping cart and if the amount received is less then the total, put them back onto the payment page, showing the outstanding balance left to pay.
Unless the payment system returns control to your website before final processing of the order, e.g. like PayPal Express Checkout, there is no way to stay in control of the checkout process. One-way checkout systems are really meant to be one-way. Follow-up management is manual (by a payment receipt) or handled by server to server notifications.
Posting directly to the payment site is not going to give you any control once you submit away to the other website. Probably the best case scenario is you submit the order to your website as an UNPAID order into your database, then provide a page that says "You're almost finished. Continue to payment." -- At this point, you should have also emptied the customer's cart so they cannot change anything about the order in process (which is already in your DB). When the payment system redirects back to your website, you will simply look for the unpaid order and mark it paid. It would also be a good idea to verify the payment amount, just in case the user modified the POST data in an effort to pay less.
EDIT:
You might really be in need of a payment gateway solution that gives you more control over the checkout process. Your concerns are real, but they are not typically addressed adequately using payment flows that send the user directly away from your website without first setting up the transaction server-side.