3

I would like to implement a robust way to handle ecommerce payment for items with limited quantity, like for example exclusive paintings. Payment would ideally be accepted via PayPal and credit cards. Ideally, it would work on a 'first-come-first-serve' basis, and wouldn't just lock items out if you add them to cart like some online fashion stores do.

However, the main problem is that once you redirect the user to the payment solution, you do not have control over the user.

Even if I was to implement some form of locking on items, i.e a user adds it to cart and it is temporarily locked for other users for say 30 minutes - I think this problem would still prevail given the below workflow:

  • User A adds item A with limited quantity (1) to cart. Item is removed from website for 30 minutes
  • User A goes to payment on PayPal.
  • For some reason, UserA does not pay immediately on PayPal but keeps session alive for say 1 hour
  • After 30 minutes, website will restore item A back in stock
  • User B adds to cart
  • User B proceeds to payment
  • User B pays for item
  • User A, with the continuously refreshed session, pays for item as well.

This would result in double-purchase for the same item.

Is it possible to solve this problem 100%? I highly doubt this would happen in real-life, but would like to handle all possible cases.

durron597
  • 7,590
  • 9
  • 37
  • 67
Karl Cassar
  • 271
  • 1
  • 11
  • 1
    I would utterly, vociferously, passionately **hate** any online shop that let me put a rare item into a shopping cart, send me to a payment service and *then* told me "Gee, sorry, we gave it to someone else instead." I don't think whatever solution you come up with could possibly be worth the negative customer experience it would inevitably cause if it ever got triggered. – Kilian Foth Jul 11 '14 at 09:22
  • @KilianFoth Yes, but if I go down that path of "locking" the item if you add it to cart - I still have the problematic workflow mentioned above? – Karl Cassar Jul 11 '14 at 11:51

1 Answers1

4

Usually payment methods involve a step where your application will have to accept the payment. With PayPal it is after the customer is redirected back to your shop. Other PSPs (Payment Service Providers) will have some kind of notification, which you can accept or decline.

At this point you could fulfill the order or decline the fulfillment and the payment.

When choosing a PSP make sure to study the API docs and see if they provide this extra confirmation step.

It would still be not optimal from a customer experience standpoint. But if this is the business model, you would have to communicate very clearly the reasons why orders might not be accepted.

seong
  • 141
  • 3
  • 1
    Yes actually PayPal does require you to confirm the payment thinking of it - I've always questioned why this extra step but this would make sense if we go down that logic. I don't think the payment gateway provider offers such an option though I would need to see if that is something which they do. – Karl Cassar Jul 11 '14 at 11:52
  • @Karl Cassar Can you post here to let us know. I thought they would surely do that so we can use the queueing part from their confirmation step. At the end of the day, most payment processing companies make 1-3% fee anyway. And the queuing and locking as not really too hard. – InformedA Jul 11 '14 at 17:16