Skip navigation
All Places > In the News > Blog > 2019 > July
2019

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 two testing environments available: Sandbox and Pre-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.

  

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, common roadblocks include IPs that are not properly identified and are accessing these testing environments. Therefore, they are not white-listed, 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 MIDs.

 

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.