The Netaxept API (Application Program Interface) supports REST interface (Representational State Transfer) and Web Services. Please select the most suitable interface option for your business. After you have selected the appropriate interface option, click the drop-down menu in the left side header or links below to find the right API calls for performing transactions through Netaxept. Also, familiarize yourself to the steps described in the “Flow Outline” section to find out in which order you should perform these calls. Netaxept doesn't provide any proprietary software installed on your server. Read more about:
- Flow outline >
- Register call >
- Terminal >
- Process call >
- Query call >
- Get Batch >
- Callback >
- Mobile In-App SDK >
- Validation rules >
- Exceptions >
- Sample code: REST >
- Sample code: Web Services >
Supported TLS versions
TLS 1.2 is the only secure protocol available when connecting towards Netaxept. Please make sure TLS 1.2 is supported and used in your systems for all operations (i.e. Register, Terminal, Process, Query or similar) when communicating with Netaxept (epayment.nets.eu, epayment.bbs.no or epayment.auriganet.eu).
You can check your current TLS version by logging into Netaxept Admin https://epayment.nets.eu. In "Transactions" page you will see the Info box with TLS version for each operation.
In REST, the merchant sends API calls to Netaxept using POST or GET method in HTML format and receives responses in XML format. Parameters in these calls need to be URL encoded, otherwise spaces and special characters will break the call and Netaxept won’t receive it in its complete form. There are no versioning issues with the REST API as long as you implement your XML parsing in a non-strict fashion.
Netaxept offers WSDL (Web Service Desciption Language) files which help merchants to easily understand and integrate the API endpoint. These files contain description of the API endpoint, such as the operations supported by the endpoint, input and output parameters of the supported operations, network protocols and serialization formats. The WSDL files can be downloaded below.
Standard WSDL file (excl. GetCardInformation) WSDL file for GetCardInformation WSDL for test environment WSDL for production environment
Please note that there is an issue with versioning with some Web Services platforms. The problem with versioning occurs when new fields are added to Netaxept’s output parameters. Nets will always place new fields at the end of the section, so that Web clients that don’t accept new "unknown" fields would ignore these fields. However, some technologies are very brittle when the output changes from what they did when the stubs were generated from WSDL files provided by Nets in the first place. Due to this, we have implemented a whitelisting system for Web Services; please see the lists below. If your Web Services platform is not on the whitelisted list or is included in the blacklisted list, please refrain from using it against Netaxept, as your Netaxept implementation might break when we make changes. The lists below are subject to change.
Whitelisted Web Services platforms
PHP5: PHP SoapClient (part of the normal PHP5 distribution) WCF: Windows Communication Foundation (part of .NET framework) CXF: Apache CXF services framework ZSI: The Zolera Soap Infrastructure for Python DOTNET20: .NET 2.0 Web References SUDS: Suds lightweight SOAP client for Python JAX-WS: Java API for XML Web Services
Blacklisted Web Services platforms
Axis 1: Apache Axis SOAP engine Axis 2: Apache Axis2 Web Services / SOAP / WSDL engine
If you use the version 1 of the Netaxept API, it has its output parameters frozen, so although new input parameters are occasionally introduced, it doesn't result in any breakage.