The typical e-commerce site has to deal with a credit card payment agency web service. It needs to record that payment has been made if and only if the charge is accepted.
That sounds like the successful charging of the credit card and the recording of payment status should be done with typical ACID transactional properties. We don't want anomolies if the server goes down when one has been done but not the other. How can such anomolies be avoided, given that web services generally do not participate in "2-phase commit" distributed transactions?
I suppose the e-commerce site and the payment agency could communicate via a transactional asynchronous message broker, but suppose none is available. How do e-commerce sites cope?
Would the payment agencies deliver occasional batch summaries of payments made so that the e-commerce site can correct anomolies? In that case, the e-commerce site would send the payment and then mark the order paid. If the server goes down before the order is marked, it will be marked paid when the batch summary arrives.
Or would the payment agency offer another transaction that merely verifies the outcome of a previous submission? In that case, the e-commerce site would look for aged, unpaid orders, and query the payment agency so the records could be corrected.