Skip navigation
All Places > Developer News and Updates > Blog > Author: andrew.harris

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. 

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.

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 

when you are at a party - and no one wants to talk payments meme
In your mind what would be the outcome if a crowd of 500 payment geeks spread out in a large banquet room in Vegas for 36 hours? Do we truly understand the problems we are being asked to solve? Do we have visions of grandeur and want to pitch something revolutionary to get some coin? Or are we really anxious to see the actual APIs that the sponsors will be revealing that can be tied into our product for the ultimate win?
For the past five years; developers, designers, and entrepreneurs flock to Vegas late October to mingle with their peers and accept a themed challenge relating to payments and FinTech. This is Money2020 Hackathon.
Some are serial hackers that make the circuit, eager to win so they can pay for a future tank of gas to get them to a future hackathon. Some are students looking to test their skills and get real-world experience and rub elbows with key industry players. While others just want to get away and spend a nice sobering weekend freaking out and stressing over what the hell to do to make payments rad. Can you guess which category our team fit?
I won’t bore you with what Money2020 is, you can look it up. I won’t drone on about what a hackathon is either, you can figure that out too. What I will talk to you about is what we learned and in turn ask you to give feedback on innovation and FinTech in the comments below.
The Story 
It was a warm Colorado afternoon in early October when a group came together over a working lunch to put aside the day-to-day talk of payment-processing, back-office application sprint planning, and the usual dev chatter around all things relating to individual technical work as a payment geek and engineer. It was time to secure our war-room, erase the spaghetti and database diagrams from the whiteboard, and get a jump start on collectively ideating for the annual pilgrimage to the Money2020 hackathon.
"For good ideas and true innovation, you need human interaction, conflict, argument, debate."   - Margaret Heffernan
Have you ever tried to loosen a machine bolt and find that you just can’t get enough leverage to break free? This is generally the way our annual ideation meetings begin. At home I have penetrating oil that I can spray the bolt head with, wait a few minutes and generally it will loosen up. After 5 years, we still don’t know what our favorite penetrating oil is, but after a couple of lunch-time meetings we somehow manage to get that rusted bolt loose and can start ideating.
Our team is very intelligent and capable of implementing and designing just about anything, and now that we had our idea we needed to determine our technology stack. Do we go-for-broke and attempt to learn something new or do we stick to our wheelhouse and forgo any language-centric or environmental gotchas. Knowing that there would still be gotchas. There are always gotchas. 
So after some debate, the team decided to stick with what we knew best and start building out a test environment. The goal was to make sure when we access those infamous APIs come game day, we could easily hook into them and get the information we needed back to help drive our solution. 
“There’s a way to do it better—find it.”   - Thomas Edison
Our idea was still evolving, but the basic foundation was in place, and we knew what we were going to build it in. The next step? Well given that we all have families and lives outside of work; plus the fact that we only had a handful of working lunches to ideate and test environments the next step was - to board the plane of course. 
After landing in Vegas we headed over to the meet and greet, had a few appetizers, Goose Island IPAs, and chatted with the four sponsors. Our idea still held up when pitching to peers and sponsors alike at the party, so we headed to our rooms to prep a little bit and get a good nights sleep before coding was to begin around 11am the next morning. 
"Ideas are like rabbits. You get a couple and learn how to handle them, and pretty soon you have a dozen.”   - John Steinbeck
After very little sleep due to a wild party in the hotel room next door, the team met in the banquet hall the following morning and secured our table and checked in with the sponsors. Once the clock started we began our coding and we certainly ran into challenges and had to pivot some along the way. Many hours into the code we found that one of the original ideas that we glossed over in one of our "rusted-bolt" war-room meeting the week before came to surface and we decided to pivot and work on that idea alongside our original plan. 
Confident then that we could pitch to (2) sponsors, doubling our chances of failure. 
“I want to put a ding in the universe.”   - Steve Jobs
I love innovation and I love working with people I don’t get to everyday in order to learn and grow not just professionally but as a human as well. Each year there are new faces that go with us to the hackathon and it is such a great experience. My advice is to get out of your comfort zone on occasion, it really can do wonders. 
Code Or It Didn't Happen
So you notice I didn’t talk at all about our idea or what we pitched. I first wanted to give you inside access to the repo and see the code for yourself. We will do a followup article if there is interest, but until then let us know what you think and ask questions below in the comments or tell us perhaps about a payment or hackathon experience you have had in the past. Also, should Worldpay do a hackathon for you guys as payment developers? Could be virtual or would you like to all met in Denver and code to some of our Worldpay APIs? We would like to know your thoughts.

“99 percent of success is built on failure.”   - Charles Kettering
We didn’t get to pitch our idea on the main stage or win any foam-core board checks that would not have fit in the overhead bin anyways. What we did come away with some great new ideas and will be spending some working lunches over the next few months bringing them to life and hope to share with you sometimes soon.