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?

  • Completes payment entry/submission in the shopping cart tab for the original amount... -- and the original items. This is exactly how Amazon does it: you pay for, and receive, precisely what is displayed on the Confirmation Page when you click the Place Order button. Any additional items that were added to the cart but didn't make it to the confirmation page are discarded. Aug 16, 2019 at 18:10
  • @RobertHarvey Agreed, discard items not paid for, but also handling itesm removed from the calling app after the redirect. They were in the shopping cart during the original redirect, but later removed in the calling app. On payment success we need to "add them back". So that would require the snapshotting the cart at the time of redirect?
    – AaronLS
    Aug 16, 2019 at 21:38
  • Amazon just discards the remaining unpaid-for items, unconditionally (they clear the cart after a sale). Aug 16, 2019 at 23:41

1 Answer 1


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.

  • I like this. In essence the deleted cart in the calling app is the "snapshot" of the last transfer to the 3rd party cart, and on payment success notifcation you'd lookup the cart they paid for. Like Robert said, you want their payment to apply to the cart that they paid for.
    – AaronLS
    Aug 19, 2019 at 16:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.