Introduction

Introduction to Web Service API and XML Schemata

Web Service API

The Web Service API is an Application Programming Interface which allows you to connect your application with the Fiserv Gateway. In this way, your application is able to submit payment transactions without any user interference.

📘

Please note:

If you store or process cardholder data within your own application, you must ensure that your system components are compliant with the Data Security Standard of the Payment Card Industry (PCI DSS). Depending on your transaction volume, an assessment by a Qualified Security Assessor may be mandatory to declare your compliance status.

From a technical point of view, this API is a Web Service offering one remote operation for performing transactions. The three core advantages of this design can be summarized as follows:

Platform independence: Communicating with the Web Service API means that your application must only be capable of sending and receiving SOAP messages. There are no requirements tied to a specific platform, since the Web Service technology builds on a set of open standards. In short, you are free to choose any technology you want (e.g. J2EE, . PHP, ASP, etc.) for making your application capable of communicating with the Web Service API.

Easy integration: Communicating with a Web Service is simple – your application has to build a SOAP request message encoding your transaction, send it via HTTPS to the Web Service and wait for a SOAP response message which contains your transaction’s status report. Since SOAP and HTTP are designed to be lightweight protocols, building requests and responses becomes a straightforward task. Furthermore, you rarely have to do this manually, since there are plenty of libraries available in almost every technology. In general, building a SOAP request and handling the response is reduced to a few lines of code.

Security: All communication between your application and the Web Service API is TLS-encrypted. This is established by your application holding a client certificate which identifies it uniquely at the Web Service. In the same way, the Gateway holds a server certificate which your application may check for making sure that it speaks to our Web Service API. Finally, your application has to do a basic authentication (user name / password) before being allowed to communicate with the Web Service. In this way, the users who are authorised to communicate with the Gateway are identified. These two security mechanisms guarantee that the transaction data sent to Fiserv both stays private and is identified as transaction data that your application has committed and belongs to no one else.

While this represents just a short summary of the Web Service API’s features, the focus of this guide lies on integrating the Fiserv Gateway functionality into your application. A detailed description, explaining how this is done step by step, is presented in this guide.

Web Service API: XML and Schemata

XML in Web Service API

📘

Please note:

The Web Service API uses the XML standard for communication.

For further specifics, please take a look at: http://www.w3.org/standards/xml/core

Including the specification of namespaces described on: http://www.w3.org/TR/2009/REC-xml-names-20091208/.

To make the names of the XML tags unique (e.g. in IPG: IPGApiActionRequest, Action, RecurringPayment, etc.), namespaces are used.

Example:
http://ipg-online.com/ipgapi/schemas/ipgapi, http://ipg-online.com/ipgapi/schemas/a1, …

These namespaces are defined in the xsd files like xmlns:ipgapi="http://ipg-online.com/ipgapi/schemas/ipgapi".

❗️

Please note:

The same namespaces must be declared in the XML files (no parsing with hardcoded namespace references), starting with keyword xmlns.

With the namespaces we recommend to use libaries to manage the XML messages.

In the course of future product develoment, it may be necessary that we extend the IPGApiRequest or IPGApiResponse with further members. While extending the request will have no impact on your implemented code, extending the response might cause errors if you check the response against ipgapi.xsd. We therefore recommend to deactivate the check.

XML Schemata

The definitions for the XML document building blocks can be found here:


Want a quick overview?