4 ms·
> As long as the uncertainty lasts, you keep retransmitting, That works fine if your payment gateway processor supports idempotent transactions[0][1][2]. Not a
by teh_klev 9y ago
> As long as the uncertainty lasts, you keep retransmitting,
That works fine if your payment gateway processor supports idempotent transactions[0][1][2]. Not all processors do. So your only recourse as a merchant is, in the event of uncertainty, to query the processor via whatever API they provide to see if your transaction was successfully transmitted to and persisted in their system, and discover the outcome..
[0]: https://dev.mca.sh/retrying.html https://dev.mca.sh/retrying.html
[1]: https://stripe.com/docs/api#idempotent_requests https://stripe.com/docs/api#idempotent_requests
[2]: https://en.wikipedia.org/wiki/Idempotence https://en.wikipedia.org/wiki/Idempotence
- zAy0LfpBZLC8mAC 9y ago1. Yeah, hence "Well, I guess to some degree this is a result of payment processors being incompetent [...]". 2. That is actually not a solution. As your communication channel is asynchronous and unordered, there are no ordering guarantees on the delivery of the transaction request and any subsequently sent status queries, thus this approach has a race condition. Also, chances are that such broken systems don't even give you any useful visibility guarantees on "received" transactions, so even if you pretend that IP is synchronous if you wait long enough chances are you'll still have race conditions.