REST is becoming extensively used in the payments space. Programmableweb.com, which maintains a directory of all public Web APIs, has tracked two significant increases in financial APIs since 2012. The first, in 2012, ties in with a general increase in APIs across the internet. The second is more interesting. Taking place in mid-2016, this increase relates to implementation of various Open Banking initiatives, including, but not limited to PSD2 in Europe. In fact, many countries are seeing a significant upsurge in open banking initiatives, as we discussed in our “Open Banking - Not Just For Europe” blog last year: http://www.nuwavetech.com/hpe-nonstop-innovations/open-banking-not-just-for-europe
For those of us in the NonStop Payments space, perhaps using BASE24/BASE24-eps, Connex, or even an in-house solution, this evolution is an important one. We need to understand how the payments services we provide might be able to participate in this new API-based world.
NuWave develops two NonStop-based products that can help in this space - LightWave Server and LightWave Client. LightWave Server allows NonStop applications to be securely and easily exposed as REST-based Web services. LightWave Client allows NonStop applications to quickly and easily access REST-based Web services outside the NonStop - either within the enterprise or externally.
LightWave Server can work in a variety of different ways to create REST services from your payment engine. Consider the following diagram:
This example might be a good fit for customers wishing to REST-enable their BASE24 Pathway management screens, for instance. This could allow simplified access for customer service representatives, perhaps by aggregating information from multiple Pathway screens into one modern UI. It could also be used by an in-house payment application, with LightWave Server presenting an IPM to the in-house application in the format expected by the application. This would allow the payment applications transactions to be exposed as REST Web services without changes to the application.
BASE24 and BASE24-eps utilize XPNET as their message-oriented middleware (MOM) on NonStop. This means that any REST solution needs to integrate with XPNET to allow REST-enablement of the BASE24/BASE24-eps online transaction path (e.g POS or ATM transactions). XPNET does support Pathsend messages, via its Common Transport Subsystem (CTS) protocol. The CTS Pathway protocols allow XPNET to present itself as a Pathway Server, and/or act as a Pathway Client and access other Pathway Servers. In this way, the LightWave products can integrate with XPNET, and therefore BASE24/BASE24-eps.
Using this approach, any BASE24/BASE24-eps transaction can be REST-enabled, normally without requiring any application changes. LightWave Server handles the REST request, and will present the required application message to XPNET via a Pathsend, who will process it and forward it onto the correct BASE24 satellite process. This approach could be used, for example, to allow an internet banking application to quickly access a BASE24 transaction, and make that transaction available to the bank’s internet banking users.
More and more often, payment engine users need to incorporate remote services into their payment transactions and capabilities. Consider a rules engine, within the enterprise, that exposes its as REST services. If the payment engine needed to take advantage of those rules as part of its transaction authorization, it would need to integrate with the rules engine using JSON/REST. LightWave Client can facilitate this type of connectivity.
Used in this way, LightWave Client also allows payment engines to take advantage of the many thousands of public web services available, and to bring the data from those services back into the online transaction path. Services for currency code conversion, for blockchain-style operations, and for stock price lookup are just a tiny sample of the types of services that might be used.
API Gateways, such as those from Mulesoft and DataPower, often play an important part in organizations that process payments. API Gateways can normalize, aggregate, and in many other ways coordinate an organization’s Web services. For payment engines running on NonStop, API Gateways present an opportunity, but also a challenge. If a transaction or service of the payment engine needs to be made available through an API Gateway, the payment needs to support a data format that the API Gateway supports. Legacy protocols, such as those used by many payment engines, are unlikely to be natively supported by the API Gateway. By utilizing LightWave Server to REST-enable the payment engine, it can most likely be simply integrated with the API Gateway, and therefore become a part of the enterprise’s Web service ecosystem.
Another API gateway use case arises when the payment engine needs to incorporate a service provided by the API gateway. Once again, the API gateway will support newer message formats like JSON and REST, but is unlikely to support older legacy formats. LightWave Client can be used to help invoke the API gateway’s services, and present the results back to the payment engine in a format it can support.
Both LightWave products include a comprehensive list of standard features that ensure your valuable transaction services are as reliable as the rest of your NonStop application infrastructure. They are completely fault tolerant, include support for TMF, and have extensive diagnostic logging. With built-in security features, including TLS, authentication and authorization, and a number of features to provide scalability and high throughput, you can be sure that your services remain up, and secure at all times.
If you would like to learn more about how LightWave solutions might help modernize your payment application, please get in contact with NuWave at sale@nuwavetech.com
Comments