Skip navigation
All Places > US Integrated Payments > Blog

How to Migrate to TLS 1.2

Who doesn't love a good, rich security protocol, you may ask?  You love them because they keep your networks safe; cybersecurity hackers love them because they can be back doors into exploiting your network!  So, yes, there is this constant tension or rivalry between the levels of secure communication your system is capable of managing and the potential threats to that network—and it takes a constant diligence to stay ahead of the crooks!  Sometimes this is as easy as replacing your old card readers with more advanced point-to-point encryption readers; sometimes the changes required to update security settings may need to go a little deeper.  At Worldpay, card data security and maintaining the network communication security of our merchants is a top priority that goes beyond being good business partners!

 

Cybersecurity affects and impacts all of us in the payments industry—so we feel it is important for us to share what we know so you can also protect your customers and your business.  We realize that understanding and implementing such things as encryption protocols and secure cipher suites can be complex, so we are here to help. This blog series will explore the potential impacts and solutions available to our partners and merchants and is intended to underscore that we all go through this together, with each new security mandate and each new cyber threat!  So who doesn't love a good, rich, security protocol?

 

Payment Card Industry Security Standards Council TLS 1.2 Changeover: out with the old in with the new!

 

The next big update being required in security is moving internet communication traffic to secure implementations of Transport Socket Layer (TLS) 1.1 and if possible to TLS 1.2—the new gold standard of internet protocols.  Currently, Vantiv supports TLS 1.2 on every processing interface. At this point, TLS 1.2 lives side by side with other currently allowable ciphers, so it is possible to communicate with a "weaker" cipher and still process.

 

In the near future, these other ciphers will no longer be supported and we will be required to disable them.  It is our goal to enable you with the tools and education necessary for an easy, hassle free TLS 1.2 migration. The sooner you get started, the easier things will be for you to make the change, because if delayed, the potential for lost revenue increases.

 

how-to-migrate-to-tls-1.2

 

Below are 5 tips to help guide you through the TLS 1.0 migration on MercuryPay and Express Interfaces.

 

1. What change will the Payment Card Industry Security Standards Council (PCI SSC) require?

July 1, 2018, an encryption method called TLS 1.0 will no longer be approved by the Payment Card Industry (PCI). Anyone transmitting electronic transactions over the Internet must update to a newer version of TLS before that day, or the the potential for processing interruptions is increased.

 

2. How will Vantiv Integrated Payment’s changes impact my business and my merchants?

Worldpay will continue to provide messaging to partners for MercuryPay and Express interfaces to confirm dates of impact. 

 

Developers integrating or testing their existing solutions in our certification (CERT) environments on MercuryPay and Express should consider modifying their applications to support TLS 1.2 as soon as possible. We have updated our MercuryPay and Express certification (CERT) interfaces to only support TLS 1.2. 

 

For more information about how to test support for TLS 1.2 in our certification environment see question 4.

 

3. What happens if a merchant does not update to a newer version?

Merchants and partners who do not update their systems to TLS 1.2, before July 1, 2018, may be at greater risk to processing interruptions.

 

If this changeover is not implemented well before the deadline the impact to lost revenue could be detrimental, because it will be difficult for them to quickly determine why and where exactly their processing capabilities failed. Assume a merchant will have to call everyone involved in their payments chain, starting with their Reseller, POS provider and processor (multiple if gatewayed).

 

4. How do POS companies confirm their software is compatible with newer versions of TLS?

Two ways:

  • To determine what ciphers and protocol you have implemented, go to https://www.ssllabs.com/ and test your browser.  There is no need to wait, confirm that with only TLS 1.2 in place you can still communicate to our CERT environment.
  • On March 5th 2018 the MercuryPay certification platform was updated to support only TLS 1.2 protocol. 
  • On April 2, 2018 the Express certification was updated to support only TLS 1.2 protocol.

 

5. How do I contact Vantiv Integrated Payments for support?

Leave a comment or ask a question.

Questions about product roll out dates

  • Partners should contact their Channel Manager regarding details about production server changes

Technical support questions

  • Partners requiring technical help to confirm or clarify changes that need to be made to their applications or merchant environments can contact Developer Integrations 
  • To determine what ciphers and protocol you have implemented, go to https://www.ssllabs.com/ and test your browser.

 

Additional Resources

Summary

Per PCI 2018 requirements, processing servers are being required to remove encryption protocol ciphers no longer considered safe which include TLS® v1.0 and v1.1. These two protocols must be retired by June 30, 2018. It is important for ISVs, Resellers and merchants to begin preparations for this critical security deadline.

 

If the POS system's encryption protocol is not updated to TLS v1.2 before the production dates listed below, merchants will be unable to process transactions.

 

 

Important MercuryPay TLS 1.2 Migration Dates

Please note:  To our partners and merchants on Datacap Systems' solutions, you are not impacted by this TLS upgrade! Datacap uses a proprietary encryption protocol to protect MercuryPay merchants. 

 

On Monday March 5, 2018 MercuryPay CERT environments (designated in the DNS/URL as "mercurycert.net") were updated to enable TLS v1.2 only. 

 

MercuryPay PRODUCTION environments removal of TLS 1.0 and 1.1 release dates:

Phase

Platform

Date to upgrade

1.

Virtual Terminal

 Wed, June 6

Blackline

2.

Hosted Checkout

Wed, June 13

Vital

Microsoft RMS

3.

Web Services

Wed June 20

4.

Micros

June 27

  • x1.mercurypay.com - no action necessaryFor more information about Datacap System's technology please refer to their site.

 

It is important that partner and integrators continue to test in our MercuryPay CERT environment in preparation for the TLS 1.2 mandate

 

Important Express TLS 1.2 Migration Dates

In support of the removal of TLS 1.0 and 1.1 from the Express Cert and Production environments, and depending on the triPOS version installed, triPOS Direct® integrators and merchants may need to make adjustments to the PC where triPOS is installed.

 

Express CERT removal of TLS 1.0 and 1.1- April 2, 2018

Express CERT Platform URL's:

 

Express PRODUCTION removal of TLS 1.0 and 1.1 June 27, 2018

It is important that partner and integrators continue to test in our Express CERT environment in preparation for the TLS 1.2 mandate.

 

Express PRODUCTION Platform URL's:

 

After TLS 1.0 and 1.1 support is disabled in Express Production on June 27, 2018, merchants will no longer be able to process transactions on the Express platform using payment applications that continue to use the older TLS 1.0 and 1.1 protocols.

 

Important triPOS Direct TLS 1.2 Application Updates

After TLS 1.0 and 1.1 support is disabled in Express Production, merchants will no longer be able to process live transactions using triPOS implementations that don't support TLS 1.2. 

 

The following options are available to force triPOS Direct to utilize TLS 1.2 when communicating with the Express payment platform.

 

OptiontriPOS Direct VersionDescription/Instructions
#15.14.2 or higher

Install triPOS Direct 5.14.2* or higher to automatically force the use of TLS 1.2 without any additional modifications.

 

*It was previous mentioned that 5.14.1 would automatically force TLS 1.2, a bug has been corrected and all integrators should upgrade to 5.14.2 or follow steps 2 or 3.

#25.14.1 or earlierUpdate Windows Registry manually to use SchUseStrongCrypto value for TLS 1.2.  See https://github.com/ElementPS/tls-upgrade for instructions.
#35.14.1 or earlier

Update Windows Registry using .reg file to use SchUseStrongCrypto value for TLS 1.2.  See https://github.com/ElementPS/tls-upgrade for instructions.

 

Product NameVersionTLS Protocol
triPOS Cloud®AllTLS 1.2 - no action nessary
triPOS Mobile®

iOS SDK 1.1.8+

 

 

Android SDK 1.0.17

iOS 8 or lower - TLS 1.2 not supported upgrade to iOS 9+

iOS 9+ - TLS 1.2 no action necessary

 

Android OS Nougat (7.0) or later: TLS v1.2 no action necessary

Previous Versions: Not supported. Any older OS will require update

 

Questions?

Leave a comment or ask a question.

 

Questions about product roll out dates

  • Partners should contact their Channel Manager regarding details about production server changes

Technical support questions

  • Partners requiring technical help to confirm or clarify changes that need to be made to their applications or merchant environments can contact Developer Integrations
  • To determine what ciphers and protocol you have implemented, go to https://www.ssllabs.com/and test your browser.

 

 

Ingenico, a major manufacturer of U.S. EMV peripheral hardware, has made improvements to their previously released Retail Base Application (RBA) in their Telium 2 line of devices. This new RBA version is 21.02. Vantiv Integrated Payments, now Worldpay and Datacap System's dsiEMVUS and dsiPDCX solutions have adopted Ingenico's latest device application, RBA v21.02. This updated RBA is for the Telium 2 line of Ingenico devices (iSC 250/480, iPP320/350, iUC 285, iWL 258, and iCMP).

 

The RBA is the internal programing of the PIN pad and enables advanced functionality and communication to Worldpay. If your POS is programmatically confirming the RBA version, this could impact your customers very soon.

 

Summary

    • Programmatic RBA Checks within the POS application can create unable to process scenarios for merchants ordering new equipment or updating to a newer RBA version in the field.

 

    • The current RBA version 18.04 will be phased out and will no longer be available for new equipment orders or replacements for Datacap solutions on MercuryPay.

 

    • RBA 21.02 provides advanced functionality to the device and is currently the latest version adopted by Vantiv Integrated Payments,  now Worldpay with Datacap dsiEMVUS and dsiPDCX.

 

    • Worldpay recommends new equipment orders and in-field replacements migrate to this new RBA version.

What’s the impact of a programmatic RBA check?

Although this practice is not common, the result can directly impact the point-of-sale application to not support a new Ingenico device or a recently updated in-field device. Thus, rendering a merchant POS application unable-to-process payment transactions. Solutions that support an RBA check will need to make modifications to their existing code in order to support any new device deployment. Acceptable changes may include, but are not limited to:

 

      • Programmatically confirm an RBA version but do not require support for specific versions
      • Remove all code that programmatically confirms / checks RBA versions, and implement a manual process to verify the RBA version during a device startup.

 

Why is it important to adopt new RBA versions?

As way to simplify PIN pad deployments for both partners and merchants, Worldpay will adopt RBA 21.02, helping to minimize mistakes during device deployments. Within Datacap’s NETePay™ and client architecture, this updated RBA is considered backwards compatible. EMV Card Verification Methods (CVMs) and supported transactions can be configured to meet merchant business needs.

 

Additionally, this RBA version supports the acceptance of EMV PIN Debit using the Ingenico Telium 2 series. POS applications that have not implemented a RBA check, adopting RBA 21.02 is considered a drop in replacement for previous RBA versions. There are however some check points to consider:

 

      • If your system is upgrading to EMV Debit using the Ingenico series, this RBA is required as are the latest NETePay and dsiEMVUS client controls.
      • A Datacap engineered Field Loader is available for in field updates of iSC 250 devices.
      • If your system is not upgrading to support EMV Debit, using RBA 21.02 will have no impact to your current card acceptance experience as long as your system does not run a RBA version check.

Resellers:

If you have questions about the compatibility of your application with this updated RBA 21.02 version, your POS developer should be able to confirm if they have implemented a RBA check and if you can support this RBA in Ingenico devices.

 

Developers:

If you have concerns or questions about adopting Ingenico's RBA 21.02 and for additional features this may offer your reseller and merchants, please contact your Worldpay Implementations Consultant.

dmeeker

Bar Tab Rage

Posted by dmeeker Aug 30, 2017

Bar Tab Transaction Flows

dsiEMVUS

 

Bar tabs can be a tricky thing to figure out how to handle from a transaction flow perspective. In this article we will explore some different scenarios that may arise when dealing with bar tabs using Datacap NETePay with dsiEMVUS and hopefully untangle the process a bit and make it clear, simple, and easy to understand.

 

Tab handling is complex and the technology doesn't always solve for the best scenario as there are many different user experiences to  consider.  As an integrator feel free to share how you currently manage bar tabs in the comments below.

 

Act 1:Scene 1

This gentleman finds himself at a bar and would like to open a tab.

The Bartender requests the gentleman’s credit card and opens a tab by sending an EMVZeroAuth

transaction to verify that the card is active.

                     *The EMVZeroAuth also returns a Token, which can be stored for later use*

 

    1. The transaction request is sent from the POS to the dsiEMVUS client control

    2. dsiEMVUS sends the request to the PIN Pad to prompt for card entry

    3. The EMV chip card is inserted into the card reader and the card data is immediately read and encrypted

    4. The secure card data is included into the transaction and forwarded to the NETePay service

    5. NETePay sends the transaction request to the Vantiv host

    6. The Vantiv host decrypts the card data and sends it to the issuing bank for approval

    7. The issuing bank sends the response back to Vantiv

    8. Vantiv takes the clear card data and converts it into a secure token

    9. The response is sent from Vantiv to NETePay, to the PIN Pad, and finally through dsiEMVUS back to the POS

  10. The POS takes the token and stores it for later use

 

*The transaction having been approved, the Bartender hands the card back to the Gentleman

         

 

       

*The transaction having been declined, the Bartender requests a different form of payment           

 

 

Act 1:Scene 2

                              The Gentleman has eaten and drank to his heart’s content (and his wallet’s chagrin) and is now

                              ready to checkout.

 

 

 

 

Scenario 1) While an uncommon situation for a diner, since it is the best thing for the merchant from a processing standpoint the Bartender prints out the check and requests the Gentleman’s card again.

The Bartender closes the check and runs a new EMVSale (which follows the same path as an EMVZeroAuth) for the full amount including the tip and the Sale is approved.

 

 

Scenario 2) Since the POS has the token from the initial EMVZeroAuth a new SaleByRecordNo can be sent for approval.

     *Ideally the Bartender prints off a receipt with a tip line and processes the entire transaction with the tip, but this is

       not as important with a SaleByRecordNo as it would be with an EMVSale

 

 

     1. The transaction request is sent from the POS to the dsiEMVUS™ client control.

     2. dsiEMVUS sends the request directly to NETePay

     3. NETePay sends the transaction request to the Vantiv host

     4. The Vantiv host detokenizes the card data and sends it to the issuing bank for approval

     5. The host bank sends the response back to Vantiv

     6. Vantiv takes the clear card data and converts it into a brand new secure token

     7. The response is sent from Vantiv to NETePay and through dsiEMVUS back to the POS

     8. The POS replaces the old token with the new one and stores it for later use

 

*The transaction having been approved, the Bartender hands the card back to the Gentleman

 

 

 

*The transaction having been declined (Since the EMVZeroAuth did not verify any funds on the card), the Bartender requests a different form of payment

 

Or

                   

 

He sends the Gentleman to the kitchen to wash dishes

 

 

Scenario 3) Finally, what if the transaction did not have a tip added on the initial transaction, but needed to be added after the fact? As a follow up to the SaleByRecordNo an AdjustByRecordNo is sent to change the initial transaction to now include a tip.

 

 

     1. The transaction request is sent from the POS to the dsiEMVUS™ client control.

     2. dsiEMVUS sends the request directly to NETePay

     3. NETePay™ sends the transaction request to the Vantiv host where it will live until the batch is closed and sent to

         the bank for settlement

     4. The Vantiv host receives the request to adjust the transaction and makes the adjustment

     5. Vantiv refreshes the token and replaces it with a brand new secure token

     6. The response is sent from Vantiv back to NETePay™ and through dsiEMVUS™ back to the POS

     7. The POS replaces the old token with the new one and stores it for later use

 

 

Act 2:Scene 1

 

While there are dozens of different scenarios that can be explored, let’s look at just one more:

 

 

What if the Gentleman looked at his credit card statement a few days later and

                                                        realized that the total amount was incorrect?

 

 

          He calls the merchant and explains the situation and finds out that the tip was entered incorrectly.

 

         
      The merchant can partially refund the transaction in the amount that was incorrectly charged.

      The merchant recalls the previous transaction and using the Token sends a ReturnByRecordNo

      transaction, which follows the same transaction flow as a SaleByRecordNo.

 

Final Bow

 

These are different ways to handle bar tabs with the current latest versions of Datacap's NETePay™ (5.06.11) and dsiEMVUS (1.16). In the future there may be a different and even better way to handle bar tabs and once available we will explore that method and its various nuances as well. I hope this article has been both informative and fun to read.

 

Thank you for reading!

Merchants are becoming more aware every day about the security threats they face when accepting sensitive card data. To that extent, they have more resources at their fingertips to determine the best and most secure payment solution on the market. Having access to the PCI Council’s website listing validated solutions or cost effective mobile solutions merchants are expecting more than low processing rates and a standalone terminal. As a developer, what are you doing to stand out?

 

The SI Advantage

A semi-integrated solution is certified to secure hardware and the target host so that the ISV doesn’t have to; the ISV only integrates to the business logic, not the host, shifting the responsibility to the SI provider. SI solutions can help minimize the upfront effort and costs associated with certification, and ease the total cost of ownership with a simple, singular interface to access all services. One example of a software-based, SI solution is triPOS from Vantiv.

 

Payment Simplicity that Matters

Accelerating changes in the payments industry has made Vantiv acutely aware that our POS developers face a difficult dilemma: creating a solution that protects card data without compromising customization or cost. The cost of a data breach can range from $5,000 to $100,000 in fines,[1] and the cost to develop PA-DSS validated solutions can be upwards of $30,000. In addition, the impact from EMV and removing sensitive card data from the POS can hinder the convenience customers and merchants expect.

 

To help solve this dilemma, we set off to strategically invest in building simple, commerce-enabled solutions that are secure, open and offer value to the POS. triPOS is one of our solutions that developers can count on. It has a lightweight design, removes developers from PA-DSS scope and greatly reduces the merchant’s PCI-DSS with P2PE and tokenization technology. Plus, the POS functionality remains within your control. triPOS manages device drivers on your behalf and with a simple configuration file, developers can quickly begin coding and testing their application for production processing.

 

Learning the nuances involved with payments and complex APIs like ISO 8583 can be time consuming and require large scale teams to complete. Payment simplicity is restored with triPOS because 80% of the code managing payments is done for you. Developers can now focus more on the user experience, creating robust reporting or business management tools.

 

Customization vs. Complexity

Vantiv provides developers with a choice. They can integrate to complex device APIs, continuously re-certify their payment application and struggle to be first to market.  Or, they can use triPOS, which is already certified, and delivers new features automatically without needing to re-integrate—whether it is a new supported device or an additional payment processor for EMV. One EMV certified device used by triPOS is the Verifone MX915, a small, sleek device designed to engage consumers in new ways with its full-motion video display. Developers can take advantage of custom device forms to enhance the consumer experience, or help merchants advertise more business.

triPOS is built for simplicity, but is packed with features that helps your payment solution stand out from the competition:

 

Element Gateway – offers access to multiple processors, so merchants aren’t locked in to a single processor.

Account Updater – provides merchants with seamless updates to their customers’ recurring billing account information using our Transform tokenization.

Store N Forward – allows merchants store encrypted pre-authorized card data until the POS system is back online.

Data Security – TransForm® P2PE validated and Tokenization are built in to the solution.

Pass-Through – triPOS devices can read non-financial cards without encrypting the data for internal use.

 

A Smart Approach to Mobile Payments

With the need to support chip cards and desire to accept NFC, merchants are re-examining their POS technologies with an eye toward increased security. This is a great time for developers to enhance their solutions, and partnering with Vantiv and integrating triPOS opens the door for cutting edge technology that better prepares you for the future.

Younger generations are taking mobile payments seriously. Young adults continue to lead the smartphone revolution, with 89% of respondents’ aged 18 to 34 indicating they own smartphones.[2] The transition from traditional cash or credit card payments to new methods hasn’t happened overnight, but the ease of use and convenience associated with mobile payments is appealing—42% of smartphone owners surveyed by Mercator Group, say they have tried mobile payments either in-store or at online retailers.[3]

 

That’s good news for developers because mobile payments come with a number of benefits that will help increase their merchant base and revenue, while providing faster checkout times and better security. Using NFC helps put security at the top of your priority list. Unlike a magnetic stripe card, consumers’ personal information is never in direct contact with the point-of-sale. Technologies such as fingerprint scanning or passwords to pay add another layer of security that chip cards can’t address.

 

Let triPOS help your solution stand out by taking advantage of a single simple integration without sacrificing customization or security. To learn more about triPOS or partnering with Vantiv, contact us today.

 

 

 

[1] http://www.cybersource.com/content/dam/cybersource/Reduce_PCI_Scope_Tokenization.pdf

[2] Mobile Payments is Really Here, Mercator Advisory Group

[3] Mobile Payments is Really Here, Mercator Advisory Group

As integrated point-of-sale systems continue to become mainstream for merchants who want more from their business management tools, cloud processing offers an attractive solution. Cloud POS software developers can more easily enable enterprise technology to SMBs. However, POS developers making the jump to cloud or web-based solutions are finding it difficult to interact with on-site hardware such as chip card terminals.

 

 

How Cloud Processing is Changing the Landscape

According to Gartner, “By 2018 Software-as-a-service (SaaS) cannibalization is expected to create a 40% reduction in maintenance and support…ISVs without a clear sales strategy for delivering and managing the transition to cloud services will see support revenue and margin erosion.¹” Cloud-based POS platforms differentiate themselves from standalone terminals, software installed solutions and native mobile platforms because merchants can:

 

  • run their business from anywhere
  • generate real-time reports and alerts
  • receive real-time software updates
  • create a smaller footprint with less hardware on premise

 

With the need to support chip and PIN, merchants are re-examining their POS technologies. Help retail merchants think beyond the checkout line and deliver solutions that can cost efficiently incorporate enterprise level tools. Chip cards and mPOS are intersecting with cloud POS solutions and SMB merchants in the restaurant business are rethinking how they interact with customers. They need a single solution that utilizes pay at table device hardware or traditional PIN pads behind the bar.

 

Take advantage of an API that supports multiple device APIs, powered by a processing platform, Express, which solves for a variety of merchant verticals. Vantiv Integrated Payments enables cloud processing and device hardware management through triPOS Cloud. ISVs can focus on the merchant benefits above and worry less about costly certifications for chip and PIN or time-consuming PA-DSS validations.

 

What our Solution does for Developers

Using a lightweight API, developers only need to initiate the payment request (with minimal transaction details) through triPOS and the solution takes care of the rest. Our tokenization technology is built into the solution, enabling faster follow up transaction management like voids or tip adjusts.

 

With “56% of consumers willing to use their mobile device to pay for products they are shopping for” (Mobile Commerce Press, December 2014)² , you should know that your solution will be automatically enabled to support technology like Apple Pay or Android Pay with no additional device integration work.

 

In addition, triPOS Cloud creates a simple pairing process with the device and workstation, which helps to reduce your installation costs. There are no networking requirements and with a simple POS configuration, merchants can be up and processing in no time.

 

Start Integrating Today

Learn more about  triPOS Cloud - Overview can help you reduce cost and deliver smarter, faster, easier payments.

 

¹ https://www.gartner.com/doc/2819221/independent-software-vendors-prepare-different

² http://www.mobilecommercepress.com/survey-highlights-consumer-attitude-toward-mobile-payments/8514805/”

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).

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.