The scenario is pretty simple.
In an e-commerce site, a certain user is given a coupon code and he can use it only once. Coupons are stored in database against each user's id.
Suppose the user adds a few products in the cart to make an order and enters the coupon and then clicks on the 'Pay Now' button and is redirected to the Paypal site for payment.
But the user uses a trick and does not pay just at that moment for the order he has just made. Instead he goes on to make another order by adding few other products in his cart and then again uses the single-time coupon and clicks the payment button to go to the Paypal site.
Now he makes payment for both the orders one after another and thus becomes successful to reuse the single-time coupon.
How to prevent the user from reusing the single-time coupon ? Should it take place before he is taken to the Pyapal site or after he is taken there ? and how above all?
I assume your coupon codes have two states, "used" and "unused" ..add a third state, "pending." When the user puts the coupon code in, validate it then mark it as pending. Once payment is confirmed mark it as "used" and don't let the user enter it again. If the user cancels their order you can make the coupon code "unused" again.
In case coupon is handled by you,
you can create single table, 2 columns:
coupon_id <-- primary key
order_id <-- probably you want this to be unique.
then you store coupon there, or if coupon is already there, you are checking if it is for same order_id.
Is this helping? Please comment and I will improve the answer.
Related
I'm selling some stuff on my website using paypal IPN + PDT. I always check how many items are in the stock before payment. After customer makes his order, he is redirected into paypal for make payment. When payment is completed I'm updating database about selling stuff, until this moment I had no problem becouse I was selling unlimited items. I'm not sure what should I do in case where I have for example 10 items for sell, for example in this scenario:
There is last item for sell. Customer makes his order and he is going to pay on the paypal but he didn't payed yet (website still showing that there is one item for sell ), meanwhile customer B see that there is one item left in stock so he is going to buy it too. in this scenario both customers will pay but only one (faster one) get his product.
What I must do to dont make this happen ?
I can't give you a code answer without seeing yours first, but here's how it could be done on paper :
When customer A clicks the "Pay" button, the item quantity is updated in the database
If the payment goes through, do nothing, if the payment doesn't go through (cancelled, incorrect payment informations, etc) then revert the quantity back to the original
This should work fine as long as you do a final "quantity check" when the user clicks the checkout button. Let's say that both customer A and customer B have an item X in the cart, and there's only one left. They can't both pay for the item, since your system would check the quantity before redirecting to Paypal, and as soon as one of the customers do click on the button, the quantity is updated to reflect the purchase.
Drown's answer is right, and I think it's better to reserve the items (reduce them from the stock) for a period of time, for example for 20 minutes.
You need a cron job or something to give back the unpaid items into the stock.
And if you are worried about crawlers you can set another cron job to check those users who have for example 3 unpaid orders with 20 minutes interval among their payments.
You probably can check this out through the orders table in your database. Maybe you need to block these kinds of users for a while or make a better decision about them.
I am having a problem on an e-comm site i am trying to build where it's possible for a user to add additional cart items when checking out with the SecurePay payment gateway.
When the user clicks 'pay now' button, they are redirected off site to the SecurePay payment page where they enter their credit card information. It's here where its possible for the user to open another page and add/remove cart items after the payment information has already been sent to the payment gateway without me being able to detect it. The shopping cart is a database shopping cart with a cookie as a unique identifier to remember the user.
The problem is that there is no input fields to for any product data in the SecurePay form that's sent to the payment gateway, you can only specify limited information about the order, ie, the total $ amount of the order including shipping(can't even send shipping total separately), a reference number(invoice number) and the currency type(AUD), surcharge percentage etc. So i have to process everything based on the the users shopping cart after the order is successful and they are redirect back to my site. If the user add/removes cart items while they are paying offsite, it is then reflected when i generate the invoice and do the stock take on the order completion page.
Im just not sure how to combat this.
My possible scenario:
I lock the cart when the user hits the checkout page, then unlock it if they hit any other page than the checkout page. Though then there is no possibility of any up selling without taking the user completely out of the checkout process and i'm also worried about any possible scenarios where if the user returns to the site their cart may still be locked. Plus maybe it seems a little messy/hackish of a solution?
I did test a couple random e-comm sites, and it was also possible to add additional cart items from another page during the 'pay now' stage of the checkout process without it detecting the additional cart items unless you actually manually refresh the page. Though i did not verify by actually paying for the items, but i can't see how it would be any different to my problem.
Does anyone have any suggestions?
I initially thought this kind of behaviour was a bug until I learned about upselling. So my solution to this (if I ever needed one), is to make sure every checkout process is a new order, and not a update. And add a hook, to let the user know about the new order, and give an option to discard (clear out) items currently in the cart.
If you can send a reference number, why not use that to generate the order? Whenever the user goes to pay, create an order with the items in their basket and send that number to SecurePay. When the payment is complete mark that order as paid for. If they change the contents of the basket then the old reference number will still refer to the products originally in the basket and if they go to check out again a new order will be created with the correct items in it.
There could be an option - that when the user is redirected back to your site - that secure pay could pass back some information including the amount charged. Then you could check and confirm that figure against whatever is in the cart.
Or - I'm looking at the secure pay developers page and they have two different methods where the customer would never leave your website.
https://www.securepay.com.au/developers/products-and-services/accepting-e-commerce-payments/
Are you in Australia - if yes you could also look at Stripe, it might be easier https://stripe.com/au/pricing
i have a Custom Cart Page which i have built its pretty standard, what i am trying to do is send all the ids of the items in the cart when the user clicks checkout so the user flow is as follows:
1) User Click Checkout
2) Packages added to table one row each item with waiting payment status.
3) User goes to paypal and pays
4) Paypal Ipn picks up payment and order ids via custom field and updates payment status of orders.
So essentially the paypal pay will be a single total payment as opposed to displaying each item. Is it possible to send all item ids via one custom field or do i have to implement a cart style paypal feature which i don't really want to?
I don't see any reason why you can't put a series of Id values in the custom field, perhaps comma separated, but it is only 255 characters long. You would have to parse the field in your IPN handler to separate out the id values again.
But I would suggest using PayPal's cart handling instead, there are no problems with how many items you have to process and also the customer sees a proper list of the items they have bought when they go through the PayPal payment process. More robust and friendlier to the user.
You may find PayPal's Third Party Shopping Cart documentation useful
I have set up a small webshop using PayPal as the payment platform. I am in the process of adding a coupon system, but I recently got stuck.
I have a table containing the different coupons as well as a field for each coupon, containing the amount of uses that particular coupon has left.
Now, here comes the tricky part: I am trying to make a system that prevents people from using the same coupon code multiple times, by checking out at the same time. One solution to this, would be to remove 1 use from that coupon before sending them through to paypal.
So here is the actual question: If I subtract 1 use from the coupon before sending the buyer to PayPal, how do I add that use back to the coupon, if the buyer decides to not complete the transaction and just closes the payment window?
you can have a look at PAYMENTSTATUS of GetTransationDetails()
if transaction failure occures you can add the coupon back
I'm currently implementing Paypal Express Checkout within a Zend Framework Application, I wrote my own cart model which consist of two simple class Cart & CartItem, and they are able to se quantity, get total price, etc.
I'm not much aware on payment system, and I only use Paypal (it's my first time), but I though since I'm not able to control what's happing there (at Paypal) it is a good idea to "lock" the Cart at the beginning of the process (when redirecting to Paypal) to avoid inconsistencies over the current Order processed by paypal and the actual cart on the website.
It can happen for example if the user open a new tab and try to add products while he is a payment process with paypal.
If your cart is locked the use is not able to add or remove anything from its cart until he finished to process the payment thorough paypal or cancel its order.
My question is do you think it is a good approach?
Edit: The reason I don't store anything in the database but only the shopping cart in session is all order are stored with Paypal, so I don't want to store it twice, it is a really really simple system.
I've done it a different way.
When the user browses the site, the cart is stored using a session, a cookie or whatever.
Once he clicks the "pay" button, the content of the cart goes to a orders datable table with a unique ID.
You delete the session or the cookie to prevent him to add new stuff to the order.
You use the unique ID to give it to paypal. Once the payment is done, Paypal comes back to you with IPN, and gives you back the unique ID. From that you know it's paid and can put a boolean or something in your orders table.
Sometimes the user won't pay, and you'll have some never paid orders. You should have a cron that check orders older than one day and remove them from the table.
I think your approach is fine. But make sure you inform the users why they can't add items to cart and offer an easy option to unlock the cart.
Use case:
fill cart
start payment
ah, I forgot the socks
close payment tab
shop opened in other tab
add socks
"you can't add, it's locked"
I can't return to payment to cancel it and can't add anything to cart => i leave