Creating an Agile Payments System Testing Sandbox using Portus EVS

Creating an Agile Payments System Testing Sandbox using Portus EVS

Payments systems by their nature are incredibly complex and expensive to create. Thus when trying to test new payments applications, accessing one of these testing environments is essential to build out new and extend existing payments applications. As more and more small, medium and large organizations are now using these systems, getting access to such an environment is proving increasingly difficult whilst also presenting an issue around data compliance due to sharing of environments.

Agile Testing Sandboxes provide the ideal solution as they can be made available at low cost, on demand and isolate different testers from each other ensuring good data governance and availability. Ostia chose the nets payment API as an example as this is extensively used in the Nordic area for payments.

The nets Testing Challenge

The real systems backing up the nets network are very complex and therefore expensive to provision and maintain. This means that access to such tests systems must be shared or restricted causing a bottleneck to application testing.


Sharing systems has the following challenges:

  • Activities by individual users can compromise the entire system leading to stability issues.
  • Changes may be made by others using the system thus causing tests that worked to fail.
  • It is impossible to ensure a consistent state on a shared system.
  • Sharing of data between organizations is not ideal and, in fact, could potentially be illegal with the new GDPR regulations coming from the EU.
  • Non-functional tests are harder to set up as changing the behaviour of the system impacts all users of the systems.

Restricting access to systems has the following challenges:

  • It means by definition that there is less time to test sometimes restricting access to a number of days in a month.
  • There is by definition a setup and teardown effort before the test system may be used and to clean-up after it has been used.
  • This is simply not scalable causing further restrictions as more users and products are brought on board.

The Nature of the nets API

The nets API is made up of a number of REST services which accept a number of parameters on the URI and returning various XML documents on completion. Apart from the data validation of the parameters, there is a sequencing to the operations that must be observed. The following are some examples:

    • Register request must be issued first to return a transaction ID before a payment may be processed.
    • This transaction ID may then be used to reserve or AUTHorize an amount on a card and finally to CAPTURE that amount from the card. The CAPTURE must not be issued before the AUTH.
    • The transaction ID must be unique for a given merchant so cannot be repeated.

Creating a Sandbox of the Nets Environment

It was decided to create a set of virtual services to implement the nets APIs in a nets Payment Testing Sandbox using Portus EVS.

Initial consideration was given to using the standard service virtualization technique where test transactions are recorded and can then be replayed back for test purposes, however, this was rejected for the following reasons:

      • The nature of the nets system is that each transaction must be unique. Recording and replaying would by definition break this rule as the same transaction IDs would be used.
      • It would not be possible to enforce the correct sequencing as if a given individual interaction with the system was recorded (e.g. a CAPTURE request), this could be replayed ad infinitum regardless of whether a preceding REGISTER or AUTH request was issued.
      • There was concern that data would need to be masked or obfuscated in different ways for different sets of testers.
      • Record and replay does not give the flexibility for developing against services as this method is simply too rigid.

It was decided that the best way to achieve this was by using the Portus Extended Virtual Services environment for the following reasons:

      • Portus EVS can ensure a unique transaction ID per transaction as required by the specification.
      • Portus EVS can enforce sequencing and thus correctly reject out of sequence request.
      • Each test environment can generate their own data thus avoiding any issues with reusing masked or obfuscated data.
      • Because Portus EVS is reacting like a real system no matter what event is sent to it, it is much more flexible for the development of new applications.


The Result

Portus EVS enabled a fully functional nets sandbox environment to be created in less than two days resulting in a simulated payment service to be available for simultaneous testing from internal development and test teams and external testers and developers from their suppliers.

The nets Payments sandbox environment removed the load on the Customer’s production and test systems which were interfacing to the ‘nets’ network; further:

      • Individual users can test the end to end system in their bespoke environments.
      • Changes can be made by others without impacting on other users.
      • A consistent state on a shared system is ensured.
      • Data is not shared or compromised.
      • Setup and teardown effort is eliminated.
      • Scalability is automatically designed into the solution.
      • Fully compatible with Cloud delivery both from a technology and data security point of view.

Next Steps

Ostia have identified two other payments services available in the Nordics for which the interface specifications are publically available and these will be the subject of our next efforts. Watch this space:

    • The Vipps mobile payment solution available in Norway.
    • The Swish mobile payment solution available in Sweden.

Written by : Ostia Solutions