Skip navigation
All Places > In the News > Blog
1 2 3 Previous Next

In the News

160 posts

Community Question of the Month

 

Our most viewed question thread this month was a simple (but very useful) query by user arrao on accessing the latest and greatest triPOS release notes.

 

Here's his question: Unable to access the https://developer.vantiv.com/docs/DOC-3006  

 

And here's in the answer for inquiring minds: triPOS Direct Release Notes - Version 5.16.0 - 5.13.0 

 

Congrats to arrao for asking such a good question and congrats for winning a $25 Amazon gift card for asking a question back in April that got 215 views this month!

dayo

Growing in breadth and depth

Posted by dayo Aug 14, 2019

If you want real speed, it pays to be smooth. Put another way, to give your customers the truly responsive and reliable service they expect, not only must your core principles and working practices work in harmony, but also your key assets – your people. Are they working together as smoothly as possible? Do they have the skills they need to do this? And if not, how do you get there? 

 

At Access Worldpay, this work means encouraging its people to grow in breadth and depth. What does this mean? Breadth-first: “It’s about how we can get our developers and cloud engineers to work together to become full-stack developers,” says Andrew Davison, a Principal Cloud Ops Engineer at Access Worldpay.

 

Pairing is sharing

To this end, every project squad within Access Worldpay practices pairing, where software developers and cloud engineers work together. “Pairing really helps for getting the knowledge-sharing going,” Andrew continues: “It’s always good to get a different perspective when you’re working on something.”

Expanding the breadth of individuals and teams is then complemented by increasing the depth of each person’s technical skills. “Traditionally, a developer might gain some rudimentary knowledge about the cloud but fundamentally they might focus and specialize entirely on the software side of things,” says Shravan Jadhav, a Senior Software Engineer. Within Access Worldpay, however, the objective is not only crossing disciplines “but fully understanding those new disciplines and developing your skills.”

 

Making the investment

Enabling people to deepen their knowledge of new disciplines requires investment, which is why a key principle of the Access Worldpay team is to reserve 1.5 days from every 10 day period to improve skills and thereby boost individual and group productivity.

 

For a development group, part of this time is spent re-examining fundamental working principles and practices. The rest is used in ‘personal days’, where individuals can talk to their managers about their training requirements and go on suitable training programmes.

 

Shravan has seen that developers are keen to improve their infrastructure skills. “They might have touched on it a little bit in the past,” he says, but have not developed a depth of understanding that is genuinely useful. “From my point of view, it’s always been ‘I can write this code but then how do I actually use it?’ because obviously, I can’t just run it on my laptop. Being able to deploy that code properly and have a full view of the end-to-end flow, that’s the bit I’ve always missed.”

 

Testing in the cloud

For cloud engineers, meanwhile, the primary focus is learning how to bring test-driven development (TDD) into the cloud. “There’s been a big, strong push to adopt TDD in the cloud and it isn’t always easy to understand how to write or implement a test in the infrastructure world that works well,” says Andrew. “A lot of cloud engineers are looking to learn how to write tests – lots of us did an infrastructure testing hackathon recently to try and get hands-on with writing infrastructure tests.”

 

The fundamental purpose of growing in breadth and depth is about helping developers and cloud engineers to work “across principles,” Andrew says. “So we have cloud engineers tackling dev approaches like TDD, but we also have developers working on cloud infrastructure, learning about how we do things and working with us to get the product delivered.”

 

Shravan agrees, saying that developers’ familiarity with TDD has proved useful when learning about infrastructure. “When you’re making changes in the cloud, using tests allows us to see if our changes are working even if, at first, you don’t fully understand the tools that cloud engineers use.” The process of testing and checking gradually allows developers to increase their understanding: “it’s a much safer way of upskilling, and a safer way for developers to be able to contribute to infrastructure right off the bat.”

 

Breadth, depth and beyond…

Although the push to increase breadth and depth has certainly helped drive improvements within this particular area, its rationale does not end there. “We’ve focused a lot on testing because TDD is just fundamental, but obviously this isn’t just restricted to that,” says Shravan.

 

Instead, he believes this shared approach can help with all the new concepts and technology that Access Worldpay wants to use. “Everything we do consider tends to be more holistic, so one of the ways we’re trying to grow in both directions is by bringing everyone onto the same page in the first place,” he says. “If you’re working on the same thing then it doesn’t matter whether you’re a cloud engineer or a developer – we can have just the one, single approach.”

 

To experience the breathless pace of software development today, just think about the constant cycle of app updates on your phone. It’s no different for Access Worldpay, but with greater stakes – instead of providing extra levels for Candy Crush, its releases improve and protect financial platforms trusted by some of the world’s largest organizations to secure the personal data of millions of customers. So where does continuous integration fit in?

 

For a payments organization like Access Worldpay, the ability to respond quickly and reliably to customer demands is less a competitive advantage than a business necessity – it is simply today’s operating environment. It is also the impetus that drove the team’s adoption of the Agile approach to development, which it refines wherever possible to improve efficiency still further.

 

Team: dynamic

Ben Haswell, Engineering lead, explains that the same considerations lie behind continuous integration. This enables a large team working on a single project to work as quickly as possible by minimizing code clashes and the delays they cause each new release. 

 

Each developer works on a small, specific task and then commits the changed code to a shared repository which holds the code for the whole project. Given that each team has five or six developers, each making changes on a potentially hourly basis, the repository can easily receive dozens of changes every day.

 

“Having lots of people working off the same repository means that everyone’s getting the latest changes at the same time,” says Ben. The alternative, he explains, is to commit multiple changes later on, “but the longer you leave your commits, the greater your chances of getting code clashes.”

 

Ben Haswell and Oludayo Fafiolu

 

Clearing hurdles

Once a developer has committed a specific change to the shared repository, it goes through the build pipeline – a process with lots of hurdles, or ‘stage gates’, which run the change through a suite of tests to verify that the change has not damaged any other code in the repository. “Nothing can get through if it breaks any of the gates,” says Ben, so passing the tests “proves that the change works – you don’t have to do a whole load of heavyweight testing.” This gives developers an underlying degree of confidence in their work: “you don’t have to worry that the application might not start at all, or that odd behaviours are down to a fundamental breakage.”

 

Keeping the build working – or ‘green’ – is key to enabling frequent releases, so should a change committed to the repository fail any of the tests, the team is alerted immediately. “Any fail is a ‘stop the line’ event and you’ll get the team swarming to get the build back to green,” says Ben.

 

As a result, problems are quickly identified, “and the earlier you spot a problem, the easier it is to fix,” he continues. “If you batch several changes together, all at once, chances are you’ll get a lot of code conflicts” which take far longer to identify and resolve. Continuous integration, therefore, is like untying a series of individual knots in a long strand of wool before it becomes a tangled mess.

 

Trunk-based development

The need to resolve problems quickly is particularly important because the team practices trunk-based development. Instead of developing code on different branches, every developer commits each change to the master code. “It means the master is always updated with what everybody’s doing, so it’s always releasable,” says Ben. “You don’t have people working in isolation, where a change may work on their own branch but cause problems when merged into the master code. This way, you’re getting feedback as soon as possible.”

 

Combining continuous integration and trunk-based development enables robust, reliable code to be produced by a sizeable team very quickly. Given that the team releases a new version of its master code approximately every two weeks, this is essential. “If you want to be able to react quickly and release quickly, you want continuous integration. It means that whatever’s on your master is valid and up to date and can be released as soon as possible.”

 

Responsive and responsible

This swift release of updated and improved master code is essential for Access Worldpay to continue serving its customers effectively and, therefore, competing successfully in its business environment.

 

“When a customer wants changes made, continuous integration is absolutely fundamental to how we respond,” says Ben. “Only with continuous integration can you make those changes, validate them quickly and get them to the customer promptly.” Put most simply, continuous integration enables Access Worldpay to be both responsive and responsible and thereby deliver rapid, safe change.

Testing is a critical component of your payment integration process across in-person, online, and mobile channels. To provide the best customer experience possible, everything within each transaction must work consistently to deliver fast, accurate, and secure payments.

 

Part of the value of working with Worldpay’s payment APIs is that we have several eCommerce testing and certification platforms that are optimized for different applications that your company may use.

 

Working With eCommerce Pre-Production

 

There are three testing environments available: Sandbox, Pre-Live, and Post-Live. This article describes each environment, including how they are used and any roadblocks or issues that arise during the testing process.

 

Pre-Production Testing Environments

 

Pre-production testing environments include Sandbox and Pre-Live.

 

The Sandbox environment is a simulator to test your payment integration process. It has a basic interface that allows you to conduct functional level cnpAPI, Chargeback API, and the Merchant Provisioner API (V13 and above) message testing. While it’s typically used with cnpAPI Software Development Kits to gauge basic functionality, you can also test XML messages for the aforementioned three supported APIs.

 

You do not need a password to use the Sandbox. You can find it online at

 www.testvantivcnp.com/sandbox/communicator/online.

 

In terms of any limitations, it’s important to remember that the Sandbox is not made for testing full functionality. As a stateless simulator, there is no historical transactional data. Therefore, the Sandbox is not for certification or regression testing.

 

Next, the Pre-Live test environment is used for all merchant certification testing. It is recommended for new Worldpay eCommerce merchants that may be coding a direct XML integration for the first time. It is also applicable for existing Worldpay eCommerce merchants who want to include additional features or functionality as part of their XML integrations.

 

Although this testing environment provides a working version of the Worldpay production system, it operates using simulators rather than communicating directly with the card associations.

 

The Pre-Live environment gives you the ability to undertake self-provisioning of a basic test account through www.testvantivcnp.com/prelivemid. This account lets you submit most standard transaction types. However, you cannot test many of the Worldpay eCommerce Value Added Services (VAS).   

 

Other limitations include the number of merchants configured per organization. You’ll only be able to use as many as necessary to perform the required certification testing. Also, data retention is limited to 30 days.

 

Post-Production Testing

 

The post-production testing environment is known as Post-Live. This environment is a copy of the merchant’s production and matches your Worldpay eCommerce Production profile, which is set up for VAS and their MIDs. It’s also where you can perform regression testing to ensure you are prepared to start accepting payments. 

 

You can use this testing environment after becoming fully certified and submitting transactions to the Worldpay production platform. When you complete the initial certification and on-boarding process, we migrate you to the Post-Live environment so you can complete any ongoing testing needs.

 

The Post-Live system provides a working version of the Worldpay production system. However, it still operates using simulators rather than communicating with the card associations. Unlike the Pre-Live platform, though, all merchant accounts/IDs are in sync with the Worldpay production environment.

 

There are some limitations to keep in mind beyond just the simulators used during this testing environment. It can only process a daily limit of 1,000 online transactions and 10,000 batch transactions.

 

Common Roadblocks

 

In terms of common roadblocks for Sandbox, this is primarily an independent testing environment where we do not get involved. This is because we do not have any logging  or merchant interactions within that environment.

 

For Pre-Live and Post-Live, common roadblocks include IPs that are not properly identified and are accessing these testing environments. Therefore, they are not whitelisted, which prevents them from gaining access to the environment.

 

Additionally, using the incorrect URL/Credential/MID combination can create issues.  Each environment has its own URL to post transactions and XML credentials and MID(s).

 

Transactions and Response Codes

 

All testing environments include data you can use to test your transaction processes. This includes card numbers, expiration dates, and transaction amounts, which enables you to generate structured requests that match the required cnpAPI schema. Our Implementation Consultants will work with you to create and access your test account.

 

Remember that it is important to determine which transaction types you will use according to your business needs before you begin using the aforementioned testing environments. Basic transaction types include Authorization, Capture, Sale, Credit, and Void. However, there are others to consider. For example, if you offer Direct Debits as a alternate payment method, there will be specific certification tests. Or, if you use the Insights feature set, there are more Authorization tests to undertake. 

 

For example, you’ll want to test authorization as part of a payment. This Includes AVS Only, Capture, Credit, Sale, and Void Transactions. Just related to authorization testing, there are 26 data sets you can use. There are standard authorization tests as well as those for partial authorization, prepaid indicator, affluence indicator, and declined or duplicate transactions.

 

You can also opt to receive information like the issuer country for the card that will help you detect any potential fraud and verify the origin for the purchase. Response elements will send back messages like approved or declined, the type of payment like prepaid, available balance, and approved amount.

 

There are other test transactions, such as reversal transactions, direct debit transactions, token transactions, and query transactions. Processing tests include stored credentials and online duplicate transaction. You’ll also be able to test for refund authorization.

 

Numerous optional tests provide a way to customize the payment testing environment to your business needs. For example, you can test address responses, international cards, security code no-match, tax billing, recurring payments, advanced fraud tools, and convenience fees. Other test address specific alternative payment transactions like gift cards, MasterPass, Apple Pay and Google Pay

 

Learn More

 

dayo

What does TDD mean to us?

Posted by dayo Jul 25, 2019

Global companies rarely get to write software from scratch, reappraising existing code, methods and assumptions before deciding whether or not to apply them. Access Worldpay provided such an opportunity and the team seized the chance to refresh their approach by embedding test-driven development into their work. Two years on, we asked two engineers for their views.

 

Most software engineers recognize test-driven development (TDD) as best-in-class methodology, and within smaller businesses, it has become standard practice. However, large organizations can struggle to embrace it, partly because of roadblocks caused by legacy software.

 

Changing Mindsets

Another issue is the “change in mindset” that TDD demands, says senior developer Ignas Traskevicius. Engineers need to concentrate not on the precise code needed to satisfy one specific task but, instead, focus on the larger goal the software aims to achieve. That sounds straightforward but, he says, it represents a “complete inversion” of traditional approaches to development that requires engineers to “write an automated test for code that is not yet there… to think up with the most convenient interfaces for this component, even in the abstract, and then use them within the test although such interfaces may also not yet exist.”

 

Such mental gymnastics are difficult but, continues Ignas, they deliver significant benefits. These include “better abstractions and leaner interfaces, with cohesive code brought together.” Moreover, TDD-led components are less coupled to others, so changes made in one component are less likely to affect others. This all results in software with robust architecture and maintainable code, which becomes more important as the software becomes increasingly complex over time.

 

The intellectual rigor involved is precisely why TDD has become fundamental to Access Worldpay’s approach – so much so that the maxim “If it’s not tested, it’s broken” is one of the team’s guiding principles. But exactly what impact has TDD had in practice?

 

the team at Worldpay

 

Code to the test

“The important difference TDD has over other forms of tested software is the ‘driven’,” says Alastair Donlon, principal developer. “You start from the ‘test’ first – it drives everything else.” Ignas adds: “You have to design the test in the abstract, without thinking about how it will affect implementation. Only once the test is complete can you start working on the production code to satisfy it.”

 

This process pushes engineers to start by breaking down the code to the point where they can control its dependencies. As a result, every individual piece of software is written with sound architecture and clear code which engineers can continue to support, even when combined into much larger packages.

 

By contrast, says Alastair, “a test-afterward method creates software with intertwined dependencies that make it harder to test the code in isolation. It becomes very difficult to move past that, to write a test for that code and to use it in other places.” Ignas goes further: “Applications that aren’t covered by TDD or some form of automated test are broken – if not immediately, then sooner or later.”

 

Tests breed success

Since it was introduced, TDD has worked well for the Access Worldpay team. “Wherever TDD is used, I see successful software,” says Alastair. “We’ve never seen any types of bugs or issues going into production and applications are more robust and easier to develop.”

 

Of course, any software development, whether or not TDD is involved, faces the possibility of under-testing. This is the chance that one or more test cases, if overly limited, may fail to address some functions and so leave them unproven.

 

Triangulation testing

The Access Worldpay team tackle this issue by using more tests to triangulate their code. A simple example is an addition. Engineers would start by writing a test to give a specific, expected and minimal solution (e.g. 2+2=4) and then hard-code the response to be that solution. They would then triangulate this code by designing another test for the same code. The second test would have slightly different inputs, expected to produce slightly different outputs (e.g. 3+3=6).

 

To make the code pass the second test, they make very simple changes that may, initially, be architecturally unsound. Once the test has been passed, however, the engineers can refactor the code to ripple throughout the software, and then test again. “This looks better from an architectural point of view and you still have the tests showing you that you haven’t broken the code,” says Alastair. Further triangulation testing can then identify other functions that remain unconfirmed.

 

First principles last

Ultimately, the team has found that using TDD encourages them to clarify their thinking and go back to first principles, says Ignas. “The test is the very first component – it gives us the chance to put software that hasn’t yet been written through its paces,” he says. “It allows us to think about the interface and to consider the most convenient and comfortable way to use each component. Indirectly, TDD drives the user experience.”

 

 

Further reading:

  1. General articles on the TDD cycle and rule
    1. The cycles of TDD
    2. Test-driven Development
  2. More specific information on triangulation
    1. Getting Stuck While Doing TDD. Part 3: Triangulation to the Rescue!
    2. The Two Main Techniques in Test-Driven development, part 2
  3.  An overview of some research on TDD practices
    1. The Evidence For TDD

It’s almost a parallel universe. Although part of a global organization with vast reach and huge responsibilities, Access Worldpay remains a small, autonomous unit with the freedom to choose its own working principles and methods. Not only can it adopt best practices, but it can also hack these as necessary to meet its needs. Co-lead Build Chapter, Pat Bateman explains how his team’s approach to QA demonstrates its independent, entrepreneurial spirit. 

 

The starting point, he says, are the objectives. Access Worldpay is expected to turn work around fast and to a consistently high standard. “Predictability is one of the big things here. We want to get stuff out of the door really quickly and if there’s no predictability, then the business has a difficult time working with a customer.”

 

Goodbye Waterfall

Such imperatives immediately made the team determined to streamline its working processes. Quality assurance (QA) was a prime candidate for reform. Standard practice separated the QA function from software development. “They were almost two different organizations,” says Pat. “Software developers would write the code; when it was finished, they’d give the application to the test department for validation.”

 

This approach made the interplay between QA and development slow and inflexible. The long feedback cycles in the Waterfall approach to software development also made it expensive. “You’d have these massive cycles to find out something was wrong and the expense of going back and fixing the issue was immense,” Pat says. “And often what you thought you were building, in terms of set requirements, had changed.”

 

Improving Agile

The shorter cycles within the Agile approach helped a little, but not enough, so the team explored further refinements. “Even in Agile, the QA function remained similar to the old methodology of ‘test after’,” says Pat. “What we’ve discovered is that you can make more change the earlier in the product’s life-cycle you go.”

 

This is ‘shift-left’: moving the quality assurance to the left – to the start of the cycle. It means that QAs can work alongside the product owner and the developer to help ensure that the requirement is correct and agree on the acceptance criteria. “This makes our whole life-cycle more efficient because you’ve done much more detection of fault or quality at the beginning of the requirement description,” says Pat. “So by the time the developer starts coding, they’re going to find fewer problems with the requirement.”

 

Expanding the role

The QA function also extends to exploratory testing. “QAs come up with extra hypotheses, also at the beginning, thinking about the other scenarios we haven’t documented,” says Pat. “They’ll ask ‘does it work in this situation?’ and they may find some edge cases we hadn’t thought about, so they’re coming up with some requirements we’d missed.”

 

And, name aside, shift-left does not confine QAs to the start of the cycle. They still perform their traditional role at the other end, confirming that the software engineers have met the requirement and fulfilled the acceptance criteria. In practice, therefore, QAs are now available throughout the cycle, helping software engineers as needed to ensure that they are interpreting requirements and acceptance criteria correctly. “The QA becomes a more important person in the delivery squad,” says Pat: “They’re constantly being used.”

 

Widening the search

Although shift-left has improved the team’s productivity, the shake-up it involves can make recruitment somewhat tricky. For example, software developers are now expected to automate all their tests, whereas beforehand they shared that responsibility. And Pat recognizes that traditional QAs find shift-left to be “a difficult transition.” He continues: “We are essentially asking them to change their job – to move much more to a product view of the world. It’s very difficult to find people who understand it thoroughly.”

 

To mitigate this challenge, new recruits receive “lots of support on the job,” he says. Access Worldpay bring in QAs with shift-left experience to help new colleagues at the initial, refinement stage – “they help them go through exemplar requirements and acceptance criteria, and we iterate this to keep helping them improve.” QAs and product owners also have a two-day workshop, where external experts go through the whole process and teach them how to find out whether what requirements are viable.

 

“A bigger impact”

Pat is convinced that this extra effort is very worthwhile, not least for QAs themselves. “Traditionally, the QA function has been at the wrong end of the process,” he says. “You can feel like you’re an afterthought, pushed into very tight timelines because earlier parts of the process have run over, so you’re just sat there, checking stuff and filing bugs without any feel of the process.” By contrast, he says, shift-left “places you at the front, with a bigger impact on the product definition; it makes you one of the most crucial people within the product you’re trying to deliver. For QAs right now, this is an exciting time.”

dayo

Access Worldpay people

Posted by dayo Jul 16, 2019

Access Worldpay is our new set of APIs that is fast, supports simple integrations with fault-tolerant, micro, and scalable services. Our developers have created a set of APIs that are readable by humans and machines, thanks to a simple JSON schema. And with Hypermedia, our APIs simplify complex payment journeys for our customers. Learn more about our APIs here.

 

Access Worldpay is a project run by developers, for developers. At the center are smart, spirited and supportive people.

 

What's behind the doors of Access Worldpay?

 

The project kicked off in 2016 from our London and Cambridge offices. The vision? Creating an easy-to-use platform, powered by our engineers.

 

In 2018, Worldpay and Vantiv became one organization, and the doors opened for collaborations of many different teams across the ocean. Our colleagues in the US had been working on microservices that offered an excellent opportunity when combined with our Access Worldpay product. This resulted in a unique and inclusive way of working together.

 

Our engineering squads are responsible for the design, build, release and operation of our APIs and services. This allows for full end-to-end control of the product but also gives people opportunities to grow as teams and individuals. Squads are autonomous and accountable for progress, which makes the project highly flexible.

 

Teams are working on an API set that is not only the industry standard but also uses a full REST maturity model. Our aim is to build a quality service, guaranteeing 100 percent uptime. Living by the principles such as: “If it’s not tested, it’s broken”, our approach to testing and “Requirements before solutions” means that our APIs and services are quality-assured throughout the development lifecycle.

 

What’s coming next?

 

We want you to meet and get to know the people behind Access Worldpay. In the coming weeks, we will be publishing a number of articles. This will include interviews relating to method, processes, and principles we use in and out of development. You can expect to read about topics such as Test-Driven Development (TDD)our approach to Shift-left in QAGrowing in Breath and Depth and many more, stay tuned.

 

 

We polled our twitter audiences to see what they knew about PSD2. Results were mixed!

 

As payment developers and API programmers, you face pressure to meet today’s consumer expectations to offer digital payment solutions. It is also critical to understand all the current rules that govern the use of their application or software in a geographical area.

 

For example, the Payment Services Directive (PSD) has a significant impact on all payment developers in the European Union (EU). This EU regulation has yet to reach other parts of the world, but the revolutionary changes it brings may signal similar legislation in other parts of the world where consumers want digital payment solutions.

 

The latest version of the regulation, known as Revised Payment Services Directive (PSD2), has launched to address the online payment process. If you are not already familiar with this new directive, now is the time to understand the changes and the impact they have on payment processes and platforms.

 

While the common response to these changes has been an ad-hoc approach to plugging in solutions to address the requirements, this latest directive may call for a more dramatic makeover to digital payment platforms.

 

Let’s cover PSD2, its purpose, and the identifiable challenges and opportunities that result from this regulatory environment.

 

What is PSD2?

 

The European Union created PSD2 as the second Payment Services Directive to transform the payments industry so that it aligns with the digital environment that consumers and businesses use. EU organizations had to adopt new regulations by the end of 2018.

 

As a set of standards, PSD2 establishes guidelines for how to pay and accept payments online. It also determines the process for sharing and viewing information related the online payment process.

 

Key Changes Since PSD1

 

The key changes from the first directive include access to bank information. Before the new directive, banks had a monopoly on their users’ data. With PSD2, merchants like Amazon can get bank account data from a user’s bank with their permission. This allows a more direct payment process rather than having to bring in another party like PayPal or a credit card provider.

 

Also, consumers can allow Account Information Service Providers Payment Initiation Service Providers (PISPs) to put all their different account information in one place. From there, they can get a dashboard view of all accounts or make payments from multiple banks within one platform. This drives greater control and convenience for consumers.

 

Another change involves stronger identity checks for online purchases. All the changes together create an online payment environment that gives consumers more payment choices, protection, and control.

 

A Challenge for Developers: Strong Customer Authentication

 

While organizations should have already enacted PSD2, one part of the process involves more time. By September 2019, developers should address the challenge of enacting strong customer authentication (SCA).

 

PSD2 defines these transactions as including account access through computers (desktops and laptops) and mobile devices (smartphones and tablets). Strong customer authentication is also necessary for the actual payment authentication process.

 

At least two of three authentication methods must authenticate all these transactions. There are many methods that may fulfill this requirement.

 

First, there can be two devices where one is running the banking/merchant application and the other is providing the authentication. This scenario includes hardware tokens and U2F devices as authentication devices. It would also be possible to have a mobile device and a laptop where the laptop is running the banking/merchant application and the mobile device is providing authentication. However, the challenge here is to be able to have dynamic linking of payment/merchant information sent back to that authentication device.

 

It is also possible to use two apps and one device. This scenario would involve a single device, such as a smartphone, which would have the banking/merchant app and an authentication app like Google Authenticator or a specialty-built authentication app.

 

Another scenario is to use one app and one device. With this scenario, there would be a mobile banking app that also provides authentication capability that you accessed through a smartphone.

 

The last scenario is Out-of-Band (OOB) Authentication. A mobile phone number receives a SMS that a SIM card has secured. In this case, the mobile device would serve as the second factor. Consumers know and trust this method already because it is easy and convenient.

 

However, the question is: How do institutions provide a frictionless experience when SCA can create friction?

 

Opportunities with Machine Learning and Artificial Intelligence

 

One answer is machine learning, which can address the dual needs of increased security and a better customer experience. PSD2 allows for SCA exemptions for Payment Service Providers (PSPs) that have incorporated machine learning or another type of analytics. Both types of tools have reduced fraud rates.

 

Machine learning platforms combine artificial intelligence technology and risk management tools designed for fraud detection. The advanced analytics platforms and tools can develop and manage high volumes of behavioral data entity profiles and then continue to learn as they collect more data.

 

The platforms can also make real-time, informed decisions from the available data. In this way, they can keep customer accounts secure from data breaches and account takeovers. Because of the speed that this machine learning capability delivers in terms of decision-making, there is minimal friction in the payment process. With fast, yet highly secure, transactions, customers enjoy their experience much more than the earlier process.

 

What’s Next?

 

PSD2 is now in use. Legacy systems no longer work in terms of security or customer experience. Rather than suffering with the same issues as many banks and other payment service providers, the emergence of new regulations like PSD2 signal it is time to invest in developing new payment platforms with this recent technology.

 

However, through the ability to provide additional financial services, reduced fees, and enhanced customer experiences, you’ll be able to reach, engage, and retain more customers while raising security levels and maintaining compliance.

 

If you are ready to learn more and enact a comprehensive change to your digital payment platform, please download Worldpay’s PSD2 eBook. It supplies a wealth of information on the benefits and process of addressing all PSD2 requirements.

 Gaming and Payments: Trends, Adoption, and Technology

 

With a mix of opportunities and challenges on the horizon, the mobile and online gaming industry is continuing to evolve in response to an ever-changing regulatory environment. Other considerations include tech advancements in gaming and audiences with diverse, shifting expectations about their gaming experiences.

 

The continued consolidation among gaming industry companies is in response to the ongoing pressure to maintain a competitive advantage through spending considerable resources. To identify how to stand out in this complex gaming environment, many gaming companies are exploring ways to enhance the user experience, including payments. The payment component is critical to achieving a new level of seamless convenience.

 

That’s why Worldpay has put together a global gaming and payments report, which includes a survey of 16 countries for an international view of integrated payments within mobile and online gaming applications.

 

The Gaming Market’s Impact on You

 

U.S. gaming markets that are set to experience significant growth this year include state lottery gaming, casino and resort gaming, sports and eSports betting, and online gaming.

 

Each of these U.S. gaming markets are prime examples of creating more transactional velocity and brand affinity through omni-channel gaming offerings. In each of these gaming markets, players are looking at how to expand their physical, mobile, and online opportunities, while maintaining and growing their customers across all channels.

 

Within these gaming markets, payment trends are critical to watch as they reflect a larger transition to how consumers expect to pay. For example, eWallet will grow from 20 percent of gaming payments in 2018 to 33 percent in 2022. Meanwhile, credit cards will decrease from 34 percent of gaming payments in 2018 to 27 percent in 2022, while debit card gaming payments will remain the same at 19 percent now and through 2022.

 

Drivers Behind Changes in Gaming and Payments

 

The drivers of today’s gaming and payments trends are the same changes occurring in the larger payment landscape. Two of these drivers include the Now Economy and millennial audiences.

 

The Now Economy has completely changed customer expectations. When businesses began to enable the ability to spend money anytime, anywhere, consumers responded in droves to companies that could do business whenever and wherever the customer had an internet connection and money to spend. This immediacy for payments is critical in an industry like gaming where timing is everything when placing a bet, as well as receiving game winnings.

 

That means gaming operators need to have payment processes that are seamless by removing bad friction that slows transactions and could hurt the betting and the gaming experience. Even if these gaming customers want immediate payment capability, they don’t want to hedge their bets on an unsecured process that does not use tools like user authentication.

 

millennial trends in gaming

 

Second, the millennial demographic is driving many of the changes in the gaming industry. As they become a greater force as a gaming customer segment, millennials are applying the same expectations as they do to other customer experiences like with the retail environment. Those expectations involve personalized gaming experiences with payment options that align with the convenience level they receive in other aspects of their lives.

 

Growing up in a digital environment where information is readily accessible, millennials have amassed a large amount of knowledge related to anything they engage with, including gaming. In fact, they know more about odds, games, and gaming providers compared to other customer segments. If they think the odds aren’t in their favor with a particular game like slots, then they will opt for a more skills-based game with better odds. And, if a gaming provider doesn’t meet their expectations, millennial users will switch to one of many other available gaming apps and providers.

 

To address player expectations around personalization, a gaming provider has to know each player’s preference. With more players opting to use mobile applications, it’s critical to offer fast, secure payment options. With eWallets, a gaming provider can leverage multiple layers of security, such as encryption, tokenization, and device authentication, while keeping payments seamless

 

The Role of the Developer in Gaming and Payments

 

Developers can address these trends by making the payment process “disappear” while also offering these alternative payment methods like eWallets that players use in other aspects of their lives.

 

To offer a personalized experience, developers are an integral part of creating a payment acceptance strategy that includes numerous payment methods -- credit and debit cards, direct debit, and mobile wallets -- and many currencies to reach players beyond U.S. borders.

 

Also, developers can help enable fast payments and payouts. From placing a bet to collecting winnings, an exceptional gaming experience involves speed and access. For example, Visa Direct enables FastAccess Funding, which delivers real-time (under 30 minutes) payments compared to standard payout times of between two and five days.

                                                                                                                                             With 59 percent of Mobile Payment Journey participants stating they would switch payment methods if it means a faster payout, we expect rapid player adoption of FastAccess Funding.

 

A New Era

 

Evolving player expectations, advancing technology, and changing regulations have led to a new era for payments and gaming. Players have unparalleled freedom and flexibility to play and pay in the most convenient way.

 

Offering a seamless payment process that integrates traditional and digital methods heightens the gaming experience and enhances customer loyalty. Worldpay will address the inevitable changes in gaming and payments as well as support your efforts to meet your customers’ expectations.

 

To learn more about the state of gaming and payment trends, download your copy of our new report here: https://www.worldpay.com/global/insight/articles/2019-02/global-gaming-payments-report.

In an increasingly complex environment of payments, we offer a wider range of tools and platforms to help you meet your payment integration objectives. In addition to our other payment solutions, we offer MercuryPay. Here’s what it does for your payment processing needs and how to get started.

 

What is MercuryPay?

 

MercuryPay is a highly scalable payment processing platform. To ensure your application integrates with this platform, you get access to the MercuryPay Integration Suite, which is a comprehensive set of integration methods, tools, and services. This suite’s integration capabilities help minimize the complexity involved in ensuring PA-DSS payment compliance and facilitates EMV card brand certifications.

 

As a flexible platform, MercuryPay offers multiple integration approaches, so you can find the one that fits your business type, target market, payment integration method, and operating system. You can also choose an approach that aligns with specific requirements for security measures.

 

The Benefits of Using MercuryPay

 

In addition to the ability to address numerous compliance issues related to payments and the customization features, there are other reasons why it’s beneficial to consider MercuryPay.

 

getting started with mercurypay

 

MercuryPay supports many industries and verticals, including retail and eCommerce, restaurant and lodging, automotive, healthcare, warehousing, and service-oriented businesses.

 

There are numerous toolkits available to you to create in-store, mobile, and eCommerce applications for a wide range of payment types that you can use in your business. Built on industry standards, there are many payment middleware solutions we offer that are available for testing in an integrated sandbox with simulators.

 

Here are some your options:

  • The dsiPDCX with the dsiEMVUS solution provides merchants with feature-rich payment options that use tokenization and end-to-end encryption for enhanced security. You can easily integrate additional hardware and features as well as provide EMV support for contact and contactless transactions. This payment middleware solution also allows for all types of payment acceptance, such as credit cards, PIN debit cards, EBT, FSA, and more.

 

  • Combining the reliability of Datacap Systems with the platform performance of MercuryPay, TranCloud is the ideal choice if you need to develop a payment integration process for accepting EMV-ready payments. Its payment and hardware hub can adapt to meet the needs of most point-of-sale (POS) providers. This particular payment middleware solution is optimized for tablet and browser-based applications that use HTTP POST in XML or JSON format.

 

  • HostedCheckout supports manual transactions for eCommerce by handling sensitive credit card data. Whether it’s from a merchant’s website, mobile device, or a POS system, online payment transactions are seamlessly handled by this hosted solution.

 

Getting Started with MercuryPay

 

To start enjoying the benefits offered by MercuryPay, your first step is to create a test account.  We have a range of production-simulated accounts that you can use to code, test, and certify your payment integration with the MercuryPay Processing Platform.

 

You’ll start with creating a test account by configuring the test server addresses that corresponds to your payment integration method.

 

Then, select a test MerchantID that fits your supported functionality. MerchantIDs are configured with specific processing functionality, such as E2E, Tokenization, both E2E and Tokenization, or neither.  

 

certification network server addresses

test merchant IDs

The test accounts listed above are for general testing and available for use. If you are testing multiple products or are ready to certify your payment integration process, we can set-up personalized accounts for further validation.

 

You can also find information on Worldpay Integrated Payments Test Cards for card-present transaction testing.  Contact certification@vantiv.com if you want to get test cards and test equipment.

 

Additional Support Available

 

As with all of our products for developers, we have an array of support resources that can provide help with MercuryPay and your payment integration work.

 

This includes asking others in our developer community here: https://developer.vantiv.com/community/help-and-getting-started

 

Of course, we would also like to hear from you so you can reach out to us here: https://developer.vantiv.com/community/help-and-getting-started/main-contact-us

 

Learn More About MercuryPay

 

Our document library for developers offers extensive information on MercuryPay and other payment integration platforms and tools. Check out the MercuryPay platform here: https://developer.vantiv.com/docs/DOC-1252.

The state of crypto payment processing

 

By now, you've probably heard all about cryptocurrency, Bitcoin and Blockchain. It’s been a decade since Bitcoin sprang into existence, and Bitcoin paved the way for thousands of other cryptocurrencies (altcoins, in crypto slang). Amid all the cryptocurrency hype, it can be hard to keep track of what is actually happening in the strand of the cryptocurrency ecosystem that is perhaps most important to crypto's long-term survival: payment processing.

 

That's why developers may find themselves asking questions like these: How easy is it to set up an app to start accepting payments in Bitcoin or other cryptocurrencies? How many payment processing vendors support crypto? What does the process for integrating crypto payments into an app look like, and is it as easy as setting up payment processing in your app for fiat (i.e., traditional) currency?

 

If you think these questions don't matter, think again. There are a number of reasons for accepting payments from customers in cryptocurrency. Accepting crypto payments helps you reach a larger number of customers, especially in countries where certain types of traditional payment options are not widely supported. Crypto payments can also help to cut down on bank charges for both vendors and customers. And supporting crypto can help apps to stand out in crowded markets, just because of the buzz factor.

 

With this context in mind, this article surveys the state of cryptocurrency payment processing by evaluating available solutions and discussing what remains to be done to make crypto payment easier to integrate into applications.

 

Cryptocurrency Payment Processing Options

 

The payment processing solutions available for processing crypto payments are far outnumbered by those for processing fiat currency. The reason is quite obvious: Bitcoin and other cryptocurrencies are still in their infancy. A lot is left to be done to make crypto mainstream, especially when it comes to transaction times.

 

That said, there are certainly crypto payment processors out there. In no particular order, here are some popular options available to developers who want to integrate crypto payments into their apps.

 

  • Coinbase

Coinbase is a popular choice when it comes to cryptocurrency payment processing. In fact, it is one of the world’s largest Bitcoin exchanges, with some 20 million users and over $150 billion already traded on the platform.

 

Coinbase makes it possible to quickly begin receiving cryptocurrency payments (Bitcoin, Litecoin, Bitcoin Cash, Ethereum) without having to pay any fees to accept crypto. Coinbase offers a variety of payment options. They include e-commerce plugins, libraries (Python, Ruby, Node.js, PHP), and SDKs (Android, iOs, Unity). Coinbase’s options make it a great choice for crypto payment processing for virtually any kind of app.

  

  • BitcoinPay

BitcoinPay makes it easy and inexpensive to start accepting Bitcoin payments. BitcoinPay offers developers several payment processing integration options to cater to any use case: API & Button, mail, point of sale, and e-commerce plugins (WooCommerce, OpenCar, Magento, and PrestaShop). BitcoinPay’s API gives developers “superpowers” by allowing developers to customize the payment process to suit their needs. And e-commerce plugins make it seamless to integrate into an e-commerce platform.

  

  • CoinGate

CoinGate processes Blockchain payments. That means it is not only limited to Bitcoin payments. It supports Litecoin, Ethereum, Dash, Golem, and several other cryptocurrencies. It offers integration options including e-commerce plugins, Bitcoin point of sale, Bitcoin payment API, and payment buttons. In addition, CoinGate charges low fees when withdrawing in fiat currency, such as USD or EUR.

  

  • CoinPayments

CointPayments is yet another cryptocurrency payment gateway that supports payments for Bitcoin and several other popular altcoins. Like the others, it offers e-commerce plugins, for even more e-commerce platforms. And CoinPayments offers many integration options that make payment even more simple: donation buttons, shopping cart button & plugin, invoice builder, API, Instant Payment Notification System (IPN), etc.

 

The cryptocurrency processors we’ve seen so far offer very similar integration options, distinguishing themselves in only a few places, such as the number of supported cryptocurrencies. Setting up your app to accept cryptocurrency payments using any of these solutions is akin to setting up payment processing for fiat currency.

 

What Remains to Be Done for Cryptocurrency Payments

Integrating and accepting cryptocurrency payments in applications is certainly possible, but there is still much to be done to make integration more seamless.

 

One major challenge is keeping cryptocurrency safe. In most cases, crypto transactions are irreversible, meaning that recovering funds from a fraudulent (or even just accidental) transaction is virtually impossible. This challenge requires developers to build extra safeguards into applications to ensure that each crypto transaction is valid before it begins.

 

Equally important is the payment processing time. With fiat payments, payments are processed within a few seconds and reflect in your account immediately. Cryptocurrency, however, takes longer to process, sometimes failing unexpectedly as a result. Certain cryptocurrencies are working to address this challenge, but Bitcoin, which remains the most popular cryptocurrency by far, takes very long to process — sometimes hours. Developers must also think about how to make sure their apps can accommodate very long transaction times, and make sure users remain aware of the state of a transaction until it is fully complete.

 

Final Thoughts

Even with the challenges inherent in cryptocurrencies that impede their widespread adoption, cryptocurrency payment processing, in general, is improving. Remember that the sector is barely a decade old; yet, there’s been so much innovation in a rather short time. Will crypto payment integration catch up with fiat payment integration? Probably, although it will certainly take some time before integrating crypto into your app is as easy as supporting fiat currency transactions using a simple solution like WorldPay's APIs.

 

Check out: Worldpay's Card-to-Crypto Exchange 

zacharyflower

New Trends in IDEs

Posted by zacharyflower May 14, 2019

As advances have been made in the practice of software development, it should come as no surprise that the tools we use to actually develop said software have evolved drastically as well. While everything from language improvements to testing advancements have been seen in recent years, one of the less "sexy," yet most important changes has been to the integrated development environments — more commonly known as IDEs — that developers rely on to actually write their code.

 

Now, don't get me wrong. Some of the most popular IDEs on the market today have been around for literally decades (I'm looking at you, VI), but even the forefathers of our modern-day code editors have received recent updates that more appropriately reflect the current state of software development.

 

new trends in IDEs

 

With this in mind, let’s take a look at some of the exciting changes that have impacted IDEs in the past few years.

 

Integrated Development Environments

 

It's no secret that the world is becoming more connected. As companies and developers alike have embraced the cloud, entirely new industries have been built. A great example of this is cloud-based version control services like GitHub, GitLab, and Bitbucket. Hosting your own source code repository is no longer a requirement for the majority of projects, which has led to more effective project management and collaboration through the additional features offered by these newer cloud-based services. Because of this shift in responsibilities, many IDEs have implemented features that integrate directly with these — and more — services, allowing for an increase in focus and a reduction in context switching when interacting with things like pull/merge requests, issue tickets, and even communication platforms.

 

To Pair (Or Not to Pair)

 

A side benefit of having such hyper-connected development environments is the enablement of remote teams. Organizations that have embraced the concept of pair programming no longer have to expect employees to be in the same room in order to work together. Many IDEs now offer functionality that allow multiple developers to work on the same set of code from entirely separate computers. While there are obvious benefits to this feature to be gained from within the same room, providing an avenue for remote teams to better collaborate is an excellent way to not only encourage remote work, but to embrace it.

 

While a number of IDEs offer support for remote pair programming, a great example in practice is Visual Studio Live Share. Live Share is a great remote collaboration tool within the Visual Studio IDE; however, it takes collaboration a step further by offering additional features like audio calls, group debugging, and even shared servers for privately viewing web applications and databases without exposing them to the Internet.

 

Cloud IDEs

 

Not every IDE lives on one single computer. To better facilitate consistency between development environments, several newer IDEs live entirely in the cloud. While the learning curve here can be a bit steep at first (every developer has a preferred IDE and different settings requirements), the primary advantage to cloud-based IDEs is a drastic reduction in resource requirements. When your development environment lives in the cloud, your working machine requires significantly fewer resources, which can in turn mean significant cost-savings for development machines.

 

While Cloud9 paved the way for cloud-based IDEs, an impressive contender with a free tier and self-hosted option is Codenvy. Recently acquired by Red Hat, Codenvy is a Docker-driven IDE built with developers in mind. A particularly useful feature of Codenvy is their cross-platform IDE support, allowing developers to use the tools that they are most comfortable with while syncing changes back to Codenvy for any additional work needed in the cloud.

 

Plug It In

 

While plugins and add-ons are hardly new, their rate of adoption by the open source community over the past several years has skyrocketed. Companies have started to create official plugins to improve the usability of their developer-focused services, while individual contributors can create much more tightly integrated environments with the services they choose to use. This allows for thinner, more performant IDEs that can be expanded to include only the functionality required by the end-user, rather than the historically robust IDEs that require significantly more resources to run.

 

Between Visual Studio Code and Atom alone — two of the most popular IDEs for web developers — the marketplace for IDE plugins is vast. With countless themes and color schemes, third-party integrations, and support for just about every programming language ever invented, plugins are an excellent way for developers to customize every inch of their IDE to create their perfect working environment.

 

Continuous Improvement and Your IDE

 

All of the above highlight how IDEs have become even better tools for developers in recent years. By way of parting, though, I’d like to emphasize that there remains even more that could be done — and will be. Don’t expect your IDE to stop evolving. Going forward, I suspect we’ll see features like more advanced predictive text suggestions or deeper integrations with external services in IDEs as the tools help developers write code even faster, more accurately and with less fuss.

 

Worldpay's 2018 Global Payments Report offers a comprehensive overview of the ways global consumers pay, from Argentina to Vietnam and everywhere in between. We took a look at 4 high potential emerging eCommerce markets in the 2018 report: India, China, Russia, and Brazil.

 

Worldpay ONE took a look at 4 emerging eCommerce markets: India, China, Russia, and Brazil to provide takeaways for developers looking to take their eCommerce business global. We looked at alternative payments and eWallets, cross-border eCommerce, and changing trends in the largest consumer markets (China and India are growing quickly).

 

Are you ready to expand your eCommerce business into new markets? Discover what tech trends and tech regulations you need to stay on top of with the Worldpay ONE Global Developer Insights report

Our top question (with over 1,000 views!) of the month comes from eegorov on sending a TransactionQuery request: 

 

Check out Evgeniy's question and our answer here. 

 

 

If you ask or answer a question that helps our community members, you're automatically entered into a monthly contest for a $25 Amazon gift card! 

Financial account data is considered to be some of the most important and sensitive data in existence. And in today’s world, it is also among the most commonly requested data on the Internet. Let’s face it — everybody shops online. And online shopping requires merchants to request payment data from the shopper. This presents inherent risks associated with providing financial data using online forms. It is due to these risks that a high importance has been placed on protecting user payment data.

 

what-eProtect-does-to-protect-payments-data

 

So, how can we reduce the risk of compromising account data and ensure a positive experience for users visiting an online store? WorldPay has the solution in the form of eProtect.

 

WorldPay eProtect provides merchants with a solution for card-not-present processing risks, allowing the merchant to protect shopper payment data, and providing application developers with several API solutions that are both secure and easy to implement.

 

This article walks through what eProtect does and how it works.

What is eProtect and how does it protect account data?

 

As mentioned above, WorldPay eProtect is a solution for reducing the risks associated with card-not-present (cnp) payment processing. But you may be wondering exactly how it reduces these risks. WorldPay eProtect assumes the responsibility for protecting payment data through several solutions. These include hosting the fields that hold this payment data, as done through use of the iFrame API, or through calls on form submit to the eProtect JavaScript API that passes the payment information from form fields hosted on the application web server to the eProtect server for processing. In short, through the use of an eProtect API, the transmission of sensitive data by the application web server is rather limited.

 

For our purposes, let’s take a closer look at the eProtect iFrame API. Through the use of this API, the fields that will hold sensitive account data are embedded on the page using an iFrame. This iFrame is hosted by the eProtect server. When the user submits the account data (card number, CVV value, expiration date), this data is submitted to the eProtect server rather than transmitted via your own web server.

This eProtect server is a PCI-compliant environment to ensure data security. The moment eProtect receives the card data, it triggers a cnpAPI call to register a token with the Vault where the account data is securely stored. It is this token that will be used for retrieving account data when the payment is processed. The eProtect server then returns a registration ID to the web page. Finally, when the actual payment has been authorized, the registration ID and payment information is sent to the Vault. The Vault then uses this registration ID to efficiently find the token and card number, and processes the payment securely. This transaction simply returns the previously registered token that can be stored by the client as they would card data. This ensures that no actual account data is stored by the client, significantly reducing the risk of an issue due to compromised user account information.

 

Implementing eProtect from WorldPay

 

One of the most encouraging parts of utilizing eProtect from WorldPay is the ease in which the solution can be implemented in a web application. Sticking with the iFrame API solution that we discussed above, let’s take a look at some sample code where an iFrame running code hosted by the eProtect server is embedded in a payment page in a web application to allow account data to be processed via the secure, PCI-compliant eProtect environment.

 

The first step in implementing the iFrame solution from eProtect is to include the jQuery library. After that, we also need to ensure that we have included the client JavaScript for the eProtect iFrame API. This is done by adding a script tag to download the JS from the following URL:

 

https://request.eprotect.vantivprelive.com/eProtect/js/eProtect-iframe-client.min.js

 

It should be noted that this URL is not for production use. For the sake of this example, I utilized the “pre-live” URL from the eProtect documentation.

 

The final steps from an HTML perspective are as follows. We will need to include the div element representing the iFrame to be embedded on the web page. In the screenshot of the sample code, you can see that it is assigned the ID attribute iFrameElem. This will be important when configuring the iFrame via custom JavaScript. In addition, we need to include form fields for holding attributes of the response from the eProtect service. Hidden fields such as that shown below in the screenshot (input with ID attribute response$paypageRegistrationId) are added to the form to assign values with the JavaScript. And finally, we need to provide ourselves with a spot to write some custom JS for instantiating the iFrame and handling the response. We do so by creating impl.js to properly configure the iFrame.  Finally, we download this custom JS file as represented by the last script tag in the head container of our HTML file.

 

eProtect code 1

 

In the custom JavaScript associated with the example, two important actions need to take place. First, the iFrame needs to be configured so that it can be properly added to the checkout page. Next, the response from the eProtect server must be handled to retrieve what is known as the paypageRegistrationId — the registration ID that will be sent with payment information to the Vault post-authorization to map to the account data and process the payment.

 

In configuring the iFrame, several properties are required. These required properties include the following:

  • paypageId - ID value provided by WorldPay
  • reportGroup - required by cnpAPI for reporting purposes
  • style - Custom CSS for styling the iFrame
  • timeout - Allotted time in milliseconds before the call times out
  • div - ID value of the HTML div where the iFrame is embedded (in our case: iFrameElem)
  • callback - the function to call for handling the response from the eProtect server

 

Please see the screenshot below for the portion of impl.js representing the configuration of the iFrame. Notice the line that instantiates iFrameElem passing the configuration JSON to construct the iFrameElem object.

 

 eProtect 2

 

The next step in the process is to handle the response from eProtect in our callback function. In our particular example, this is the function called iFrameElemCallback. A key element in the callback response is the paypageRegistrationId as that is what will be used by the cnpAPI to locate the associated token and card information in the Vault when processing the actual payment.

 

In the screenshot below, you will see the defined callback function. This is used to check the response code, handle the response data, and submit the form. The snippet below shows the first two steps. The hidden form field for paypageRegistrationId has the value set after we check and find that the call to eProtect has been successful. Other attributes of the response object can be handled in the same manner. This success response is defined by the response code 870, which we check for prior to setting the hidden form field value and submitting the form. Additional response codes and additional information on the response object from the eProtect service can be found in the eProtect online documentation.

 

 eProtect 3

Conclusion

 

Storing payment data that is later compromised is among the worst possible events that can happen to an Internet merchant. It damages the trust necessary for a merchant to be successful. WorldPay eProtect can help in mitigating the risks associated with collecting payment data, ensuring that shoppers have a positive experience and feel comfortable engaging in future transactions.