We ask for both authorization and capture in one API call. One consequence is that we see plenty of unsettled transactions that remain at Open or Suspended statuses. When Amazon implemented the new console last fall, DS added a manual review of the Open transactions to the workflow, settling (on Amazon's advice) anything that didn't look overtly fraudulent.

Recently the option to Collect the Open transactions was unavailable at the portal, and given the volume of these Open & Suspended donations from recent US tests, it would be awesome to look at this before Big English. We saw approximately ~100 Open and ~45 Suspended over the past 10 days. During high volume times those numbers increase, ~50 Open per day during last December being a rough estimate.

What is the best way to handle these stragglers? According to Brick, Amazon does not reach out to donors whose donations are suspended, leaving that up to us (we're confirming this). It would be great if we could automate any part of dealing with the transactions that do not settle in the first API. I asked about options for improving the process for unsettled donations. Brick sent:

We have some documentation you might be interested in regarding our Asynchronous decline process. We have documentation here:

https://payments.amazon.com/documentation/lpwa/201952140

You would also need to incorporate IPNs to listen for the response:

https://payments.amazon.com/documentation/lpwa/201909440#201909440

Our SDKs also include IPN handlers if you implemented using the SDK:
https://github.com/amzn/login-and-pay-with-amazon-sdk-php?ld=ELUSLPA-w.amazon.com

One option is also to first do a synch auth and then if it is suspended, try asynch as a fall back.