Credit vs. Debit - Part 2

This post expands on my previous post on this subject, in which I try to differentiate 'credit' vs. 'debit' as it relates to payment card processing.  This is a constant source of confusion, especially as it relates to the various nuances of debit card processing.  As background to this piece, I suggest you read the excellent Wikipedia entry which defines online vs. offline debit.

Back in the 1980s, we had a simple, bifurcated world:  there were credit cards (PIN-less and tied to a credit line); and there were ATM cards (always requiring a PIN and tied to a bank account).  Muddying the waters was the advent of the so-called 'check card,' which can be thought of as a 'dual mode' card - it can be used without a PIN as sort of a 'secured' credit card ('secured' in the sense that the cardholder is dipping into real money in a bank account) or with a PIN as a debit card.

Now, we get into some rather misleading definitions that this muddying has caused...

• When you use that check card with a PIN, it's called Online Debit.  For those of you familiar with ISO8583, that PIN-ed request is going to result in you (as the acquirer) formatting an 0200 (the typical MTI used for a Purchase/Sale) request to the Debit/EBT gateway.
• The card issuer (or its authorizer) authorizes that request and treats it as the 'letter of record' (my term) to debit the account in its nightly posting cycle.
• The Debit/EBT gateway may or may not require the inclusion of that Debit transaction in a nightly extract/settlement file (prepped and sent by the acquirer).  As a case in point: the FDR North implementation requires that you put Debit/EBT transactions into a combined settlement file; the FDR Nashville (formerly 'Envoy' before parent Concord/EFS was scooped up by FDR) implementation has no associated extract requirement for Debit/EBT.  [Same company...go figure.]   Even for FDR North, those Debit/EBT transactions in the settlement file aren't there for issuer posting purposes; instead, they provide the basis for gateway-to-acquirer settlement, and they also feed into a 'suspense' process.
• When you use the same card without a PIN, it's called Signature Debit, i.e., because you sign for the transaction like a credit card - of course, new regulations muddy the waters further: at some merchant categories, a signature is no longer required for purchases of < US$ 25, as frequenters of Starbuck's know. 
• Now, the ultimate in misleading definitions: Signature Debit is often called Offline Debit, this despite the fact that 99 times out of 100 (you're not obligated to authorize these, but you open yourself up to chargebacks), the acquirer sends an online transaction request to get an approval decision (for ISO8583-savvy folks, you send an 0100 - the auth MTI - in these situations).  Where the 'offline' designation comes from is that this online auth is not the letter of record.  In these situations, you (as the acquirer) are obligated - assuming the transaction isn't subsequently reversed - to put these 'offline debit' transactions into the settlement/extract file.  And it is these items that the Issuer uses to debit the related bank account.  In other words, the 'offline' appellation here refers to the manner in which the bank account ultimately gets debited, not whether you sent an online request at the time of purchase.
• Okay, to further complicate matters: this Offline Debit transaction is often referred to as a Credit .  Ugh.  Why?  Well, you auth it via a 0100, like credit.  And, when you stick the related entry into the nightly extract file, you format it as a Credit record.  For example, in the FDR North extract file, these transactions get formatted as the Credit 'D' record, not the Debit/EBT 'Q' record.  Indeed, from the perspective of a host-based payment system, you can't tell the difference between a purchase conducted with a 'true' credit card and one conducted with check card in PIN-less mode.  In the words of Dan Rather, "If it looks like a duck, walks like a duck, and quacks like a duck, it must be a duck."