Skip navigation
All Places > News > Blog > 2016 > August
2016

Pioneers of EMV

Posted by katharine.unsworth Aug 23, 2016

EMV – It’s been the buzz word for the last two years as integrators work on updating their POS to support the new form of payment to protect their merchants. It’s been a constant game of ‘hurry up and wait’ from the moment the liability shift was announced. Merchants waiting on their ISVs (Independent Software Vendor). ISVs waiting for the integrations they need to be available. Processors waiting on card brand certification to be completed.

 

When I first joined the credit card industry all I knew was that Vantiv processed credit cards, as vague of a term as saying a doctor helps people. It’s a very complex process with many parties involved. At Vantiv we have done everything to offer solutions to our partner as soon as they are certified and simplify the process. From initial beta to initial releases, we have continuously improved our solutions to add more features and functionality to meet the diverse needs of our partners. It never fails to amaze me how many unique ideas our ISVs have and the intense processes they go through to not only design a unique POS system but to also accept credit card payments. One of the greatest confusion is the platform offerings.


Like any great innovation and change it has been a process of building up our platforms, functionality, and capabilities. With each new release we push to offer more EMV compatible devices, more integration options, and more EMV functionality.

 

chip.png

 

From starting off with a single EMV device we have been able to expand our most popular Datacap integration to support over 5 different devices, which keeps expanding! We also have been able to offer a cloud based EMV solution with TranCloud that will continue to expand in order to offer additional hardware providers to meet our partners various device needs. This is just the beginning of a continuous advancing industry and integration options. The amount of work required from our partners and ISVs is astounding. They have gone through certification process, EMV receipt reviews, and Beta phases to test new releases. They have been the pioneers of EMV!

 

I tip my hat to our partners. They have worked with us as we have overcome restrictions and patiently gone through each sanity check as we add new functionality and devices. Still, it is ultimately the customers that
have overcome the most confusion. This first year has been quite a relearning process. We have had to coach our ISVs so that their merchants can offer the best experience to their customers. At Vantiv our TechLift team is here to not
only help integrate to our solutions we are here to help improve the support our ISVs customers, simplify their installation practices, review documentation to offer improvements, and help educate as we continuously evolve in this ever changing and advancing industry.

zkurka

Immortal Technology

Posted by zkurka Aug 19, 2016

I have stated on several occasions to think about upgrade cycles on your POI (point of interaction) hardware at 2-3 years.  One of my coworkers absorbed these statements in the literal sense that 2 years is all they will last in contrast to the common wish that your pin pads are the Highlander, and while only rarely has a  VeriFone 1000SE led to decapitation, is more or less expected to live forever.  

 

The concept of the 2 year replacement cycle is in the light side, I try to say 2-3 because this timeline is often correlated with a PCI expiration.  EMV and NFC were market disruptors in 2015 causing an atypical replacement cycle that fell perfectly between the PCI expirations of 1.x in 2013 and 2.x next April, 2017.  2-3 years could be thought of as the literal average life cycle for hardware in some cases, similar to the lifespan in years of a car driven 30k a year being less than a car driven 5k.  To quote a famous college professor, “it’s not the years, it’s the mileage.”

 

Though that concept of wear and tear leading to shorter lifespans of product is true over a wider array of devices outside of payments, oddly the hardware trusted to enable the most fundamental part of commerce, the exchange of goods for currency, is viewed with contempt and as a necessary evil.  As such it’s uncommon for users or installers to make a concerted attempt to understand POIs.  It’s often just expected to work, and when it does not the responsibility is often pushed to someone else.

 

I often describe the concept of the 2-3 year life cycle as “just like your cell phone”.  My attempt isn’t to suggest that after 2 years you have to worry about your POI hardware overheating, butt dialing, and leaking purple smoke (though I have to admit that would be a cool indicator of end of life).  The attempt here is to shift the paradigm by creating a correlation to the one piece of hardware that most folks can’t live without.  Missing a cell phone has been shown to cause extreme anxiety and in some cases violent responses.  While I don’t see anyone going fetal or getting in a fistfight over a Verifone anytime soon hopefully there is some middle ground.  I muse at a world where POI hardware is purposely retired in favor of newer, more feature rich, and secure tech just as is embraced with the cell phone.  If viewed in this way, natural life cycles would be embraced.  Unfortunately we might be quite a ways away from this relationship with our POS.  A good exemplification of this is the Vx805 shortage in Q4 2015.  The reaction was externalization of the responsibility for the shortage.  I don’t think I heard a single “I” statement in the explanations for 3 months.  If this was a shortage of iPhone7s at the month of the release I suspect the statement would be, “shoot, I should have preordered my iPhone7.”  The tough part about this argument is that it is entirely emotional in that the smartphone is perceived as a desired evil rather than a necessary one.  If you lean towards being one of those adherents enjoy your sinful Apple bliss and please read the next, more mathematical approach.

 

In 2007 my old 20” TV started on the downward spiral.  I was in the middle of my 3rd stint in college and measuring money tightly enough that I knew the cost per egg in the 18ct carton.  It was about 12 cents.  When I added the English muffin, generic American cheese, cooking spray, and a dash of Tapatio, my breakfast sandwich in the morning was just shy of 50 cents (Take that McDonalds!).  My roommate at the time was 1 year out of school and reaping the benefits of having a real life adult job had purchased a 39” Sony 3 months prior.  Now I am not suggesting anyone will ever go out and buy an iSC480 to top your L5200, but I had a real bad case of technology envy.  I looked at a lot of TVs over the next week, but the one I kept coming back to was the gorgeous utopic depictions on the Sharp Aquous.  To add to the already consternating decision it was also on sale….for 900.00!  What is a poor college student to do, but rationalize.  In this case the approach to a 900.00 TV was the same as the Egg McMuffin.  Without boring you with math I figured out my average usage if I expected a 4 year lifespan.  It basically came down to costing me 40 cents a day based on the amount of TV I was watching at the time.  Basically a new TV per diem was cheaper than a breakfast sandwich.  Based on that line of thought what does a set of new pin pads for each lane cost when broken down over the hours of operation and days open per year over 2-3 years.  My guess is that if you get a Starbucks drink each morning at 3.50, your barista could be exchanged for a couple Ingenico touch screens.

 

I wouldn’t be on a soap box professing that we need to change the way we think about our hardware as a worthy investment either by emotional perception or financial rationalization if I wasn’t seeing a slightly dangerous trend in the industry combined with the current doctrine of thought.  At risk of one last analogy, think about the evolution of the automobile over the last 30 years.  In 1980 there used to be minimal electronics and several dozen moving parts.  If something did break the repair was either done with a hammer or a bigger hammer.  Conversely cars today all have computers and of something breaks the clunks, creaks, or splinters of metal are no longer the indicator for the mechanic, replaced by computer diagnostics.  Remote diagnostic services even have the ability to shut your car off it they sense danger.  Our POS hardware is on the same technological tangent.  Chip readers, integrated scanners and contactless modules add to the complexity of the design and opportunities for failure.  PCI security requirements that mandate features to protect data, but can potentially render the pad inoperable necessitate a different thought approach.  We need to perceive the POI hardware as a tool worthy of the investment on a regular cadence rather than an unwanted and unsavory expenditure.

 

Maybe I am a unique technology user.  My phones are new every 2-3 years.  I never expect a longer life out of them and always strategize the purchase of a new one before the demise of the old.  This means I get exactly the life out of the phone that I expect to.  The Sharp is still alive.  I am going to undoubtedly watch some Netflix in high def this evening.  If I got home and the Sharp was dead, I would memorialize it with a cheap breakfast sandwich and start doing the math to justify my next TV.  After all, it doesn’t owe me 4 dimes in fact I have to cost per day down to 5.4 cents.  As I expected to pay 40 cents a day, I am far into the win column on that purchase.

 

I challenge each of you reading this to figure out the cost of the POI Hardware over 3 years.  Also how much does your breakfast cost?
              

I love acronyms and metaphor and how they shape our world.

 

Acronyms are like tribal slang defining ecosystems, abbreviating complexity and reducing enormous monsters of incalculable breadth into palpable comprehension.  Acronyms can be used like surgeon’s hands in any discipline to cut to the chase and bring precise, even life-enhancing, understanding. Acronyms can be soft and gentle reminders; or too, acronyms can be flung like unsuspecting arrows and solicit glazed looks of uncertainty in the uninitiated.

 

Acronyms, though, strive for accuracy, like a wink-wink-nudge-nudge hope to convey meaning. They can end up being academically dry appropriations of something they are not.  Take EMV for example.  The feared disruptor acronym of the payment’s industry, just saying EMV can roll off the tongue like a delectable Rolls Royce sound of elegant craftsmanship, eeeee—mmmm—veeee; sounds like it was a secret password used by 13th Century European royalty or some sacred keystone siren chant in a Dan Brown novel used to uncover new passages of the universe.  Acronyms can have this power.

 

EMV = Euro MasterCard Visa! Is that what it means?   Yes, EMV stands for the 20+ year-old European integrated chip card standard.   As it migrated to the U.S. this acronym played a most curious game—it became the thing.  It, EMV, became synonymous with that thing on a credit card that users need to insert—the chip.   Standards in tow, the Euro crossed the pond to the U.S. and Visa and MasterCard were joined by the other card brands playing at the chip table.  Somehow, the EMV Queen Mary docked in New York harbor and waved a hand shouting “Halloo, We have brought you wondrous shiny things from the homeland.”

 

It might be time to bring this acronym home! Maybe we would have been better off calling it something with substance like a USAVMDA Chip Card (United States of America Visa, MasterCard, Discover and American Express Chip Card) instead of EMV.  OK, well, this is a bit lengthy for an acronym but it has a nice rhythm to it—rolls off the tongue like a Snoop Dogg rap; hip, true, and honest.  You got to love acronyms—but metaphors are the real cat’s pajamas!

 

Metaphors are the DNA of understanding the complex world we inhabit made into an analogy, a like or as phrase that creates a soft cushion reminder of what is truly authentic.  I love metaphors and I am convinced metaphors love me back!  In the payment’s industry in particular, metaphors enliven that DNA like strands of a divine sequence of numbers.  As a SME (Subject Matter Expert) of the MercuryPay’s API (Application Program Interface) documentation, it has always been a struggle not to wax on and into metaphor when, for example, describing the intricacies of an XML or the difference between a void and a reversal.  As we all know, well-formatted XML is like a well-tempered Bach Prelude played meticulously and exactly as written—you cannot miss a note, replace a phrase or stop in the middle without the audience and our processing server throwing a hissy!  Now, a void is like that birthday gift you give your girl friend, but she never wanted a long sleeve angora sweater to take to the Bahamas anyway so she sticks it in the closet never to be seen or worn again; a reversal is the delight in her eyes when you return the sweater, get your money back and let her do her own shopping for that trendy bikini she really wanted.

 

In our DI day-to-day operationalizing, strategizing and quantifying the integration process, metaphors sometimes play a starring role in how we attempt to capsulize what we do. Metaphors can lighten the intensity and placate anxiety—and the really good ones will set you laughing as they level set a common field of vision.  Metaphors are like that—they are fairy dust and release values at the same time.

 

Athletic and fitness metaphors are common as are chess games, fly fishing, Special Forces or Black Ops military operations and Dungeons & Dragons.  Sometimes small animals sneak in as well as large man-eating fish, baking, architecture, religion and beer making.  Yes, beer making. We love a well-fermented and balanced brew of payment solutions all frothing with features and packaged in a secure wrapper. Now that’s a tasty POS!

 

I think you will find acronyms and metaphors a plenty in VantivONE.  They drive the authentic by finding new keys into meaning.  Where acronyms might be more like our tribal drum beats of knowing, metaphors can lift us, TechLift us, to higher places of understanding.

jmather

Habits of Success

Posted by jmather Aug 15, 2016

I had an opportunity to meet and chat with a wonderful individual in our industry recently. This individual is responsible for bettering many people's lives, supplying them with new skills, monetary means and lot of heart.

 

In our conversation, he handed me his card and with a genuine smile presented me with his four habits (on the back of the card of course). After reading these I was met with a nice sense of contentment and I immediately felt these habits are attributable not just to success in sales but success in life.

 

Here are the habits:

 

Ageless Habits for Sales Success

  1. Do what you say you’re going to do when you say you’re going to do it!
  2. Always return your phone calls just as soon as possible!
  3. Sincerely care about your customers’ needs, properly fill them at a fair price, and all of YOUR needs will be taken care of.
  4. ALWAYS be honest, cheerful, caring, and maintain through good and bad times a very POSITIVE attitude….


Do you know who this individual is? I will give you a wild guess, he is a former RSPA Hall-of-Famer. Extra points if you can name him and his company below in the comments (hint, you can click the link in the prior sentence to get a list).

Yesterday’s live webinar hosted by 451 Research was a great opportunity to learn about current trends in consumers’ mobile shopping habits and how Vantiv’s new developer network, Vantiv O.N.E., helps developers address ever-evolving trends.

 

Jordan McKee led the presentation with some interesting facts about how consumers have embraced mobile shopping and payments, including:

  • Technological concepts from mobile pay to tokenization and EMV
  • The key players: Google, Apple, Samsung, Amazon
  • The regulations and standards affecting all of the above


Next came the stats that make marketing so much fun:  how people are using the new technology.  No doubt, retailers are becoming aware that many (if not most) of their customers are price shopping and even competitor shopping from their very own showroom floor. If it were my store, my knee-jerk reaction might be to install some signal jammers, or maybe the better idea might be to advertise heavily that competitor prices would be considered for price matching.  Could this be a new era for negotiated payment experiences at retailers?  It’s always interesting to think about how advances in payments are going to affect the future of retail.


And speaking of the retail experience, payments are already allowing us to pay with our smart watches and other devices. Consumers are shopping in ways you might never imagine, like ordering groceries straight from their refrigerator’s touch screen, or using virtual reality headwear to augment reality shopping.  The future of shopping is indeed enticing, and I believe personal financial consultants are going to experience a surge in clients as consumer budgeting and self-control take new precedence.


The bottom line is that payments are changing.  And this means developers are faced with a lot of work to keep their clients up to speed.


That’s where Matt Ozvat comes in.  Vantiv’s head of integrations and lead technical evangelist, Ozvat describes Vantiv O.N.E. as developers’ go-to place for fast help and comprehensive payments resources.


Ozvat did a great job of explaining the three pillars of Vantiv O.N.E.: TechTools, TechLift and TechTribe.  These pillars offer developers everything they need quickly and easily, saving tech support calls, and time searching through cluttered FAQs and Help pages. Vantiv: O.N.E. is an organized repository of APIs and SDKs, an online support network of Vantiv company experts, and a forum/community of developers who integrate Vantiv products into their solutions.


If you missed the webinar, you can view it now. Enjoy!

So, oh, what I want to know is...what is the payment of the future?

 

Is it by voice?

 

Is it by phone?

 

Is it by fingerprint?

 

By Iris?

 

By ….

 

Innovation is happening so quickly in the payments space it is enough to make a technology geeks head spin. So let’s investigate a bit. If you have read the book “The Singularity Is Near” it may seem that speculation about how we will make payments in the relatively near future is a lost cause. After all, just around the corner we have nano-bots replacing our digestive systems and processing our food for us.

 

Perhaps the most near term (close to reality) piece is IoT using decentralized networks through the blockchain. Imagine a network of devices in your home taking advantage of the cost of energy to moderate usage of your appliances and placing orders for new light bulbs/detergent/batteries on demand. What do you know, now we have robots spending our hard earned money. They are tiny robots, but man can they spend fast!

 

I find the most fascinating piece being our transition to voice technologies. Since the computing machine was invented we have been feeding data to the machine and getting back a computed result (GIGO after all). What if this all changes from here on out with technologies like Viv? Imagine the computer now questioning and learning from us. This may truly usher in a new age of computing. I for one truly believe this is the wave of the near future.

 

So how might this affect payments? Profoundly? Imagine voice payments being interleaved into your daily dialogs. We call this “Voice Commerce”. But wait...how would a computing device be able to classify the nature of your intention to make a payment? These are unknowns, but these are problems being tackled right now. It will change the very nature of our payments technology and our advertising. How do you advertise in a voice first world without interrupting the conversation I’m having with my wife about where to go for dinner? What just happened to pay-per-click and banner advertisements?

 

I will save the discussion for another post as to how I think payments technology might tackle some of these issues, but I will mention of course that machine learning will play a big part.


So, thoughts…? Do you think that paying with your phone is so 2015? Do you think biometric payments are the future? Feel free to open the discussion below.

jbevington

The Next Wave is Here!

Posted by jbevington Aug 8, 2016

The Next Phase of U.S. EMV Receipt Requirements

 

It was the summer of 2015--the summer of the “Y2K of payments,” as my colleague Zach Kurka, prophetically labeled these Nostradamus of payment times.  We were making the move to be first to market with a new Datacap-Mercury U.S. EMV initiative. EMV was going live over Vantiv’s MercuryPay platform and all hands were on deck to make it happen!

 

There was scramble, intensity, on-going corrections of the card brand certifications, operational challenges, focus, chaos, confusion and yet, there were iterative high-hope peaks of hopeful success that we held on to like climbing a Colorado 14er—and everywhere, everywhere there was innovation and invention!  

 

Thanks to Lisa Killigrew, EMV Early Access kits were designed and distributed with everything an ISV needed to dig into EMV—including our first set of U.S. chip cards, a documentation zip-drive, videos plus a stash of chocolates and candy!  Now we’re talking!

Screen Shot 2016-08-07 at 10.14.09 PM.png

The zip drives included early drafts of EMV specifications, Github code links and preliminary certification scripts.  And there, tucked in among the EMV code bells, chip card whistles and a personal welcome note to the new landscape of payments from Matt Ozvat, was the first, simple draft of U.S. EMV receipt requirements for certification receipt review.  I have to admit, in the spirit of Y2K and Nostradamus, we were channeling a little “Oh Canada” when these early access receipt reviews were created.

 

Our Canadian EMV Sponsors had taught us well over the years.  Even in the early days of non-chip Canadian debit, a receipt review was a standard staple of certification.  When EMV was adopted in Canada in advance of their own Liability shifts of 2011, our Toronto based EMV sponsors were so thorough and so unwaveringly diligent at defining the rules of Canadian receipt requirements that these do’s and don’t became practically ubiquitous with EMV receipts.  They were u-biq-ui-tous, eh? 

 

So it was no wonder that the first wave of U.S. EMV receipt requirements emulated what had become a Canadian perspective—that is, receipts should be reviewed for consistency and accuracy as they contain pertinent transaction information for the cardholder, merchant, processor and the issuer that must be correct.  The standard has proven to be spot on and yet, the black and white interpretation of this standard just might be ready for a little 2016 Vantiv ingenuity! 

 

Outside of Canada, receipt reviews were generally new for us, and until U.S. EMV, even the card brands stayed fairly high level with what they called sales draft best practices with the exceptions of things like truncation for card data and expiration dates.  But in the summer of 2015, with our own liability shift looming, we were at the EMV crossroads—and that meant, for the first time, reviewing receipts. 

 

I recall reaching out to Ray Moorman, our quintessential and absolute savant on all things EMV, for his advice. 

 

“Ray, I need to know existing card brand regs for receipt generation—can you send me all that you have?”

 

“Sure can, but it is all over the map—might be best to use what is coming back from Datacap as it covers all the bases.” 

 

So what was determined to be our best criteria for accuracy for this first wave of EMV certifications ended up being based on what was already being returned to the POS from the Datacap EMV control in the form of print data. In so many ways, this made so much sense for the developer and our integration consultants—the whole package of print data is included in an XML transaction response data element called <PrintData> with line-by-line receipt details.  Perfect!

 

The <PrintData> convention was brilliant, even for a one-size-fits-all approach—and it was built right into the dsiEMVUS semi-integrated solution, ready to go.  The bigger win here of course was that the heavy integration lifting, card brand certification and device level interaction was already completed on behalf of the developer and as a result, the POS was abstracted from touching the EMV payment flows.  All that was needed for the ISV was to code to the EMV client control, ask it to send a request to the PINpad, wait for the response and then print the receipt. Brilliant!

 

Not only was it convenient for a developer to pull, parse and print the merchant and customer receipt—it included this EMV data exactly as the card brands wanted to see it.  And this was a perfect synergy to “receipts should be reviewed for consistency and accuracy as they contain pertinent transaction information for the cardholder, merchant, processor and the issuer that must be correct.” Done! 

  • Format of the receipt? Done!
  • Customer agreement and signature line? Done!
  • Chip entry method, Application Label, and all EMV AID, TVR, IAD, TSI, ARC and CVM? Done!
  • Add the merchant receipt header and footer, pass in PrintData and print! Done! 

When EMV hit the U.S. in a fury pushed by the October 2015 Liability shift, we were prepared to accelerate the certification process thanks to our understanding of the Canadian model and the confidence we placed in Datacap’s dsiEMVUS control response data. Done!

 

Out of the gate, the Early Access EMV kits and the Datacap PRINT DATA defined receipt requirements as the MercuryPay/Datacap U.S. golden standard, a standard that has continued through the entire first phase of EMV adoption and by which all of the existing EMV certifications over the MercuryPay platform have followed.  Yes, there were some ISV push backs, merchant complaints of wasting paper, creative adoption of various requirements, but, to date, every certified developer/ISV has managed to adapt to and certify to this standard. 

 

As a reference, here are two examples of the currently established receipt standards for a CVM of Chip and Signature and a CVM of Chip and PIN.  The receipt, all passed to the developer’s POS from the Datacap print data, includes, standard transaction and cardholder details, amounts, cardholder verification and EMV specific application data:

Screen Shot 2016-08-07 at 11.21.55 PM.png

  Fast Forward, 2016. . .

 

A year later, and the first wave is behind us.  The Y2K didn’t happen and we are all still here. EMV is here.  Millions of EMV transactions have been processed and millions of receipts have been printed.  Cardholders have learned what to do and clerks can now multitask while reminding customers of how to respond to prompts on their PINpads.  Receipts happened in perfect, golden fashion everywhere!  One of my favorite things to do is to use my chip card all around town and compare receipts—and I marvel as I see just how ubiquitous the standard has become across all merchants accepting chip—regardless if they are processing with us or another company.  I call this a huge success—for EMV, Vantiv, our ISVs and merchant base—and more, this is success that brings with it a responsibility to move to the next level—the next wave!  Because we were so integral to this first wave of EMV adoption in the U.S., because we held tight from our vantage point on that Colorado 14er, because we listened to merchants, resellers and ISVs, we can help make that next gen happen—the next wave of EMV is here! 

 

As EMV adoption is in a steady ramp-up mode across the U.S., the card brands are coming out with programs and incentives to continue the growth and adoption of chip card usage.  So called “Quick Chip” enhancements, Chargeback limits and easier access with lower costs of direct EMV certification options are being welcomed. Receipt requirements are also going through reconsiderations and here at Vantiv Integrated Payments, we are pleased to share with you the following next wave of card brand receipt requirements. Note that these are minimum card brand requirements and that still the Datacap <PrintData> standard will always be viable, as it will continue to be the most comprehensive set of receipt requirements available.  But as markets, merchants, product and innovation come together to impact these requirements, the card brands and Vantiv are responding accordingly. 

 

Here is the latest wave of Vantiv minimum receipt requirements, outlined by major card brand.  More details and examples will be forthcoming, but consider this a sneak preview of EMV receipts for the future!

 

Visa Credit/PIN Debit card present minimum receipt requirements

Screen Shot 2016-08-07 at 11.11.22 PM.png

Additionally:

Visa requires a completed transaction receipt (paper or electronic) to be provided to a Cardholder for the following:

  • Purchases (magnetic stripe, contact and contactless)
  • Recurring Transactions

 

Visa requires a completed transaction receipt (paper or electronic) to be provided to a Cardholder, upon the cardholder’s request, for the following:

  • Transactions at Unattended Cardholder Activated Terminals
  • Visa Easy Payment Service Transactions (small ticket)
  • Transactions at Contactless-Only Acceptance Devices

 

Note:  Electronic signature capture merchants must be able to provide a printed receipt.

 

 

MasterCard Credit/PIN Debit card present minimum receipt requirements

Screen Shot 2016-08-07 at 11.13.33 PM.png

Additionally:

MasterCard requires a completed transaction receipt, whether the transaction is approved or declined, to be provided to a Cardholder, either automatically or upon the Cardholder’s request for all transaction types.

 

For contactless transactions that specify signature verification, the merchant must generate a receipt to be signed.

A receipt is also required for all contactless transactions following an unsuccessful transaction attempt and the receipt must indicate the response or failure reason.

 

Note:  Electronic signature capture merchants must be able to provide a printed receipt.

 

 

Discover Network Credit card present minimum receipt requirements

Screen Shot 2016-08-07 at 11.15.07 PM.png

Additionally:

Discover requires a transaction receipt for all transactions except for No Signature Required Card Sales unless one is requested by the cardholder.

 

Note:  Electronic signature capture merchants must be able to provide a printed receipt.

 

American Express Credit card present minimum receipt requirements

Screen Shot 2016-08-07 at 11.17.15 PM.png

 

Note:  Electronic signature capture merchants must be able to provide a printed receipt.

jmather

Explorations in Ethereum

Posted by jmather Aug 4, 2016

When I first heard about Bitcoin it must have been in 2009 or 2010, It seemed a regulatory nightmare with huge disruptive potential that most regulatory bodies would never let come to fruition. Somehow though, there was something about it that was intriguing and it just kept taking hold. All said, Bitcoin had and has its issues. One big one is the sophistication required to created decentralized applications using Bitcoin. Along came Ethereum, where in theory, you can achieve decentralized applications by joe brogrammers like me . In Ethereum the hard cryptographic security is taken care of by the protocol itself, freeing you up to focus on what you want your application to do, not with how to manipulate the protocol.

 

To get an overview of the differentiating factors of Bitcoin and Ethereum, you can watch this video starting at the 6 minute 50 second mark and to quote Joseph:

 

https://youtu.be/0ilYnuP1qd4?t=6m50s

 

"The essential differentiating element between Bitcoin and Ethereum is what you can do on it and that’s enabled by the virtual machine and the programming language. In Bitcoin there’s a very simple virtual machine at each node and a very simple programming language. You can only write a very limited class of programs. On Ethereum there is a general purpose computer or virtual machine at each node and a very rich programming language so you can write whatever you can dream up, essentially."

 

So, this got me wondering, how difficult is it to do a hello world in Ethereum. Well, it turns out, if you follow the tutorials in Ethereum, they have an example of this known as the "greeter" app. If you have ever tried this you will realize that it is actually a bit more difficult than it might seem. I'm hoping this tutorial might be a bit easier. So, get ready and fire up your console as here are the "YMMV" Instructions on how to make the greeeter/hello world app function and process transactions in Ethereum. If you don't want to do this and just want to learn a little bit more about ethereum, skip below and read the excellent beginners guide to ethereum.

 

Step 1: Install geth (go based ethereum command line interface)

Step 2: Launch geth in developer mode (this will keep us from downloading the entire blockchain and allow us to more easily mine our own ether.

  • geth --dev console
  • Make not of the ipc folder (it is in a non-standard location when using developer mode), you will need this in Step 6

Step 3: If you haven't already create your own test account now (inside the geth console)

  • Personal.newAccount()

Step 4: Check your account balance (if you have not mined any eth before it should be 0)

  • eth.getBalance(eth.accounts[0])

Step 5: Start the miner and let it run

  • miner.start()
  • This will output a lot of logging so in the next step we will remedy by attaching to the console via the ipc mentioned in Step 2

Step 6: Attach to the console

  • geth attach ipc:/var/your/path/to/etherecum_dev_mode/geth.ipc

Step 7: Ensure that your account balance has increased via the mining that is running in Step 4

Step 8: Go to the online solidity compiler (this is the compiler that will compile your dapp, don't worry about installing your own, trust me, for now just use the online one)

  • https://ethereum.github.io/browser-solidity
  • Now copy and paste your code into the left hand pane of the compiler (this code can be found in the greeter link mentioned above) and it should compile your code with output into the right hand pane:

Step 9: On the right hand pane of the compiler, copy the Web deploy portion of the code (preferably to a text editor) and then modify the portion of the code to have your own message here:

/* var of type string here */

Step 10: Go back into your attached geth console and unlock your account you created

  • personal.unlockAccount(web3.eth.accounts[0]);
  • Ensure you have your password for your account when you run the above as you will be prompted for it

Step 11: Copy the code from step 10 into your attached geth console

Step 12: You should now have received a "Contract mined!..." message with the contract address

Step 13: Now within a short period of time (about 1 minute) you should be able to run:

  • eth.getCode(gretter.address);
  • This should return anything other than "0x", indicating your greeter/hello world contract is live!

Step 14: Now you should be able to run the greeter:

  • greeter.greet();

Step 15: This should return your greeting string that you modified in Step 9

  • This means that you can now theoretically offer this greeter dapp to anyone else for execution by having them create a contract with your ABI (Application Binary Interface) and the address of your greeter with code like below:
  • var g2 = eth.contract([{"constant":false,"inputs":[],"name":"kill","outputs":[],"type":"function"},{"constant":true,"inputs":[],"name":"greet","outputs":[{"name":"","type":"string"}],"type":"function"},{"inputs":[{"name":"_greeting","type":"string"}],"type":"constructor"}]

... ).at('theGreeterAddress');

 

Step 16: Now we have completed the greeter tutorial in a hopefully more friendly walkthrough than the one on the Ethereum website itself! The final step is to cleanup our greeter since we will no longer be using it. If we con't do this, it will leave the abandoned contracts on the blockchain, and in the future, it is noted that we may have to pay rent to use the blockchain. This of course is on the dev network, but it is still good practice:

  • greeter.kill.sendTransaction({from: eth.accounts[0]})
  • This should output something like: "0xf8341d41b7aa69bfbb31ff851b2e39897c4b054bccd9b5c54c19917d3988f561"

 

If you made it through that, congratulations and let me know your feedback!