5 ms·

"You just can't put a band-aid type solution on a problem created by a weird race condition" Oh yes you can, and do, often, in payment processing code. I've do

"You just can't put a band-aid type solution on a problem created by a weird race condition" Oh yes you can, and do, often, in payment processing code. I've done it (with a simple sleep for x seconds I think), and I can assure you the higher ups couldn't have been happier.

Slartie 10y ago
Oh, so maybe THAT is the reason why one of our customers had funny cases of thousands of his customers being double-billed on card payments by the payment processing provider! As a developer (of the cash register software, which wasn't at fault in this case), I was kinda amused by the whole thing. But I can assure you, the higher-up business people weren't amused at all.
- Illniyar 10y ago
  Heh. We had tons of double billing from payment processors, we never could get a straight answer from the gateway as to why it happened. Most of them came from.a gateway called CyberSource. Also, lots of customers have weird banks where they see both an authorization (I.e. hold) and the actual capture, and they mistake it for two captures. Usually it helps to educate them about what is an authorization.
  - chris_wot 10y ago
    Man, a bank that doesn't know the difference is a bank I'd be withdrawing my funds from!
    - Illniyar 10y ago
      The bank knows the difference, the reports they send out to customers (or maybe what the customer's see on the site) don't make the distinction clear enough. Most banks don't even bother showing the customer authorizations of any kind.
- deleted 10y ago
  [deleted]
- Illniyar 10y ago
  If your using Java, there's a popular apache http framework[0] that automatically retries a failed request unless you specifically instruct it not to. That bit us in the A$$ with double payments a few times. 0- https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.html https://hc.apache.org/httpcomponents-client-ga/httpclient/ap...
  - magnetic 10y ago
    If you rely on http to ensure the one-and-only-one type of paradigm, I have bad news for you (because you won't be able to distinguish failure vs success case when you hit a timeout: did it not receive the request or did I not receive the ack?). You should embed a transaction ID to ensure idempotence of your API call. Then you can make the request 1, 2 or 3 times without any risk. The receiving end will realize the transaction ID already transitioned state and won't cause multiple payments to occur.
    - Illniyar 10y ago
      Obviously. But youd be surprised, some gateways don't let you send your own transactionId. Or at least they ignored it for determining duplicate requests. Though that was several years ago.
kalmi10 10y ago
I always wondered why cards get processed so slowly in some countries...
nathan_f77 10y ago
You absolutely shouldn't need to do that often in payment processing code. Did you go back and fix it properly later?
- Illniyar 10y ago
  The sleep was as good a solution as we were willing to do. The race condition resulted in an error syncing between two datacenters, so when it happens it can be dealt with manually. Also, to be clear, it did not affect customer waiting time as the delay was in a webhook which we used as a backup to the main payment process.

Slartie 10y ago

Oh, so maybe THAT is the reason why one of our customers had funny cases of thousands of his customers being double-billed on card payments by the payment processing provider! As a developer (of the cash register software, which wasn't at fault in this case), I was kinda amused by the whole thing. But I can assure you, the higher-up business people weren't amused at all.

Illniyar 10y ago
Heh. We had tons of double billing from payment processors, we never could get a straight answer from the gateway as to why it happened. Most of them came from.a gateway called CyberSource. Also, lots of customers have weird banks where they see both an authorization (I.e. hold) and the actual capture, and they mistake it for two captures. Usually it helps to educate them about what is an authorization.
- chris_wot 10y ago
  Man, a bank that doesn't know the difference is a bank I'd be withdrawing my funds from!
  - Illniyar 10y ago
    The bank knows the difference, the reports they send out to customers (or maybe what the customer's see on the site) don't make the distinction clear enough. Most banks don't even bother showing the customer authorizations of any kind.
deleted 10y ago
[deleted]
Illniyar 10y ago
If your using Java, there's a popular apache http framework[0] that automatically retries a failed request unless you specifically instruct it not to. That bit us in the A$$ with double payments a few times. 0- https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.html https://hc.apache.org/httpcomponents-client-ga/httpclient/ap...
- magnetic 10y ago
  If you rely on http to ensure the one-and-only-one type of paradigm, I have bad news for you (because you won't be able to distinguish failure vs success case when you hit a timeout: did it not receive the request or did I not receive the ack?). You should embed a transaction ID to ensure idempotence of your API call. Then you can make the request 1, 2 or 3 times without any risk. The receiving end will realize the transaction ID already transitioned state and won't cause multiple payments to occur.
  - Illniyar 10y ago
    Obviously. But youd be surprised, some gateways don't let you send your own transactionId. Or at least they ignored it for determining duplicate requests. Though that was several years ago.

kalmi10 10y ago

I always wondered why cards get processed so slowly in some countries...

nathan_f77 10y ago

You absolutely shouldn't need to do that often in payment processing code. Did you go back and fix it properly later?

Illniyar 10y ago
The sleep was as good a solution as we were willing to do. The race condition resulted in an error syncing between two datacenters, so when it happens it can be dealt with manually. Also, to be clear, it did not affect customer waiting time as the delay was in a webhook which we used as a backup to the main payment process.