4 ms·
Well, I guess to some degree this is a result of payment processors being incompetent, but really, the idea of "detecting an abnormal state" is idiotic. You sho
by zAy0LfpBZLC8mAC 9y ago
Well, I guess to some degree this is a result of payment processors being incompetent, but really, the idea of "detecting an abnormal state" is idiotic. You shouldn't build distributed system for the unproblematic case and then bolt on corrective measures to make it work through failures--you should build it exclusively for the failure case, and the unproblematic case will just work, with the benefit of fewer special-case code paths and generally lower complexity.
You don't build a payment transaction mechanism that assumes that TCP connections cannot break and then bolt on recovery mechanisms that try to fix things up if they do anyway--you build a transaction mechanism that simply assumes that the TCP connection will break every time. If it doesn't, great, you get better performance, but that's it.
The idea that somehow the uncertainty whether your request was received and processed by the other party is created a certain amount of time after you have sent the request is just confused. The uncertainty starts the very moment the request leaves your machine, and it lasts until you receive an acknowledgement. As long as the uncertainty lasts, you keep retransmitting, in order to guarantee that the uncertainty gets resolved at some point. In order to avoid that retransmissions cause repeated side effects, you assign a unique ID to the transaction so that the recipient can avoid applying duplicates.
- 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.