Skip to main content

Invalidating an Inprogress Shopping Cart [Resolved]

In the classic 3rd party shopping cart, you create a pending transaction with the amount, redirect the user to the 3rd party shopping cart, they complete payment, and then they are redirected back to the calling application.

Let's say the calling application handles its own catalog, and tracking items the customer has selected. The shopping cart redirect is only for the payment entry and processing.

The risk is the customer has the calling site open in multiple tabs:

  • Navigates to the shopping cart(starting a transactions for one amount) where they are looking at the payment entry page
  • Adds/removes items in the calling application
  • Completes payment entry/submission in the shopping cart tab for the original amount

I've seen hokey schemes where upon redirecting the user to the shopping cart, the calling application sets a flag indicating the cart is interacting with the third party cart, and locks its own cart modification functions. This can be a pretty bad experience if the customer uses the back button to navigate back to the calling site.

You could take snapshots of the cart on each transfer to the shopping cart, associating that snapshot with the items in the cart at the point of transfer, so that when the order completes you know exactly what was paid for.

You could notify the shopping cart via API to invalidate the in-process transaction, such that when the user tries to pay it advises them the cart has changed. This API call could return a failure if the customer has just paid, to handle race conditions, indicating you should not allow the last attempting modification since the cart as it is has been paid for.

Another ideal solution is the shopping cart has enough item tracking information that it can be the source of truth, and you add/remove items directly to it via API as customers interact with the calling site, ensuring it's always up to date. But more often than not what I see is the calling application tracks items on its own, and doesn't build the 3rd party cart with the items in it until the customer is attempting to transfer to the shopping cart.

Alot of this would be driven by what 3rd party shopping carts typically implement to handle synchronization and concurrency issues.

What are good or typical approaches to ensure payments are not invalidated by the customer editing their cart in the calling application?


Question Credit: AaronLS
Question Reference
Asked August 24, 2019
Posted Under: Programming
25 views
1 Answers

You actually build your own shopping cart, and hand it to the 3rd party in the process of deleting it. When the user tries to add a new item to the already-deleted cart, you give them the choice of either copying some or all of the deleted cart (if and only if their page copy contained enough info to identify it's contents) or start from scratch.

If the 3rd party allows items to be removed, and also sends the customer back to you with info describing what got paid for vs what didn't, then you can give the customer the option of adding those items back to a new shopping cart.

This does pose a question: does the customer get to have multiple shopping carts (in which case you might as well call them wishlists, and allow things like saving, naming, copying, locking, and exporting for "buy for wisher" and/or "buy for self"), or just one? There's no particular answer to that though.


credit: aerohammer
Answered August 24, 2019
Your Answer