jknipp | 10 years ago | on: The Problem with the FizzBuzz Problem
jknipp's comments
jknipp | 13 years ago | on: Your ATM does not use transactions
This has nothing to do with transactions in the sense of database transactions or a transaction manager managed by an app server, these may still be used behind the scenes.
jeremyjh did a good job explaining this. I work for a company that supports the card issuance side and previous to that I worked for one of the largest drivers of ATM's for small and regional banks.
This has nothing to do with transactions in the sense of database transactions or a transaction manager managed by an app server, these may still be used behind the scenes.
What happens here is the ATM sent a withdrawal request over the network, that was recorded by the issuing bank - a memo to that account - the bank recorded a debit. Subsequently, the ATM/network/something failed and a second 'reversing' request was sent over the network to the issuing bank, this reversal credit rollsback the initial credit - this may or may not get memo posted to the bank account in real time because reversal transactions can be processed at a lower priority.
During the end of day settlement process, the ATM network 'settles' up with each Bank, during this time the debit/credit markup transactions are dropped and replaced by the REAL activity posted by the ATM network (STAR/Pulse/Cirrus/etc).
ATM systems are a lot more complicated than a simple database transaction, and even I left out several of the steps and possible events that could occur during the process.
During the end of day settlement process, the ATM network 'settles' up with each Bank, during this time the debit/credit markup transactions are dropped and replaced by the REAL activity posted by the ATM network (STAR/Pulse/Cirrus/etc).
ATM systems are a lot more complicated than a simple database transaction, and even I left out several of the steps and possible events that could occur during the process.
jknipp | 14 years ago | on: Ask HN: Where/How do I learn about credit card payments and payment gateways
The device you swipe your card at Best Buy is a merchant device. Best Buy has made an agreement with the device vendor to route its traffic over a specific network, say First Data.
When you swipe the card the network(gateway) decides where to 'route' the request based on the BIN (typically first 6 digits of the card number, can be more depending on how the card profile is setup). The network has BIN tables setup so they can easily identify which cards go where. After the merchants gateway has determined where to route the card, the request then propagates to the issuing network, from there it is sent to the issuer to approve/deny the request.
This is a simple high level overview and by no means complete.
Ex. path
User swipes card @ device -> Merchant devices sends transaction to First Data (where FDC is the merchant device gateway) -> First Data routes transaction to issuing network (Visa, MC, Cirrus) -> Issuing Network forwards request to issuer (issuance processor) for approval
In debit world, it used to be that the more 'hops' a request took to route back to the issuer, the more that interchange that was incurred.
There are all sorts of scenarios that can occur, for example, I'm working on a project that would circumvent the networks if the transaction is for a card issued by our bank (closed loop transaction), which avoids interchange fees paid to the network.
3 out of 4 people so far were unable to do the test. One guy boasted 20+ years of development experience and I used to work with him, he didn't even attempt it?!? Frankly, I expect candidates of any worth to feel insulted we are asking them to write this. The guy that did complete it wrote it in Bash, and wasn't strong in that to begin with. Bonus points for learning a language on the fly, that's what I'm looking for.