Tag Archives: technology

Dear Internet

Dear Internet,

Today I upgraded to iTunes 4.9. It includes support for "podcasting". Now, despite the wankery about this perpeptuated by every computer technology reporter ever, as if this were some sort of messianic second coming of Jesus, I can't think of any practical reason I'd want to hear people talk about crap.

I ask all of you who support this technology, which is apparently some sort of wet orgy between RSS 2.0 and MP3, to convince me why this is such a earth shattering technology that I should bother messing with it. Preferrably point me toward compelling content, stuff that I'd spend time listening to. You know where to find my interests. I'm not trying to start a technical debate here, but this is only the 200th technology I've been told will change the course of human history forever, so I remain sceptical.

Thank you in advance,
Paul

:-O

:-O

pwn3d..

More than 40 million credit card numbers belonging to U.S. consumers were accessed by a computer hacker and are at risk of being used for fraud, MasterCard International Inc. said yesterday.

In the largest security breach of its kind, MasterCard officials said all credit card brands were affected, including 13.9 million cards bearing the MasterCard label. A spokeswoman for Visa USA Inc. confirmed that 22 million of its card numbers may have been breached, while Discover Financial Services Inc. said it did not yet know if its cards were affected.

Proceeding down the walk of shame now is CardSystems, Inc., a merchant services provider.

For those of you unfamiliar with how credit card processing works, let me give you a quick rundown. Forgive my shitty ASCII art, it's late.

You -> Merchant (merchant either swipes or keys in the number, or if online, retransmits it over SSL to the payment processor) -> Payment Processor (optional, if online – they act as a terminal for you – this is part of the merchant step, really) -> Merchant services provider & Merchant account bank -> Magical credit card interchange system -> Cardholder bank. Then the cardholder bank does a test to see whether the credit limit, amount requested, and all that jives. If the bank is willing to render that payment to you, it returns success, along with an authorization code. If not, it returns a decline with a reason code (my favorite one is "Pickup", which indicates that not only was the card declined, but you should attempt to seize it if you can do so safely).

(If that last part was confusing, my payment processor, Authorize.net, has a pretty little diagram of how it works, simplified, for online transactions)

Then the request goes back to the merchant services provider, who records the transaction as an authorization (and usually a capture too), and then passes the success or fail to you. If you do things like address verification or checking of CVV2, those are usually done at this point, and if they don't match, the transaction is reversed, meaning that you've just created a bit of hell for some poor debit card guy who won't see the hold drop off his account until you batch out.

Anyhow, so the merchant services provider stores a log of all transactions, not only to assist in fraud correlation, but to actually finish the transaction, which occurs in three stages:

  1. Authorization – This actually is where you stake your claim to a specific amount of money, and ask the bank if it's available. Say if I'm pumping gas, I may authorize you for $50 before I turn on the pump, just to make sure that if you hit that, your card can cover it. Restaraunts typically authorize your card for 125%-150% of the bill, to cover tip if you write one.
  2. Capture – In many transactions, this is done at the time of authorization. In things like hotel rooms, self service gas pumps, restaraunts, etc, this is done at the end of the transaction. The amount you capture cannot exceed your authorized amount. If you authorize for $50, and capture for $25, it only takes $25 from the customer's bank account. No actual withdrawal is generally done unless you do a capture. But most of the time, say, getting groceries, buying crap off amazon, etc, this is done simultaneous to the authorization (which is known as an authorization and capture transaction).
  3. Batch – All your captured transactions are held until the batch they are associated with is closed. Typically this occurs daily. Most merchant providers will refuse a batch older than 60 days, so this is often done at least every other day even if you don't do many transactions. The batch actually initiates the transfer of money, which was just set aside for you when you captured. Typically, at this point, the money is enroute, and if you refund someone, or void a transaction, it runs as a withdrawal of your account, a seperate transaction rather than just reversing the one that was already done.

For investigations of chargebacks, or fraud, the merchant provider keeps a full record of the transaction. If someone were to get ahold of this database, the results could be disasterous.

Guess what. It just happened. Endgame.

Let's see how this ends up.

doh!

I really need to read the gas gauge more often. The cool part about having mobile internet, and a cell phone is, that when you DO run out of gas on the side of the freeway, you can call a friend and get some help getting more gas. And while you're waiting, you can just dink around on your livejournal and read work email.

Thanks to unnamed coworker for his (coming soon) help. Doh.

Happily telecommuting from the corner of 11 mile and southfield road. ๐Ÿ™‚

Telcodata changes to backend

Telcodata has been converted to InnoDB throughout tonight. It also has a slave replication going finally, so there can be hot backups of the database, should something bad ever happen to it. (There's nightly snapshots taken and spread around, but until now, nothing was replicating any more frequent than that).

We'll see how this affects perfomance tomorrow morning. ๐Ÿ™‚ I've got my fingers crossed!