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


183 posts

If you're a developer looking for Worldpay test cards for point of sale testing, you need to know how to obtain information about the appropriate integration processes, interfaces, and workflows.


This article covers the procedures for finding the appropriate support from Worldpay's Business Development team that you will need to acquire physical cards or e-commerce card numbers for performing test transactions.


Following the correct workflow is essential when starting a Worldpay payment implementation, and — as part of that— requesting test cards or test card numbers.


This process ensures we can give you the required information and support so that your application works as intended.


Integration for New ISVs

The Worldpay One Network Experience is a developer network for payment professionals. It is a comprehensive and accessible developer program that makes it easier to integrate payments into any application. You can find all the tools and resources you need in one place at the Worldpay ONE portal.


If you are a new vendor, start by initiating a conversation with Business Development and working with one of our Developer Integration (DI) consultants. Start by submitting the Worldpay partner contact form. The Business Development team will guide you through the rest of the process.


Integration for Existing ISVs

If your organization is already a Worldpay vendor, it's still best to get in touch with your Business Development contact, hold a kickoff meeting, and discuss requirements.


Even if you're working exclusively with card-not-present transactions (e-commerce), you still need to go through the Business Development and kickoff meeting process.


Worldpay's Business Development team will help you create long-term value for your organization, based on your market, customers, and relationships. The Business Development team works to understand how forces and variables within your business interact to create opportunities for your business’s growth. Worldpay's Business Development team will be focused not only on helping you grow revenues but also on understanding your market and helping you find the best payment solutions.


Express Interface Certification

The Express Certification Interface includes a set of requirements that an integrator must meet to obtain a certification for transaction workflows. These transactions may be card-present (such as retail), and card-not-present (as in direct marketing and e-commerce).


Documentation is available on Worldpay ONE, and the Developer Integration team ( will provide the necessary information to allow you to complete the certification process:

  • Set up a Test Account to sign up for a free production-simulated test account to use during the integration process. This sign-up will grant you access to the API so that you can connect your solution to the Express Processing Interface.
  • Test Your Integration. The Worldpay Integrated Payments certification environment allows you to code, test, and evaluate your integration into the Express Interface, simulating a production environment.
  • Complete and submit the Request for Certification (R.F.C.) and Scenarios Document. This provides the Certification team with details about your software or hardware. If needed, Worldpay Integrated Payments will provide any additional certification documentation, test scripts, receipt requirements, and test cards.
  • Certification Testing and Review. In this phase, the integration team will provide you with all the necessary testing scripts. The team will also review test transactions and requests, advising you on any recommended changes to your integration and application.
  • Express Certification Letter. After you complete all requirements, you will receive an official certification detailing which functionalities implemented in your solution have been approved for use on the Express Interface.


Hosted Payments

The Hosted Payments solution supports three different processing flows:


  • Single Sale Transaction Flow
  • Single Sale Transaction with Embedded Browser Control Flow
  • Store Card Data in PASS to Tokenize Flow


A typical transaction using the Single Sale Transaction Flow will follow these steps:

  • Your app submits the sale data to Worldpay's Express Interface.
  • Express returns a transaction GUID if the request was successful.
  • Your app performs a redirect (full, popup, or iFrame) to Worldpay's Hosted Payments URL and appends the Transaction Setup ID to the end of that URL.
  • The end-user inputs the card into the Hosted Payments page/popup and clicks Submit.
  • Express redirects the details to the return URL you initially provided.
  • Your app receives the URL and parses out the response details.


The Single Sale Transaction with Embedded Browser Control Flow is similar to the Single Sale Transaction Flow but allows hosting the user interface in an embedded browser control.


The Store Card Data Flow is similar to the Single Sale Transaction Flow, but instead of sending a card number, your app stores the Payment Account ID token provided by Express and subsequently submits the sale using this token.


Card Issuance for the EMV Standard

EMV is a specification standard for smart card payments that was created in collaboration with leading card brands. EMV has replaced earlier information storage based on magnetic stripes, with the goal to standardize the "conversation" between cards and payment terminals.


Worldpay IP provides you with several tools to assist you during your coding, testing, and review phases. These include robust testing platforms, merchant IDs, test cards, and reports that let you review your transactions and results.


Your consultant will provide you with a set of EMV and magnetic stripe test cards along with a detailed, personalized test plan. Our test plans contain test cases that cover all of the transactions you plan to support. Our test plans are great learning tools for fine-tuning your payments knowledge and Worldpay-specific integration methods.


The MercuryPay Payments Platform

MercuryPay is Worldpay's award-winning platform for fast, reliable, and secure payment processing. You can rely on MercuryPay’s state-of-the-art processing engine — It meets the highest industry standards for security, robustness, and card brand compliance.


If your company is a member of the MercuryPay platform, arrangements will be made for Integration Planning, which includes a few steps.


Your company will be assigned a MercuryPay Developer Implementations Consultant during the integration with Worldpay IP. First, Worldpay IP will arrange a kickoff call with your team, which includes:


  • Deciding which features and functionalities you wish to implement.
  • Understanding the specific requirements for your target business.
  • Deciding which integration method best fits your POS architecture.
  • Reviewing MercuryPay integration specifications, data, and error handling.
  • Reviewing payment industry rules and regulations.


After the kickoff, you should do regular checks with your consultant to stay on track throughout the integration process.



Providing test cards for point-of-sale testing is just part of Worldpay's customer integration process.


Contacting Worldpay Business Development for proper guidance is key to a successful integration process, whether your company is a new ISV or an existing vendor starting a new integration.


You can contact the Developer Integrations Team by email


Useful Links

The links below provide additional in-depth information to guide you through a successful integration process:


Worldpay partner contact form


Express Certification Overview


Hosted Payments Overview


MercuryPay Platform Integration Guide

Who are the developers in our community? What got them into coding in the first place? How do they like to learn and troubleshoot? We asked 100 of our developer partners about their education, career path, coding preferences, and more. Here’s what we discovered.


Read the complete study.

Developers who code for payments are seasoned

45% of our developers have been coding professionally for a long, long time—over 10 years. Over 1 in 4 developers have been coding professionally for 5-10 years, and nearly 1 in 5 developers have been coding at work for 1 year or less.


Most began coding as kids

45% of the developers surveyed began coding before they were 17. 1 in 4 learned to code as young adults, from age 18-22.

So you want to start developing a payment solution using Worldpay from FIS technology. It's easy, right? You’ll simply google it, pick the correct APIs, and start coding. Developers trust that they know their craft well and love to start creating new solutions right away. Programming is fun, so who can blame them?


Well, it's easy once you get to the development part. But soon you realize you're in trouble: there are plenty of methods and parameters to investigate, technical and business terms you don't clearly understand, and classes that look similar but are designed for different payment flows.


When it comes to payment solutions, there are numerous issues at stake that programmers can't solve alone. Such an undertaking requires teamwork to plan and execute each phase properly.


Before you start coding, there are some procedures you need to follow. And we are committed to ensuring your experience with Worldpay from FIS payment technology is as smooth and secure as possible.


Even if you’re already a Worldpay from FIS partner, it is important to get your new project off to the right start. We'll cover the steps we recommend that every vendor follow when starting a new engagement with Worldpay from FIS.


Getting Off to a Good Start


Developers love to jump right in and start building. But suppose you spend hours developing 10 payment methods and, at the end of the week, you find out that only three of them are needed for your business.


If you start coding without proper business and technical support, chances are you'll end up putting more time and effort into your solution than needed. But this is nothing compared to the complications that lurk beyond coding. Let's dive in and discuss some major concerns that arise when implementing payment integration.


  • Since the vast majority of worldwide purchases are made using card-based numbers and eWallets, preventing payment security issues is a top priority for anyone doing business online.
  • If you’re developing a "card-not-present" solution, such as e-commerce, you should be aware of risks associated with online transactions. Reducing merchant exposure to fraudulent misuse and fraud-related chargebacks is a concern when trading online.
  • Entering new global markets can be difficult. Cross-border e-commerce demands knowledge of local markets. A payment partner with expertise on cross-border integration helps bridge those gaps. 

  • Payment gateways offer a variety of payment methods that fit different businesses and different markets. Those options include credit and debit cards, bank transfers, e-Wallets, pre-pay, and post-pay schemes. But given these alternatives, how should you develop a payment solution that best suits your needs, without getting lost in the gateway integration?


A successful payment solution requires sorting out questions that touch many aspects of your business and goes beyond just coding.


Worldpay will make sure you have the right solution and the right tools for your business and your project.


Beginning Your Engagement


Do you already have a relationship with Worldpay? Get in touch with your Worldpay Business Development representative, who’ll point you in the right direction.


The Worldpay Business Development staff consists of seasoned professionals, experienced in building new relationships between solutions provided by Worldpay and businesses like yours.


Worldpay holds the privileged position of partnering with dynamic organizations worldwide. The Worldpay Business Development team is ready to build up a new relationship with your company, focusing on bringing you solutions that provide maximum value to your business.


If you're not yet a customer, reach out to Business Development (BD) to get the project started.

Assessing Your Business


Whether you're starting a first project or just a new project, Business Development will need some information before they can advise you:


  • Make sure you have an idea of your transaction volume and annual revenue before your kick-off call with Developer Integrations (DI).


  • Are you a payment facilitator performing transactions on behalf of merchants? Worldpay PayFac experience provides the tools you need to onboard sub-merchants, collect payments on your schedule, and reduce risk.


  • Are you a value-added reseller (VAR) or an independent software vendor (ISV)? VARs will enjoy innovative technologies designed for fast, secure, and cost-effective processing services. And if you’re an (ISV), Worldpay will help you build your brand and win more business by reducing processing costs and increasing your revenue.


  • Do you have any existing contracts and value-added services (like check-processing) that will not be routed through Worldpay? Working with multiple contracts is a common scenario. Knowing this beforehand is essential so the Business Development team can outline a solution designed with your reality in mind.


  • What hardware will you need us to support? With so many payment terminals to choose from, you should get advice about which one is most suitable for your business. Worldpay will help you by supporting the right equipment, based on your needs, budget, and plans for the future.


What's the Process?


As soon as our team understands your business and project, Business Development will evaluate your plans and set up a meeting with Developer Integrations. The Solutioning team works with Business Development to ensure you're choosing the right APIs and understand what is involved in your solution in terms of architecture, manpower, and so on.


The process starts with the first contact with Business Development and Solution Architects to evaluate your plans. Next, they’ll set up a kick-off meeting with Business Development, Developer Integrations, and stakeholders on your team to discuss project planning and requirements.


The foundation of any successful integration project is people. We believe strongly in having the right people at the table to discuss the project. The optimal mix will comprise business decision-makers and technical implementers, including CEO/CTO, lead engineer or primary developer, and project coordinator.


Details and requirements decided previously have to be reviewed and followed correctly for successful integration. Kick-off calls will be highly technical, so ask all the questions so Developer Integrations consultants can troubleshoot and anticipate problems.


The more info about your business plans and your current workflow you bring to the table, the easier the planning and execution of the next phases will be.


What to Expect From the Worldpay from FIS Team


Our Developer Integrations team has worked with many types of clients over the years, giving us accumulated experience and technical skills. You can expect excellence from our team!


Despite the technical nature of the Developer Integrations staff, they’ll be working with your business in mind because they’re involved in your integration project from the start. We'll be doing our best to deliver an integration that meets your business needs.


First, we’ll discuss the scope of the work—and decide who’ll be responsible for which parts of the project, schedules, and phases.


Next, we'll review the certification procedures. We take compliance seriously, and you should, too. For example, by acquiring the PCI (Payment Card Industry) certification, your business is acknowledged as a member of a secure network of commerce partners. We'll be discussing how to implement the PCI requirements, phases, and levels of compliance. Plus, we also have integrations that can help keep your business out of scope, meaning a big portion of the potential liability lies on our shoulders.


What about hardware? Obviously, POS systems demand the use of devices. Depending on the nature of your business, the equipment can vary widely. We'll advise you on what hardware to purchase.


Then we'll discuss milestones and project timelines. Before the payment solution goes live, it should go through a testing phase. The Developer Integrations team will provide you with credentials for the sandbox environment, where you can test your code end-to-end.


Remember: Developer Integrations is your dedicated development contact. Team members speak the same technical language as your developers and will be ready to help you throughout the implementation.

Next Steps


Ready to get started? Contact your Worldpay from FIS Business Development representative, or use the Get Started page to make a request.


For more information about Worldpay from FIS, check out the big picture from our resources: "Developers, developers, developers." After all, we know people like you are behind successful projects. Access the North America Merchant Solutions Developer Community and join the network to get articles, forums, and docs related to Worldpay integration development.


Need more detailed information on development? We're here to help!


As we kick off a new year, what does your payment roadmap look like? Are you looking to add a new feature to your payment stack or are you building out your PayFac strategy? Perhaps you are poised to begin your integration to Worldpay from FIS in North America. 


There is so much to consider when it comes to integrating payments into your point of sale [ Express API ] or hosted payments page. If you have questions about PCI Compliance or you are ready to talk to a payments professional we have the answers. If you want to learn more about integrated payments first, perhaps start here


Our solutions range from integrations for small businesses all the way to the enterprise.

Payment development can be daunting, and having someone to help you guide you through your journey is what Worldpay from FIS is all about. 

This community is geared towards North America Merchant Solutions, so if you are looking for eCommerce API documentation and are outside of the US, then check out our eCommerce API Portal


The payments landscape is ever-changing, integrations are becoming more layered, there are many value-added services that can be added; keeping up with complex data is now the norm. Worldpay from FIS have multiple solutions to keep you out-of-scope as well as experts to help you with Level II and Level III processing. 


So I ask you again, what does your 2020 look like in terms of adding or enhancing payments for your customers? Let us know, reach out to our team or add in a comment below. Happy New Year! Here's to an amazing year in payments! 

Learn how companies need to adapt to be competitive in this Payments Journal article and grab the most recent white paper from FIS on Consumer Preferences. 


Consumer Preferences Are Shifting. Here’s How to Keep Up. | PaymentsJournal 

 Workplace distractions are an indigestible all-you-can-eat buffet. It starts with the sugary snacks, like Twitter, Instagram, Amazon or eBay. They’re garnished with carb-heavy coffee runs, lunch options, and office gossip, along with some protein: side-projects, meetings and Slack. You still think you’re fine until finally, cruelly, the server piles on a great fatberg of emails that block you up and slow you down.


When you’re tasked with building a brand-new, cutting-edge payments platform like Access Worldpay, it’s hardly ideal. So it’s no wonder that the leadership team chose to remove as many distractions as possible from the people tasked with delivering it all.


Less gets more

Perhaps counterintuitively, they decided the best way to increase teams’ productivity was to reduce their time together. For context, Access Worldpay uses the Agile approach to software development. This maximises speed and flexibility via small teams working in 10 day ‘sprints’, during which they plan, build and release software.


Careful examination of these sprints revealed that their productivity was frequently diluted. “Oftentimes you’ve got lots of other things cutting in and distracting teams so typically people can only contribute 85-90% of their time to sprints,” says Sean Simmie, Co-Lead (Build Chapter).  


Demarcation brings protection

The solution was to “segregate those distractions as much as possible” by reducing the sprint length from 10 to 8.5 days. Reserving sprint time solely for sprint work “protects” the teams so that they can focus properly on the task at hand. It also allows the remaining 1.5 days to be reserved for issues that are equally important but not sprint-specific.


Most of this time – a full day – is invested in ‘chapter time’. But what are chapters? “With Agile delivery, you take all the people you need to produce the outcome you want and put them in a team,” Sean explains. “If you need more than one team, generally you’ll want them all to be aligned so you don’t duplicate effort. That’s where chapters come in.”


‘People over process’

Access Worldpay has several chapters, all working to standardise best practice, share experience and expertise, and establish common principles and practices. “The chapter day is about the cross-cutting concerns and different chapters have different areas to align on,” says Sean. “For example, the build chapter has done a huge amount to standardise our approach to software engineering.”


Moreover, Agile delivery emphasises ‘people over process’, so “empowering people to contribute and make decisions is important,” says Sean. Investing in a specific, demarcated chapter day makes it “a distinct, protected thing that gives our people the opportunity to contribute rather than the leadership team simply micro-managing things.” He continues: “If we don’t give people real time and space to do this, it doesn’t happen – we’ve seen that time and time again.”



Now it gets personal

The final half day is reserved for personal development. “Again, it’s people over process,” says Sean: “We take our commitment to our people seriously because they’re our success, our biggest strength.” Behind this commitment lies a clear business case, he explains: “We need full-stack developers that can handle infrastructure, the front end and everything in-between, so we’re looking for people to grow in breadth and depth, to constantly improve on the engineering side.”


Individuals discuss their career aspirations and personal development plans with their manager. These can involve improving soft skills, such as presentations, or learning new disciplines. “One engineer uses his half-day to address and work on UX-related topics,” Sean says: “He set up a mentoring programme in which he would discuss, collaborate and review his work with a member of the UX team.”


Libraries and lunches

Investment in personal development also extends to extra time for conferences or essential training, such as Scala or Cassandra. It also happens less formally on the desk with line managers providing specific support and continuing performance management, and at regular ‘lunch and learn’ sessions. “It’s a chance for people to come together as a community,” says Sean. “Three of our engineers are the lunch and learn co-ordinators so instead of being management-led, it’s a grassroots effort, which is valuable.”


Beyond these lies a universe of courses and libraries online, including Linux Academy and Pluralsight. “We try to offer as much as possible and some people use their time to do certifications themselves,” says Sean. “The key thing is that it has to be something that the individual wants to maximise – if they feel they’re already getting enough from on-the-job experience, that’s fine as well.”


‘Production takes priority’

Although these 1.5 days are protected, they aren’t sacred. “Production takes priority over everything,” says Sean. “We have a duty of care and responsibility to our customers so we can’t have folks taking time out to read from Safari Library if our systems are crashing in production.”


“The thing is, they wouldn’t do that,” adds Ben Haswell, Engineering Lead: “Our teams have ownership and they know it.” It’s a natural consequence of Access Worldpay’s culture of empowerment and, ultimately, it’s the dividend yielded from a sustained investment of time, training and trust.


It's the most magical time of the year for Worldpay's developer community: our annual survey of payments developers is out: 2019 Payments Developer Insights Survey.


Take the survey (it's just 26 questions, and 25 are multiple choice) to enter to win 1 of 3 $200 Netflix gift cards. That's 1 year of a premium subscription!


We'll post the results at the end of October. Is this suspense killing you? Here's last year's report to read: Developer Insights Report 2018.

Faced with a pile of LEGO, any child knows that building something from scratch involves lots of decisions – about who can help, what to build, and whether it can be adapted later on. Those decisions can transform a simple LEGO plane into a sea-plane, jet-plane, biplane or triplane. Enough good decisions could even, one day, create the prototype Megafast UltraCool StarSurfer 2000.


That’s a complicated vehicle, obviously, but it’s nowhere near as knotty as Access Worldpay, which has required decisions of a quantity, complexity, and consequence to make LEGO heads spin. Still, the brief was clear – to build a set of payment services and interfaces that could deliver Worldpay products quicker, more safely, more simply and with better service quality than anyone else. It also had to be easily scalable globally, both in capacity and cost. All told, “a reasonably non-trivial request”, says Simon Welland, Co-Lead of Access Worldpay.


Stating the obvious

Simon and his colleagues began with some “obvious” decisions, starting with the judgment that Access Worldpay had to be “cloud-first”, because the alternatives “simply couldn’t deliver the scalability and speed we needed.”


They also chose to go open-source. Besides using standard tools, such as GitHub and Nexus, they opted for proven open-source software, “because typically it offers the best engineering and innovation, and also the best quality and good value for money,” says Simon. To help ensure a viable supply chain, Access Worldpay decided to invest in key open-source providers and to share any future developments or improvements made by their engineers to open-source projects. 


Autonomy and automation

The imperative for high speed, responsiveness, and service-quality triggered important decisions. “We felt that only very high levels of automation and rigour in our approach would enable us to meet the required pace of change and level of quality of service,” Simon explains: “So we really pushed for investment in automation, in testing and in the use of software agents to have zero defect pipelines.”


Another choice involved fully harnessing “the power of the squad”, says Pat Bateman, Co-Lead (Build Chapter): “The squads are full of incredibly capable people who are at the coal face, living the problems on a daily basis, so we push as much autonomy in their direction as we can.” Reinforcing this, the team’s BRO model (Build, Release, Operate) gives squads responsibility for building and releasing software and then maintaining it too, thereby improving service quality.

 Oludayo Fafiolu, Patrick Bateman, Paul Wright and Simon Welland

First, principles

Since autonomy is about decision-making, success requires clarity – specifically, clear guidelines, principles, and leadership. One founding principle was to leverage individual knowledge and experience through extensive collaboration – for example, helping Worldpay colleagues understand wider applications that may sprout from the team’s decisions, and also discussing experiences informally with developers working for their customers.


Another guiding principle is test-driven development (TDD). “We test everything,” says Simon: “If it’s not tested, it’s broken.” Although TDD is commonplace for software developers, it represents a new frontier in cloud and infrastructure engineering. Consequently, the team’s cloud engineers have had to “rewire their brains to think about things a little differently,” says Paul Wright, Head of Cloud Engineering. “As head, my job has been to ensure people feel comfortable in this journey, understand the challenges and are clear that this is the agreed direction.”


Just-enough, just-in-time

Setting clear guidelines and principles – however challenging – has empowered squads to make the decisions necessary to fulfill the task at hand. “We ask the squads just to try and meet the requirements they’ve been asked to meet and avoid a whole bucket list of hypothetical things that could happen in the future,” Pat says. This helps create a “just-enough, just-in-time, every time” architecture that enables squads to start producing results very quickly.


Effective autonomy also requires clear limits and, therefore, leadership. “You need a strong feedback loop,” Pat says, because some decisions matter more than others. “If they come up with any significant decisions they can bubble them up to the leadership team,” he continues: “If it’s a really important decision we’ll try to make it for the entire team because it can help an awful lot of the other squads who’ll also hit these problems at some point.”


Four-wheel decisions

The leadership team consists of Simon and three others, including Paul and Pat. “It means you’ll have a difference of opinion, which is good,” says Pat. “With a group of three plus Simon, who’s the constant check and decision-maker, you end up making a lot more sensible decisions based on everyone’s collective knowledge and experience and opinion. It feels like a very safe environment as a result.”


Simon adds: “We bring over 100 years of systems leadership experience into the group and we do use that in our decision support.” It also helps them develop the knowledge and skills necessary for squads to use their autonomy to best effect. “We’ve worked hard on supporting our people to grow to the full-stack – which, today, extends from front-end to back-end to infrastructure,” says Simon: “We’re developing those skills in individuals so that, ultimately, we can take our architecture decisions anywhere within our team.” Paul agrees: “That’s what we decided from the start – to build strong, cross-functional teams that know what they’re operating and owning.” Just imagine what they’d make with some LEGO.

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  


And here's in the answer for inquiring minds: triPOS Direct Release Notes - Version 5.17.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!


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


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



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


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.