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

Developer News and Updates

191 posts

At many companies, security is not central to their development lifecycle. They often consider security in their applications as part of the QA process, after their software has been fully developed. As a result, engineers and developers end up working reactively, fixing shipped code, instead of treating security as a primary concern.


Hackers, in contrast, are always lurking behind the dark corners of the web, waiting for companies to make mistakes.


When we talk about payment applications, the obvious concern is regarding sensitive information, both from customers and the company itself. But it can also result in unauthorized transactions, financial loss, and industrial espionage. Underestimating the ingenuity and tenacity of hackers may result in incalculable damage for organizations.


By putting security first, companies can anticipate breaches, fix them, and prevent exploits from attackers.


In this article, we'll talk about payment application security and discuss the security lifecycle, best practices, and technology that enables them.

What is Application Security?

Testing application security involves two main approaches:


  • Static Testing
  • Dynamic Testing


Each of these techniques analyzes different aspects of an app, so they're different, yet complementary to each other.


Static application security testing (SAST) is a type of white-box testing to analyze source code against vulnerabilities. It can help remediate situations where unsafe code may lead to unintended code execution. The application data is analyzed for security weaknesses. SAST tests the internal (rather than functional) structure of the application.


Dynamic Application Security Testing (DAST), in contrast, is executed while a program is in execution. It analyzes the application from the outside in by examining it in runtime to discover security vulnerabilities. For example, DAST can assess a web app's response to simulated attacks, thus identifying vulnerable security points.


Security Vulnerability Categories

Most of the authentication security issues arise when you try to implement your own authentication solution. Just don't. It is tough to get it right, and you may face many pitfalls ahead, such as failing to enforce password policies and missing two-factor authentication.


Prefer open-source frameworks maintained by active communities and frequently patched against possible new vulnerabilities.


Sensitive Information Exposure arises when applications access sensitive data, particularly unencrypted personal information. In this case, an attacker can perform an injection attack to expose confidential information in plain text. Sensitive data in your systems must always be protected by AES and RSA encryption, both at storage and while on transit.


Broken Access Control vulnerability happens when inconsistent access constraints are applied in different places of an application. The "security through obscurity" approach falsely assumes that resources that remain hidden from most users are safe from potential attackers. Access control vulnerabilities may be avoided by protecting data with multiple layers of defense and tightening access to resources through a single mechanism.


Security misconfiguration issues affect network services, application servers, and storage systems. Some examples include error messages revealing sensitive information, unpatched, or outdated services. You can mitigate application misconfiguration by following a consistent configuration process, and reviewing security notes, updates, and patches.


Cross-Site Scripting (XSS) flaws arise when untrusted user input is executed as part of the HTML, or when users can be influenced to interact with malicious links. Attackers can steal credentials, or deliver malware by performing remote code execution on the user's machine. Once this security breach is exploited, attackers can succeed in taking over the victim's account, retrieving web app data, or modifying the content on the web page for malicious purposes.


Components with known vulnerabilities present problems when introduced into an application and run with the same privileges. This vulnerability provides attackers with some of the most feared breaches in the industry, known as Heartbleed and Shellshock. Backdoors in vulnerable components can hand total control of the machine to the attacker.

Best Practices

When application security is carried out as just a tiny part of the testing phase, it means too little thought and effort has been put into creating secure products. Unforeseen vulnerabilities arise and pose an increased threat to private customer data and the probability of data breaches that can be exploited by attackers.


Microsoft helped pioneer some best practices for development teams with the Security Development Lifecycle (SDL). These practices help developers build more secure software by mitigating potential vulnerabilities from the very start of development and at regular points during the development process.


Here's a brief list of SDL best practices:


  • Provide training to ensure everyone follows security best practices.
  • Define security requirements to reflect changes in functionality and to the regulatory and threat landscape.
  • Define metrics and compliance reporting. Also, define acceptable levels of security and assign team accountability.
  • Use threat modeling to identify security vulnerabilities, determine risk, and how to mitigate them.
  • Define standard security design for features to be used by engineers. Imagine an attacker is brute-forcing a password on the user login form on your website. Fortunately, the security design had already helped identify potential breaches at your application login process, which was then patched by the development team. The attacker will now be locked out of your website after a given number of failed login attempts.
  • Define and Use Cryptography Standards to ensure the right solutions are used to protect data.
  • Manage the Security Risk of Using Third-Party Components by keeping an inventory and consistently evaluate reported vulnerabilities. Attackers are happy to hear any announcement of weaknesses within the components your company uses. But thanks to the Secure Software Development Lifecycle (SDLC), your team can follow standardized development procedures, which include upgrading any components to new, secure-patched versions.
  • Enforce the use of only Approved Tools throughout your organization.
  • Perform SAST and DAST tests to verify the security of both static and running code. Hackers can make use of vulnerability SAST and DAST scanning tools to find breaches in your system. By running these tools early at the verification phase as part of the secure SDLC and fixing vulnerabilities, your company will be ahead of potential attackers.
  • Perform penetration testing to uncover potential vulnerabilities resulting from coding errors, system configuration faults, or other operational deployment weaknesses.
  • Establish a Standard Incident Response Process to address new threats that can emerge over time.

Security Tools and Payment-Related Technologies

Developing successful and secure projects depends on changing the mindset of the corporation staff and creating a new culture that puts security first. But it also requires specialized technology and tools. Let's dive into some of the standards tools used these days in payment security:


  • 3D Secure (3DS and 3DS2) are fraud prevention standards that add a layer of security in online payments. These standards help prevent fraudulent payments and ensure that only the rightful card owner makes the online payment. This is done by requiring the cardholder to provide a password, an SMS code, and a temporary PIN. 3DS2 also leverages smartphone biometrics capabilities like fingerprint, voice, or facial features.
  • 3DS Flex and 3DS Flex Premium are advanced 3D Secure products from WorldPay, featuring detection and issuer monitoring by default. 3DS Flex Premium also offers a dedicated 3DS consultant to help you design your security strategy, and advanced reporting to analyze shopper behaviors.


Besides 3DS standards, let's briefly discuss some security concepts applied to different aspects and processes of secure payment solutions:


  • EMV chip cards. This technology helps merchants protect their business against fraud liability of potential counterfeit schemes.
  • Network security. To prevent breaches that compromise sensitive card data, merchants can implement firewalls and segment communication networks.
  • Data security. This technique will make the data worthless if stolen. Encryption and tokenization are EMV strategies for a small merchant looking to invest in a POS technology upgrade.
  • Physical security. Physical access to the POS should always be limited and secure. Card numbers and other customer information must never be written down.


When it comes to security engineering for businesses, there is too much at stake. In this article, we covered many security tools, techniques, and practices, but you can go further. Making good use of information and action, you can always eliminate or mitigate security risks in your operations.


Small businesses are particularly vulnerable to attackers, but the Small Business Guide to Preventing Data Breaches from WorldPay blog shows us how to deal with these threats. This guide examines why data breaches happen, the implications for businesses like yours, and most importantly how to reduce the risks to your business.


3DS Flex from Worldpay helps increase issuer approvals for transactions controlled by laws and regulations while reducing friction at checkout and improving the shopper experience. Get your free consultation or talk with an Enterprise Specialist today:


Worldpay offers superior security for merchants and customers alike, helping to reduce fraud and increase genuine transactions.


Article posted by Andrew Harris.

The term microservices is used fairly frequently when people talk about developing modern software solutions, but what does that actually mean for payment and financial applications? Let's take a broad look at what a microservices architecture is, how to develop applications using this architectural style, and the benefits of developing applications this way.


What are microservices?

When we talk about microservices in application development, we are talking about applications built as a suite of small services. Each service generally contains its own business function, run in its own context, with its own resources.

Microservices typically have the ability to communicate with other services in a loosely coupled way, often over RESTful APIs. This allows developers to implement each service as its own self-contained action, which provides a lot of flexibility and reuse of developed components.

There are a number of principles that are generally adopted when developing microservices for application design and development. Many of these principles are adopted to ensure that systems are robust, supportable, and can be developed quickly.

Let's take a look at these architectural principles.

Organized by business functions

The first key principle of microservices is the organization by business function. This principle allows you to slice up the work into potential services that can be composed together to form a business process. For example, a typical banking application might be broken into some of the following microservices:

  • Check balance
  • Make payment
  • Transfer funds
  • View transactions
  • Authenticate user


One of the important design considerations when using this principle is to ensure that the business function is as generic as possible. For instance, the service "check balance" could be defined as "check savings account balance." However, if you think of this as a service, this would be too limiting and really the only difference between the two would be the account type that can be passed in as a parameter.

Highly maintainable and testable

The next principle is ensuring that the services are maintainable and testable. This principle can be a little hard to understand, but it is primarily based on the concept of your services being relatively small.

Each service should contain a minimal number of steps while still remaining as generic as possible. This allows your service to be easily understandable, making it a lot easier to maintain. It also simplifies the testing required for the service and, coupled with a test-driven development process, also ensures that the service components can be easily tested.

Loosely coupled

Trying to develop services free of dependencies is the most challenging aspect of a microservices architecture. There are a number of ways to achieve loose coupling, and the use of a messaging system that implements a publish/subscribe mechanism provides a good way to achieve this.

Independently deployable

Allowing services to be independently deployable results in a lot of flexibility when deploying new service components, updating existing components, and isolating components.

Owned by a small team

Finally, each service can also be owned by small teams. Rather than multiple large teams owning large applications, finding the team that supports specific functionality is a lot easier with applications composed of small services.

Benefits of adopting a microservices architecture

Developing software using a microservices architecture practice changes the way historic development practices work. This style of development offers a lot of practical benefits when adopted.

Modularity enables a lot of benefits for large scale applications, particularly in finance. Being able to add, remove, or recompose lines of business and business processes by adding, moving, or removing modular services enables a lot of flexibility and responsiveness.

Having a suite of individually scalable services also allows applications to flex with burst workloads in a cost-effective manner. For instance, if bulk payments are generated or large numbers of users are sending funds, those specific services can scale independently to meet the load, rather than the whole application.

Microservices, by design, have a great affinity with cloud offerings, allowing services to deployed onto a cloud infrastructure using three different models:

  • Infrastructure as a Service: You manage services from the operating system up.
  • Platform as a Service: You manage services from the container up.
  • Serverless: You manage only your services.


Your build and deployment pipelines for services can be vastly improved and automated. Services should minimize changes to their interfaces, allowing changes and updates to occur with almost none of the downtime associated with traditional build and deployment activities.

Microservices support easier troubleshooting. This benefit requires good practices, but essentially it is a lot easier to see when components of your application are misbehaving. Because services are testable and visible, you can see when a service is failing its tests, using too many resources, or generating error logs.


Finally, managing the building of large, complex applications becomes a lot easier. As you go through the sections of your system, you will be defining small, manageable services that allow you to build, test, and deploy portions of your application quickly. As application development continues, much of the work becomes less about developing new services and more about adapting and composing services in different ways.

Deployment options

As mentioned, there are several ways to deploy cloud-based applications that also extend to on-premises and hybrid scenarios.

Traditionally, applications were deployed as a few big components on bare metal servers. You can still do this with microservices, and it may be particularly useful for services used in batch processes. However, most applications built using microservices try to take advantage of being able to scale automatically as required.

Hosting applications in virtual environments is fairly common practice with on-premises deployments. Virtual environments allow a microservices application to scale in some ways, but they’re still not as flexible as other environments. For instance, services used as part of a batch process that can start and scale virtual machines to crunch large amounts of transactions work reasonably well when deployed using virtual environments.

Cloud environments offer a large amount of flexibility when deploying microservices applications, with a number of options around how much of the environment to manage and almost limitless resources to scale individual services. Microservices do really well when deployed to cloud environments.

Running services within containers provide the most flexibility and control, albeit with additional overhead for maintaining and monitoring containers. Containers like Docker provide a self-contained environment for services to run in. Orchestration services like Kubernetes and Docker Swarm allow you to run and scale containerized services across both on-premises and cloud infrastructures, allowing for a truly hybrid deployment model.

Writing microservices

Microservices themselves can be developed with almost any language and framework. This includes Java, C#, JavaScript, Python, C++, Rust, Golang, and more. Part of this freedom allows you to migrate to a microservices architecture with the language your developers currently know and use. It also allows you to transition applications into other languages without the need to rewrite the whole application.

For instance, a payment processing service that runs primarily through a batch process might be written in Rust to ensure it runs as optimally as possible.

The other consideration of applications built using a microservices architecture is whether to adopt a truly serverless build leveraging Lambda (AWS) or Functions (Azure). These services allow you to build and deploy services without the need to configure scaling, servers, containers, or other components.

Next steps

You had a broad look at microservices, their benefits, and how to approach designing and developing applications using this architecture. While they shouldn't be used for every application, a microservices pattern can add a lot of flexibility for large applications and can really leverage the benefits of cloud services.


If you are looking to adopt this pattern or build your financial application in the cloud, check out the in-depth microservices guidance from AWS ( or Azure (


If you have questions, be sure, and post your question in our community forum. 

Principles matter. For any group, of any size, principles bring clarity, they provide a sense of purpose and they offer direction when the road ahead is difficult or complex. This is certainly true at Access Worldpay team, where test-driven development (TDD) is a guiding principle. Does it still hold true when put under stress?


At Access Worldpay, everything is tested, all the time, and the phrase “If it’s not tested, it’s broken” has become a mantra for the team. Rigorously applying this principle takes effort, even in software development where TDD has become commonplace. Maintaining the same rigour becomes far more challenging in newer areas, particularly infrastructure code. Why?


Big change, new skills

Infrastructure itself has changed rapidly and significantly, from localized hardware and software to remotely-located cloud-hosted services, such as AWS. This requires users to configure and code remote servers to their precise needs and then test that this code meets their required specifications.

Testing infrastructure code is, therefore, an entirely new discipline – one that is wholly embraced by Access Worldpay, albeit with open eyes. Dominic Byrne, a cloud engineer, explains: “Infrastructure code at the moment is in its infancy – for example, terraforming is releasing at a pretty rapid rate. It’s what we use, but it’s still in beta.”


New code, no context

As a result, Dominic explains, reliable testing frameworks do not yet exist. “People are reluctant to develop them because early ones don’t work anymore,” he says. “They were just built around a basic configuration plan so they become completely useless whenever the structure of that plan changes.”


What’s more, many cloud engineers are unused to TDD. “In the past, infrastructure engineers and application developers were two different teams,” says Daniel Beddoe, a senior software engineer at Access Worldpay. In addition, he explains, people used to question why infrastructure configuration files needed testing at all. “It turns out there’s every need to do so because now you could write something very bad in just one line of configuration that could mess up your whole infrastructure.”


Same team, single path

Instead of treating application and infrastructure engineering separately, Access Worldpay takes the same approach to every piece of work. “We’re making everything one team and applying practices from application development into infrastructure,” says Dan. This means identifying requirements and defining success before work begins on each project, whatever its nature: “We’re saying that you need to write tests for your infrastructure just as much as you need them for your applications.”


Part of this shift is organic. “People are increasingly moving from application development into operations and infrastructure,” Dominic explains. “They like the tools they currently use and they want to bring the same principles into infrastructure code.”

Live tests, late feedback

That’s easier said than done, because infrastructure code is tested against a live service, which makes the feedback loop much longer. “Without building anything, loading my spec files and running my tests on my current project averages about 44 seconds,” says Dominic: “For an application developer, tests taking that long to finish aren’t good.”


A central goal, therefore, is to ensure that this feedback cycle remains manageable – particularly since it lengthens further whenever code is altered. “If I change, say, an elastic search server, the loop goes from 44 seconds to 10 minutes at least – that’s just the reality of those services online,” Dominic explains. “So for infrastructure code, following basic TDD principles where you write your tests and watch them fail means allowing for the time it takes in your feedback loop.” That this can be difficult is hardly a surprise given the pioneering nature of the work, but the team has devised new ways to ameliorate these challenges.

Testing spec, teaming up

One approach is to change how infrastructure code is written before testing begins. Instead of writing and testing segments of code incrementally and enduring the long feedback loop each time, “you try to write each instance as the final product,” Dominic explains. “For example, saying ‘I want it to have these forwarding rules; I want this origin to match this specification,’ and you write all that and then you start your feedback loop to test that spec.”


The issue with working this way, of course, is unpicking the code should a test fail. But perhaps such workarounds need only be temporary; as infrastructure code is more widely adopted and tested, eventually more robust frameworks to support those tests may be built


In the meantime, Access Worldpay is supporting TDD for infrastructure code by physically pairing software developers and cloud engineers to shed old, silo thinking, and encourage the broader outlook that cloud-based infrastructure requires. “There’s a whole world of delivery to actually get your thing to work – you need to know how to get your application out into the world,” Dominic says: “Just knowing how it works locally isn’t useful for anyone.”


Towards better, even slowly

However imperfect today’s situation, Access Worldpay remains committed to testing infrastructure code. Partly this is to uphold the principle that TDD produces better, more reliable products for its customers, and partly because testing documents systems more clearly. This makes it easier for product owners to prioritize future work and for new team-mates to make useful changes quickly and with confidence.


The end goal of being able to apply traditional application development practices to infrastructure code in a consistent, rigorous way is still some way off. In the meantime, Access Worldpay is trying to develop a methodology that makes infrastructure code tests not only rigorous but also practical – staying true to its core principle while always analyzing its approach and making further refinements wherever necessary or possible. Progress, however uncertain, is still progress.

If you're a developer looking for Worldpay from FIS 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 developer community is a network for payment professionals and integrators. It is a comprehensive and accessible developer program that makes it easier to integrate payments into any application.


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: The specified item was not found..

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