Transaction Types 101

Here is a list and definitions of common payment card transaction types:


The Authorization transaction is typically used by a merchant to obtain the authorization of a transaction amount as a pre-approval for the purchase of goods or services later during the fulfillment process. Authorization transactions are typically submitted for authorization and then funds are held by the issuer until that transaction is captured or the authorization is reversed or expires. An example can be found with online retailers who initiate an Authorization transaction to guaranteed funding by the card issuer prior to the shipment/delivery (i.e. fulfillment) of the goods. An “Authorization” is also referred to as an Auth-Only transaction.


A “Sale” transaction is used by merchants for the immediate purchase of goods or services. This transaction completes both the authorization and capture in a single transaction request. The Sale transaction is an Authorization and Capture transaction that if approved is automatically included for settlement.

Forced Sale

A “Forced Sale” is a transaction initiated by a merchant with the intent of forcing the posting of the transaction against the customer account without receiving prior authorization by the card issuer, or receiving a voice authorization code from the merchant acquiring call center. An example would be when a merchant’s terminal is offline, requiring the purchase of goods being completed without receiving online authorization by the card issuer. Or they received a Voice Approval. In these cases the merchant would enter the transaction details and forward this Forced Sale transaction to the card issuer with the expectation of receiving funding for the goods or services rendered. A forced sale does not require a matching authorization. Forced Sales are also known as Off-Line Sales.


A Refund allows a merchant to refund a previously settled transaction and submit the refund for processing. Refunds are only allowed for financial transactions (Sale and Captured) and are typically limited to the original authorization amount, or a lesser amount, in some cases, multiple partial refunds up to the original transaction amount. Some systems incorporate a feature called Matched Refunds. Matched Refunds must match back to an original transaction to help control fraud. “ Refunds” are also sometimes referred to as a “Credit” transaction.


Void transactions can reverse transactions that have been previously authorized or approved by the card issuer and are pending settlement. Merchants will only be allowed to void transactions that are in an open batch (pending settlement). Sale or Refund transactions are the most commonly voided transaction types.


The Capture transaction will allow merchants to capture a previously authorized transaction that is pending settlement, and submit it for clearing and settlement. An example is when online retailers who initiate an Authorization transaction to reserve funds by the card issuer prior to the shipment/delivery (i.e. fulfillment) of the goods, and then once fulfillment has been completed the transaction will be captured and submitted for settlement. A “Capture” is also referred to as a Pre-Authorization Completion transaction.

10,000 TPS per second

I ran across Kiplinger’s article and picture of “The Credit or Debit Debate Visualized” It is a very nice picture of both the usage of Credit and Debit Cards over time, as well as a nice list of pros and cons and differences between each, I encourage you to check it out for a good basic summary.

In payment systems I don’t really care as much about the type of card, Credit vs Debit at a basic level to me — one has PIN’s and requires usage of HSM’s and require real-time reversals and one uses clearing files and the other reconciliation files. But I digress.

At the bottom of the picture there are some statistics, Kiplinger being a personal finance website and not to mention various “Letters“, these are mostly consumer related, but his one caught my eye:


Which makes me chuckle because lots of prospects tell us they need a system to be able to support the worlds average TPS (Transaction Per Second), or a small fraction of.

You don’t know until you know (or go into Production)

images-2.jpgOver the last six months we have been busy building and implementing an OLS.Switch Issuer Implementation with one of our customers and their banking and payment processing partners. It has been a process of reviewing and implementing message specifications, business processing requirements, authorization rules, clearing, settlement, flat file and reporting requirements. We also filtering external messages into our IMF – Internal Message Format based on ISO8583 v2003, build an interface Card Management functions via our local API’s and message sets. Building client simulators and trying to faithfully reproduce what happens when you are connected to a real system.

Testing on test systems is the next step – replacing our client simulators with other “test” systems that are driven by simulators by the processing gateway we interfaced to. Those simulators have limitations – in their configured test suites or test scripts, some require manual entry to send original data elements for subsequent transaction types, (e.g completions and reversals). We generate clearing and settlement files and match those to on-line test transactions, and our use cases.

After on-line testing, you connect to an “Association” test environment to do “Certification” and run a week’s worth of transactions through a wider test bed. Then you are certified, your BIN goes live and then you enter a production pilot mode – where you watch everything like a hawk.

You can do all of the simulated testing for both on-line transactions and off-line clearing and settlement files that you want – when you connect to the real world and do your first pilot transaction that is where most likely you will see something that wasn’t simulated, tested, or even included in certification, it happens. You need to be proactive, set-up reviews and manual interventions, perform file generation when you have staff available to review the output before it is released for further processing.

What have we seen :

  • Test environments that are not as robust as production or not setup with up-to-date releases.
  • Certain real-world examples are hard to simulate – reversals, time-outs.
  • Thinly-trafficked transactions: (chargeback, representment)…people can’t even define these much less create them in test
  • Poor or incorrect documentation of message specifications.
  • You receive Stand-In Advices or other transactions on-line that you don’t see in testing or certification.

Production pilot is a very important phase of testing – It is where you discover and address the < 1% of issues nobody catches in prior project life-cycles. What can happen, WILL happen. What you think might be something that will occur infrequently will bite you sooner, not later.

twitpay – Pay by Twitter


I had a friend “tweet” me a payment using twitpay this afternoon. I remember twitpay from earily in the year, but unlike my experiences with OboPay and Amazon Payments, sending a txt message or using a website to initiate a payment seem to be the easiest, thus I never signed up with twitpay, I also believe that it was in a early beta as the time as well, and honestly I thought it was silly, why would I use twitter to send payments when there are other working models that I’ve used. But with me being in the payments space and some what of an early adopter, I think I’l give it a shot the next few times I need to pay friends back for lunch.

twitpay uses the Amazon Payments Infrastructure, so you need to create an Amazon Payments Account and link your DDA and or Credit/Debit Cards Numbers to it. As a user of Amazon Payments as an alternative to using Obopay (I found it cheaper and there was less nagging verification) I didn’t need to perform this step.

How to use twitpay. It is easy — just tweet:

@dbergert twitpay $5.00 for lunch money

This would pay the user dbergert (this is me btw) $5.00 with a comment of “for lunch money”

In order for the recipient to claim their payment, they need to be a twitter user, and first follow the twitpay user, and then “Claim” your twitter account, which will result in a PIN that is DM’ed (Direct Messaged) to you from twitpay. then you can see what amounts your are owed, and then you also have the ability to send payments as well. When you want to settle up ? which doesn’t appear to be automatic, you click on the settle-up button to initiate the funds transfer from your Amazon Payments Account to the Recipients Amazon Payments Account. twitpay charges a nickel for transactions over $1.00 to settle.

Give it shot, It is a neat unique way of quickly paying a friend for something, I’m not sure if it works with DM’s so you should note that any payment that you make currently with twitpay are public to those who can read your twitter updates.

I’ve sent a few friends varying amounts between .50 and .75 this evening to see how useful it is, Honestly I’ll probably just use Amazon Payments txt or website interface, but who knows, let’s see how the experiment goes!

SPSP Webinar: Secure Hashing and Scope Reduction Methods

Hashing is one of the most basic constructs of Payment Systems development, as it relates to both secure storage of passwords as well as a method of rendering card numbers unreadable (PCI 3.4), you can also use the hash as a lookup or index in a database if you are performing column level encryption especially asymmetric encryption. I hope the presentation includes the difference between "secure hashing" and "naked hashing"

I encourage my readers to attend the following webcast by the Security of Payment Security Professionals, of which I am a member.


Wednesday, January 21th, 2009 the Society of Payment Security Professionals is hosting a webinar on “Secure Hashing and Scope Reduction Methods”.  You can register for this event online.


I plan to do a follow-up post on this and perhaps with a few code examples 🙂

Batch vs. Real-Time Processing in e-commerce environments

I was having a discussion recently about payment processing in e-commerce environments, specifically Batch versus Real-Time Authorizations. Batch processing has a one-a-day connotation, or that it is simply file based.  Why would you not want to send transactions real-time was the question to me? 

My Answer:  Any time you are not face to face with a customer or if there is a delay before the customer receives the product or service, you should do Near-Time authorizations with the intent of not allowing the mechanics of the authorization impact the customer.

Let me explain:

It comes down to the customer checkout experience as well as to help prevent shopping cart abandonment the payment process should not be an impediment to the customer ordering an item. Especially if there is a glitch, communication issue, or any other outage in the authorization process including late or slow replies. You don’t want your customer to get frustrated during the order process, because they will go some where else to shop.

What is an alterative approach ?

Take the order, log it in a Database with a status of "Payment Pending" or "Authorization Pending"  Have a batch process or scheduled task or cron job that runs on a periodic basis to loop through the list of Orders with Pending Payment Statuses, Securely acquire the required authorization data elements required for the authorization request (Considerations need to be made regarding the retention of CVV2 subsequent to the authorization request, and how the authorization data is managed between the order and authorization request ) and perform Near-Time Authorizations for these orders. Approval responses update the Order Records in the Database, and "errors" and are placed to try again at the next run (Consider Reversals and Duplicate Transaction Checking here on error responses to protect your customers open-to-buy) Declines are noted as Payment Failed, and you send a payment email allowing your customer be notified that the authorization failed, and prompt them to update their payment information on a Secure Account Web Page or call you to provide it over the phone. (Note this method wont work if you are doing any 3D-Secure – Verified by Visa, MC Secure Code , stuff — Which I’ve used I think 2 times in the last 5 years.)


Our you could do it real time and put a message on your cart to your customer, "Please Try Again Later" when an issue occurs with your payment gateway or processor — They will Try Again Later, somewhere else.


In retail environments (or in e-commerce environments with large volume) where real-time is required, you need a redundant payment switch that can handle multiple outbound connections to your processors primary and secondary authorization centers (geographical diversity in their data centers) that run on separate connections (routers, outbound copper, and different telcos)  but also read this here, Andy talks about this in a little more detail, and talks about geographical diversity that runs though a common CO in an issue that a client had with an authorization provider.

Card Readers in Vending Machines

Years ago I assisted a company that developed magstripe readers that would operate in vending machines, copiers, laundry machines for a project related to college campus cards.  My part was to assist them with both the message formats, connection methods, as well as selecting transaction types and device captures modes (Host Based Capture works the best in this model, BTW) for integration to a payment switch and authorization host and ultimately certifying the different devices.


While I was in Dallas last week I took a snap shot of a vending machine that had a similar device:


These are not new, but I don’t visit Vending Machines like I used to and don’t see that many Vending Machines that accept payment cards. This appears to be a model from USA Tech called the ePort. I got a water and coke for a total of $3.00, btw 🙂

OLS – Company Profile in The Green Sheet

logo3In Issue 081201 of The Green Sheet There is a Company Profile of OLS (On-Line Strategies, Inc)

Hugh Bursi, Director of Marketing of OLS worked with the Green Sheet to put this company profile together. Although the article doesn’t reference me or my 12 years of Payment Experience  (Which is small compared to Hugh and Andy’s ) at a Third Party Processor as Director of Technology and Development where I worked with both Insuring and Acquiring Bank’s and ISO’s, it is a great article and great to be in The Green Sheet!