In Case You Need Street Parking on Your Next Road Trip

You might want to look for the new generation of parking meters.  

Paying for parking can be a pain in the neck.  Not enough coins.  It can be unclear where to pay.  Or how to signal to the metermanmaid that you have paid.  

This meter has it almost 100% handled in terms of transaction origination.  Adding a static 2D barcode on a sticker, unique to that particular meter, would be easy and accurate.  
With sensors embedded under the parking space, that metermanmaid's job is in peril.  The coin collector's job will fade as well.

The video is here.  I got tired of scaring myself to death when its loud audio auto-played.  There's a Wired ad at the front end.

ATM Security of a Different Sort

In October of 2011, I went to Toledo, Spain with a number of attendees of an S1 user conference.  Payment geeks all, this ATM, which has obviously seen some hard usage, became an instant subject for the photographers in the bunch.  Notice the bars.  Notice the little webcam stuck in the window.  And, yes, notice the EMV reader and PIN pad.

(Now that ACI Worldwide owns S1, let me encourage them to make a return trip!)

The Developer is the Decider

For Visa and its issuers, the path to consumer uptake is via the developer community.  So where's its developer outreach program?

Visa and the card brands have to do a far better job of reaching out to the developer community.  This isn't the Old Days of card acceptance anymore.  The corporate Treasury organization is no longer the exclusive occupant of the payments driver's seat.  The IT organization and the developers responsible for embedding payments into the overall shopping flow are making those choices.  

At the corporate level, the card brands still don't understand today's developer mindset.  Visa's got a leg up with its CyberSource and, in particular, Authorize.Net units as both of them have put together strong developer-facing organizations to speed shopping cart and payment services integration.  But at the brand level the developer still seems to be an afterthought.  And that's not good.  

One brand-provided developer site I reviewed, not Visa's, can only be described as pitiful.  They've all got to do a much better job of reaching out, of going where the developer lives, if they want to succeed.  

Next generation payment gateway providers like Braintree and Stripe get it.  They know they've got to be there when it's 11AM on a Saturday morning and the start-up's engineer who drew the short straw of payment integration is just getting started. That start-up engineer could very well be making the purchasing decision for her next three companies.  

If card brands want to reach deeper into acquiring, and toward the consumer through initiatives like V.me, reaching out to developers first bcomes necessary.  Developers are driving payment innovation - partly because so many of them come from outside the payments industry.

Visting Visa - Discussion on End to End Encryption

I was at Visa's Foster City headquarters recently.  The EMV Migration Forum meeting was taking place. I'm looking forward to hearing what came out of what looked to be a well attend event. I ran into Paul Tomasofsky, president of the Remote Payments Security Council who is working with EFT operators who own the knotty problem of EMV, debit cards, and PIN handling in the US.  

But my purpose was to talk about encryption, Visa's new Consumer Authentication Service, and get a little background on V.me.  This post is about encryption.

End to End Encryption

I spoke with Phil Kumnick, Head of Acquirer Processing.  Our topic was end-to-end (E2EE) and point-to-point encryption (P2PE).  

In August, Visa announced Merchant Data Secure with Point-to-Point Encryption, a service that will be made available to merchants through acquirers.  An approach that uses existing standards, format preserving encryption, and multi-zone encryption, the network is entering a space with no little competition.

Phil said one of its reasons for entering the market now was the end of the wait for the PCI DSS to firm its hardware-based encryption standards.  It’s hardware approach is based on the broadly deployed TDES encryption algorithm and DUKPT key management scheme, the most commonly installed terminal hardware security scheme out there. Visa's approach is also meant to be interoperable with terminals using Voltage Security's IBE, VeriShield Protect from VeriFone and others.  

Visa's offer supports zone-based encryption.  Zones provide flexibility.  In one example Phil gave, a merchant could use a home grown encryption scheme between its terminals and its central system. In the next zone, the connections between the enterprise switch and the acquirer could be based on Voltage Security's IBE method.  The next zone into the Visa network would use Visa's scheme.

Visa's longer term view is not just for encryption.  It includes tokenization.  Given the rising density of dynamically generated signals - from EMV to mobile devices - that are associated with each transaction, the PAN itself can become a token once there is ubiquitous use of dynamic data for all risk scoring and fraud management. The transaction ID field, for example, could be made mandatory as an additional dynamic data element. In that future, the PAN alone will no longer have value. Obviously, given how early we are with dynamic data, the "PAN as token" is some ways off.

The company plans to take a similar approach with software-based encryption, waiting for the PCI SSC to solidify its approach, now expected some time in 2013.  The wait and see approach is to ensure the Visa offering would be fully in compliance with the PCI standards.  

From my point of view, software-based encryption is a key tool if risk assessment is based on the layered approach that relies on the net risk posture calculated from from multiple signals.  Obviously, software-based encryption schemes will have significantly easier deployment hurdles, important especially for consumer uptake of mobile apps with embedded payment capabilities.  But, as the amount of sensitive data increases, so does the need for hardware-based approaches.

My Takeaways

Long term, this has important implications for mobile transactions.  Dynamic data based on all kinds of available signals, not just payments-related data, will let us make the important distinction between card holder present and simple card present transactions.  If Phil knows to a very near certainty that George is the one using his mobile phone to conduct a transaction, Phil's risk in approving it drops accordingly. You could even argue, quite successfully, that this rich data mobile context could be more secure than the magstripe.  If not today, it won't be long before that claim can be made.

Into Other Lines of Business

The acquiring industry's been nervous about what the card brands were going to do once they became public companies.  Guessed at for a long time, it's now become a certainty that the card giants, and Visa in particular, will offer a widening array of acquiring functions to acquirers to help accelerate key capabilities deployment in the marketplace.  Encryption is one of them.  Tokenization another.

The extent to which the incumbents should be nervous, however, is debatable.  Visa operates a network, it sets technical standards for connecting to that network, and manages the rules that govern the network.  That's a very different discipline than providing technical services directly to the acquiring industry, itself principally based on services.  Larger issuers, too, have long standing relationships with their service providers over whom they exert considerable power.  Purchasing acquiring-side services from a traditional revenue provider makes some issuers uneasy.  At the least, the contrasting combination of Visa's traditional functions and its nascent services set is producing some skepticism.  Visa will have challenges in pushing further into the services business.  

On Format Preserving Encryption

Format preserving encryption (FPE) is a key feature for smoothing deployment of encryption services in applications that make use of the 16 digit PAN structure.  Often, the vendor's method retains the first six digits and last four digits in the clear, to facilitate routing (based on the first six) and receipting (the last four).  That leaves just six digits for obfuscation.  

The variability of FPE approaches is such that even the National Institute for Standards and Technology (NIST) is working on an FPE-related standard:

"NIST is currently developing an addition to the 800-38 series of Special Publications, which will specify schemes for format preserving encryption based on the FFX framework. NIST is also considering specifying an online authenticated encryption mode to support Smart Grid as another addition to the series."

Visa as a service provider has to compete, at least in the US, with a number of acquiring processors and approaches, for the encryption business.  The specifics of Visa's encryption and tokenization plans are not without critics.  The format preserving encryption approach that Visa suggests cannot be used, at least according to Voltage Security, for storage.  Clarifying that concern will be required because no one wants to deal with multiple format preserving encryption standards within the enterprise's walls.  Life is already complicated enough.  

Given the continuing evolution of standards, everyone should be keeping a close eye on the NIST efforts.  The PCI SSC issues strongly worded suggestions.  NIST provides technical standards.  

Another Run at 3-D Secure and Issuer Liability in eCommerce: Visa Consumer Authentication Service

Recently, I spoke with Mark Nelsen, Visa's Head of Risk and Authentication Product Development, who is responsible for the new Visa Consumer Authentication Service.  Announced November 26, it is a service targeted toward issuers but, in my view, the larger potential beneficiaries are the e-commerce and m-commerce merchants who must do no little integration work to take advantage of the service.  A skeptic might call VCAS Son of 3-D Secure.  It appears to be a big improvement, though, on its parent's shortcomings.

Payments Authorization 

The payment authorization message is a pillar of the credit and signature debit transaction flow.  But it was built for the card-only world and, as we all know, its adaptation to the Internet has been uncomfortable because that key signal, the card, is not available. Only the easily copied and easily entered magstripe data is at hand. That's been one of the hardest collisions between the payment network and the Big One, the Internet.

We've known for quite a while that today's eCommerce transactions have far more data available to them for stronger risk decisioning.  Signals that pour off of the access device - PC, smartphone or tablet - and data regarding the past behavior of a particular user ID, password, and payment card number, as it's used both online and offline, all of these are available to strengthen the risk assessment.  Merchant databases and mobile device signals - lat/long, phone number, etc. - simply add to that rich data stream.  

Much of that online-generated data, however, has had limited utility because of the incumbent authorization system's inflexibility. From a practical point of view, there's little room to add more capability.  Changes to well established data formats break brittle old code.  

So, the desire to leverage that Internet-generated data in risk scoring has been around for years.  A number of third parties - from credit scoring outfits to device fingerprinting providers and others - have improved the utility of that data but, thus far, it's been confined to the merchant and acquiring side of the transaction flow.

That's not to say that enriching the authorization message hasn't been done by a card brand.  AMEX's enhanced authorization message includes Internet-generated data such as the accountholder's email address.  A merchant who supports the AMEX approach may see fraud detection performance improve by 30% or more.  A big improvement.  Unfortunately, many eCommerce merchants haven't seen the effort needed to support the AMEX enhanced authorization method as warranted because AMEX makes up such a small portion of their transaction volume.

Enter VCAS

The Visa Consumer Authentication Service is the card brand's effort to pull in the rich data available from the Internet in order to provide issuers with a more precise risk score.  It does that using the existing 3-D Secure infrastructure, the one that has often required consumers, as they checkout from a merchant's site, to enter their online banking credentials.  From a consumer experience and merchant point of view, that's a no-no.  US eCommerce merchants, in particular, have loathed the 3D Secure process due to its negative impact on shopping cart abandonment rates.  Once a fraud score invokes a separate login / password screen from a bank's online portal, it's too often "shopping game over."  

VCAS allows the issuer to let low-risk transactions to proceed to the next step, authorization, without prompting the consumer for any additional information.  In cases where a transaction is deemed high risk, Visa recommends that issuers use VCAS’ one time password infrastructure or a challenge / response approach.  

Bank of America's SafePass is an example of an SMS-based multi factor authentication tool.  I use SafePass in specific steps of my online banking life.  Should BofA integrate its SafePass method with VCAS, it could prompt me via SafePass if it sees a risky transaction.  A SafePass prompt would appear, I'd say "send the text", and enter the value I receive on my mobile into the prompt box.  I would not be shown an online portal window requesting  my online banking credentials.

It's easier than it sounds and should provide a better user experience.  I've not found SafePass inconvenient.

In implementing VCAS, Visa also recommends simply approving more transactions and putting those the issuer is uncertain about into the review queue.   That's fine for physical goods or airline tickets.  Not useful for digital products.

How VCAS Works

Rather than breaking apart the existing AUTH message, VCAS operates before the traditional AUTH message.  VCAS consists of two merchant-generated XML messages and two responses from the issuer.

The first message asks the issuer whether or not the account number participates in 3-D Secure. Some BIN ranges, supporting anonymous cards for example, don't participate in 3-D Secure.  A Yes/No response is returned by the issuer.

If the PAN is covered by 3-D Secure, a second message is sent, requesting authentication of the transaction.  The issuer then determines the risk using a VCAS provided score and its own models based on risk.  If the issuer approves the transaction without needing further authentication, it returns in its positive response a consumer authentication verification value (CAVV).  

This key generated value is then placed by the merchant into the traditional AUTH message as proof of authentication back to the issuer.  With the CAVV in hand, the transaction liability remains with the issuer, just as it would for a point of sale, card present transaction.  This is a significant change for online retailers who eat the merchandise loss in e-commerce transactions.

Among the various elements it looks at, the VCAS system includes device identification inputs and historical transaction analysis in order to provide the authentication risk score.  Given the abundance of data signals, Visa predicts the vast majority of transactions will be scored as low risk, avoiding the need to invoke any 3D Secure screens.

Merchant integration isn't trivial.  Merchant must deploy 3D Secure technology either through integration within its own systems or via a third party provider.  It must install a Merchant Plug-in (MPI) to establish a secure communications channel between the merchant, the network and the issuer.

It's About the Merchant AND the Financial Institution.

Visa's been working on recruiting financial institution support for VCAS.  But it's early days for merchants.  They'll have work to do.  And Visa isn't sharing performance metrics yet.  Those metrics will vary widely depending upon the merchant category.  

Given Visa's transaction footprint, however, Visa is hoping VCAS will accelerate merchant adoption of 3D Secure technology. The liability change should help.

There is some connection to its V.me digital wallet service.  The two programs share the same analytical environment using the same data sources.  

VCAS is a solution for issuers.  But roll-out is dependent upon merchant uptake.  Visa needs issuers first but merchants have to follow to make this useful.  With EMV coming to US, issuers are going to have to strengthen the e-commerce channel's fraud protection because, as in other EMV markets, Internet, mobile and other card not present channels will become the preferred target for fraud

Visa's CyberSource acquisition is making inroads into Visa's mainline services set.  At the time of the acquisition, CyberSource customers were able to benefit from analysis of a card number's offline, in-store, at the POS, behavior (we've got to dump that false distinction of offline and online transaction origination soon).  The history of what that card number has done at the POS is now available for VCAS risk scoring.  Given Visa's transaction reach across both channels and branded cards, that behavioral analysis should be meaningful to merchants.

So, for the time being, Visa's VCAS focus is on the issuers.  I suppose issuers are the prerequisite participants because they have to be able to respond with the CAVV for the scheme to work.  But eCommerce merchants are the ultimate users.  They have to install the 3D Secure infrastructure and build the XML files, and more into their checkout process.  

A VCAS Impact on Mobility?

If a mobile merchant integrates to VCAS, the liability shift for those transactions goes away.  The issuer is liable just as with card present POS-based transaction origination. If that's the case, the delta between card present and card not present transaction costs starts to look less like a barrier.  Card not present risk just gets better for the eCommerce and mobilized merchant.  With that CAVV value in hand, both directly entered and card-on-file based transactions look better.  Merchant-specific mobile apps look a lot better whether they're used at home, in the parking lot, or in the store aisle.  If the checkout counter is going the way of the dodo at specialty retail, so could the merchant's own mobile POS terminal. Just let the customer handle the whole transaction.  Apple's already doing that.  

With a strong mobile risk model, what does that do to the NFC value proposition?  If those responsible for building the NFC ecosystem don't hurry up and accelerate its growth, they might need to revisit their business plan.  Again.

Showrooming is Very Real - Just Ask Best Buy

A new Harris poll reveals just how serious showrooming has become for Best Buy in particular.  Walmart and Target aren't immune.  

Amazon continues to eat everyone's lunch.  Fascinating.  If Amazon dominates, won't it have to open retail stores simply to show consumers what they can buy online?  I'm only half kidding.  Retailing is being transformed.

Harris poll press release

Pando Daily's take

Image from Pando Daily's post

Massport Garage Credit Card Payment needs a lever

I came back last night from a family event over the weekend.  This thing needs a handle because it looks vaguely like a slot machine.  Given the cost of parking for less than 48 hours at Logan Airport's central parking facility, it sure feels like a one-armed bandit.

VeriFone Backs Away from Direct Merchant Acquiring

One of the things I appreciate about Digital Transactions is its grounded assessment of payments industry news.  It's reporting of today's climb down from direct merchant acquiring by VeriFone, Digital Transactionss is an example.  The post puts the small retreat by VeriFone into context.  It would have beent tempting to indulge in some schadenfreude because of the company's vociferous pronouncements about Square's launch.

What's more important is VeriFone's revenue growth in North America, the growing percentage of EMV devices it is selling in the US (26% of new terminals support EVM), and its continued focus on its Paymedia software platform.

Here's the story:  http://digitaltransactions.net/news/story/3803 

Here's the post on the VeriFone change of direction by the Wall Street Journal's Tricia Duryee.

No one will be particularly surprised at VeriFone's choice to abandon the micro-merchant market.  Given the cost of reaching them, their tiny transaction volume, and higher risk profile, there's no way it's a particularly profitable venture. Square surely cannot be making money on its base of micro-merchants.  Its journey toward profitability will be from the set of larger merchants it's now taking on, more deals like Starbucks, and the second phase opportunity of selling marketing services to those retailers.  

Past the tipping point for smartphones in Europe

ComScore reports that smartphone penetration in the top European markets is now over 55%.  In a few years, expect similar numbers to be reported in developing economies even with comparatively low bandwidth.  

http://techcrunch.com/2012/12/17/smartphone-penetration-in-europes-big-5-markets-now-at-55-apple-continues-to-feel-the-heat-from-fast-rising-samsung/

Experiencing Payments: Square at Starbucks

Since Starbucks and Square announced their project, I've not managed to use Square at a Starbucks location.  Until yesterday.  It was straightforward.  It was as easy as the closed loop Starbucks app and it had a particularly interesting feature.  See the last panel for that.

The first pair of screenshots show Square as it launches and once I've selected the Starbucks location.  Notice in the first panel, the app picks up the other nearby Square merchants.

The second pair show the payment initiation screen and the 2D barcode as presented for scanning.

The last two are the more interesting.  The first shows that I did two transactions at the store.  

Of more important, the second shows what I bought during the first transaction.  That's SKU-level data, folks.  That means that Square sees Starbucks transaction detail going by.  No doubt, Square's promised to do nothing with it without Starbucks permission.  But that's the level of detail that Square is seeing via its Register application, too.  

SKU-level detail is among the most prized merchant assets.  Walmart would never consider sharing its item-level detail with a payments provider.  That's why on your bank and card statements you only see the total amount of the transaction.   The receipt detail is only with the merchant and on that piece of paper the clerk gave you.  While some wonder about Square's revenue model - it's not making much on 2.75% of a transaction - one can imagine the value of data analytics services.

And, no, I didn't eat both the scone and the cinnamon roll.  Lew ate the roll. 

Although I knew the answer, I asked the barista if he could see any personal information about me.  Nope.  Square's "put it on my tab" capability has not been integrated with the Starbucks electronic cash registers.  

I'm more interested to know if Square is building APIs to its "put it on my tab" capability, among others, so that other eCR makers can support Square.  Anyone know?

Talking with Visa about Payments Innovation (and the Road Trip)

At the end of my conversations with various Visa leaders handling security and e-commerce risk management, I sat down for a short conversation with Erika White.  Here's what they posted on the Visa Blog.  

And here are a couple of video clips.

My Dinner with Steve Elefant

One of the most experienced payments industry participants is Steve Elefant.  Currently consulting to Google on its payments initiatives, Steve's background includes entrepreneurial successes with startups ICVerify, Payment Processing, Inc. as well as his highly visible corporate role as the post-breach CIO of Heartland Payments Systems.  

Last Tuesday, over dinner at the Googleplex and in a conversation about payments innovation, Steve talked about innovation primarily in business model terms.  While he agreed that mobility and cloud are behind the new point of sale, on two major industry trends, the issue was all about business model.

Our conversation is here.

A Shrinking Distinction? Card Present vs. Card Not Present

I'll admit to having been over-focused, even somewhat obsessed, on what I've considered to be the high cost difference between card present and card not present transaction rates.  After all, the difference on some interchange tables is over 100 basis points, a full percentage and more of cost.  Even Square employs an up-charge when card data is entered via the keyboard, 3.50% instead of its 2.75%, a 75 basis point delta.  

Ouch.  That has to hurt, right? It has to inhibit e-commerce and mobile transactions?  Based on e-commerce sales this year, not so much.  And there are far bigger accelerants in play.  The CNP problem may not be as big as I'd thought.

To put it into Maslovian terms, the hierarchy of merchant needs does not begin or end with payment cost.  The nearly entire pyramid of need is about increasing sales.  While transaction costs impact cost of goods sold and the price to the customer (bow to Walmart), a method of increasing sales volume comes out ahead of a 30, 40 or even 75 basis point cost, the typical range for many merchant categories.  It's just a few cents on a $100 sale.    

When you're a top e-commerce retailer, those few pennies can add up quickly.  But even  those costs are lost in the noise when compared to merchandise fraud losses.  Unlike their brick-and-mortar card present competitors, e-tailers are not covered for fraud losses simply because the card is not present, a presentation that has long been equivalent to card holder presence.  And while it's rumored that the top dog, Amazon, has managed its fraud down to card present levels, managing those fraud levels matters a whole lot more than the CP v CNP cost delta.

A lot of innovation and hard work is happening in fraud reduction.  More on that later.

Assuming for the time being that fraud loss management is strong, let's look at the accelerants to increased sales.  A major accelerant is the rise of mobile apps and their use of card-on-file payments.  Despite the fact that these are charged at card-not-present rates, increasing numbers of merchants are more than willing to take on the risks because these apps improve sales.  

Starbucks is, of course, the poster child of that success.  While 25% of its sales are now on its prepaid cards, Starbucks announced at its December 5th investor conference that its mobile channel is now seeing 2.1 million transactions per week from 7 million active mobile users.  Its app not only manages transactions, it supports what Starbucks calls "direct emotional engagement."  Every merchant wants that kind of love.  Mobile apps, when they work well, engender warm feelings if not Starbucks-level passion.  Its integrated Square's mobile payment app, Square Wallet, as yet another mobile payment method to expand that love.

from Starbucks Dec 5 2012 Investor Conference presentation

The convenience of that card-on-file payment, and reload for many, contributes to the appeal.  That's why Dunkin Brands has its own app now for its eponymous Donut shops.  Why Amazon's mobile app is well loved (I'm the only person you'll ever read of who bought a chainsaw at 11 pm from his bed).  And why more brick-and-mortar retailers are looking to apps to drive in-store performance through a either a directly managed card-on-file approach or via a cloud wallet from the likes of PayPal, Google, or Paydiant.

"Direct emotional engagement" trumps a simple piece of plastic.

Experiencing Payments: Flawless MBTA App

December 9 - Back in Boston, Taking the Train Home

And then there's an app that just works.  The new app from the Massachusetts Bay Transit Authority (MBTA) commuter rail system is a delight.  Straightforward flow.  Big buttons for data entry that are context sensitive.  A number pad when you need it (CVV entry).  

The app comes from UK-based Masabi.  It's been used by a dozen other systems.

Now that I've learned how to take screenshots on my S3 (hold the power and home buttons down at the same time, way easy), here's the flow for buying a ticket.  

The splash screen, the main screen, and my options once I'd gone through the From / To station list (didn't think you needed to see that).

Then I chose the card I'd already loaded into the app, i.e. this is a card-on-file, in the cloud, and card not present transaction.

Once the transaction goes through, the ticket is loaded into the My Tickets section.  I've now got two round trips to Boston waiting for me.  The last panel is a shot of my ticket from last night. The rectangle at the top shows the current time, the time block moves back and forth, and the three blocks are multi-colored.  Apparently the color scheme changes on a daily basis according to a scheme that the conductor knows.  My conductor just glanced at the screen, nodded with a "thanks" and put a paper slip in the holder above my head.  Done.

This apps works.  I'm done with digging for cash and coin when purchasing tickets on the train or paying by cash or card at the ticket counter at North Station.  Definitely an improvement.  The user interface makes good use of the mobile phone's limited screen real estate.  The app also caches my past ride routes and email address so it gets easier on subsequent use, just as it should.

Way to go MBTA.  

UPDATE: What the live ticket looks like.

Taking a screenshot on my Galaxy S3 is drop dead simple.  Hold the Home and Power keys down at the same time.  A second or two later, click, it's captured.   

Here are a couple of shots of the tickets I used yesterday for my train ride into North Station.

The color scheme changes regularly.  The time display moves back and forth across the screen so it's clear to the conductor that it's a live ticket.

On the way home last night, I was reading Eric Jackson's The PayPal Wars and was surprised by the conductor who was looking for my ticket.  I fumbled with the phone for a bit to bring up the ticket.  While I was switching to the MBTA app, he moved forward to others on the train.  He turned around a few rows beyond me.  I held up my mobile, he squinted at it, and gave me a thumbs up.  That was it.

Experiencing Payments: The Arco Station on S. Delaware in San Mateo

Sunday December 9, 0829

So much for the user experience

This is one busy gas station.  It appears to have decent prices (for California), is right off Rt 92, one exit from Rt 101, and is a short hop to the rental car return at SFO.  That's why I was there, running late.  After no small amount of confusion, I was running later.

This station has new pumps and new card readers.  While the pump next to me said cash only, this one had the nice new readers and PIN pad so I thought I was in good shape.  I swiped my cash rewards card and even agreed to the $ 0.35 surcharge.  Then, it asked me for a PIN.

Huh?  US credit cards don't have PINs for POS payment transactions.  

Now getting anxious about getting to SFO (I like to make planes, not catch them), I go and stand in line, waiting, more anxiously, to get this figured out and over with.  

The clerk informs me that it's debit only.  Better signage would have helped.  So, it's either throw cash knowing that'll work or go back to the pump and begin the process.  I threw cash. Pumped and returned to the line for my change.

Impressive level of steering toward debit and cash.  Even more impressive that they wanted to charge the $0.35 for the transaction when I made a $43.92 purchase.  That's likely a bit more than the retailer's cost.  Or should be if he's taking advantage of the Durbin amendment.

This petroleum retailer definitely dislikes electronic payments.  And the way I experienced them at that station, I didn't care for them either.  Just for different reasons.

Experiencing Payments: First Square Wallet

As part of this road trip, I'll report on using a range of alternative payment methods.  And some of the old standbys:

Friday December 7

Broadway Barista, Square Register, and Square Wallet

Not so much.  I thought I'd loaded my card into the Square app on my Android phone.  With a patient barista, I tried to enter a Bank of America card into the app which promptly gagged on the card.  So, with a line behind me, I cancelled the Square app approach and tried to use the card.  Bad magstripe.  Another card worked but the alternative payment method sure felt awkward.  After the swipe, of course, Square reported that it's got a good card on file.  Just not the one I wanted.  At least the right picture of my mug is in the app.

Now, on to Starbucks to use Square.  And to a smaller retailer who uses Square Register.