Welcome to the new Netaxept documentation. You will find all the content you have had access to before here, if you look at the drop-down menu in the header.

Payment Overview

Netaxept provides payment services for your merchant in 4 steps that involves the merchant’s customer and Nets as a payment provider:

1)      Once the customer has checked out the order, the merchant must register the order at Nets (the payment provider). By issuing a registration command together with the Merchant ID, Nets will accept and store this payment registration, and reply back to the merchant with a transaction ID that refers to this registration.

2a)   Either: The merchant puts this transaction ID in a web form and displays the form to the customer. The web form is set to submit the customer to a URL at Nets, where the customer will enter payment  information and  authenticate themselves at Verified by Visa / MasterCard Securecode.

2b) Or: The merchant collects the customer's payment info, and forwards this information to Nets. Nets will forward the customer to Verified by Visa / MasterCard Securecode for authentication.

3)      Once payment information is validated at Nets, the customer is redirected back to the merchant with a payment status.

4)      The merchant processes the actual payment by reserving or capturing the order amount with a process command to the payment provider. The processing command will be matched with the previous registration, and both need to receive a OK status in order for the payment to be processed. Whether the payment was processed with status OK or not, a reply is sent back to the merchant, enabling the merchant to send a “Thank you” or an “Error message” to the customer.

Netaxept provides these payment services to the merchant with no proprietary software installed on your server.  Netaxept gives you the option of two standardized communication methods in order to access the payment services commands described in the 4 steps above.


REST (Representational State Transfer) or Web Services

Using REST, the merchant can call the Register webpage, the Process webpage, or a Query webpage (to check status) at Nets in order to perform the 4 steps above. The reply from all webpages is XML, enabling the payment provider to send back more than one line of information to the merchant.

Using Web Services the merchant will be able to remotely access the payment provider commands by downloading and installing 2 WSDL files (test and production). A WSDL file will let your Web Services know which payment processing commands are supported in Netaxept.



Netaxept provides 3 ways of getting the payment info (like a card number) from the merchant's customer.

Service type Nets hosted:

Nets, and not the merchant, provides the webpage for the customer to enter a card number (or other payment method). This will free the merchant for PCI requirements (se below) that is otherwise required. Although the webpage is at at Nets, the merchant's logo and the merchant's order description is still displayed on the webpage.




Service type Merchant Hosted:

The mechant collects the customer's card information from the merchant's webpage, and posts the card number through HTTPS to Nets during the payment dialog. The merchant will have complete control of the layout of such a webpage, but has to implement the merchant solution according to the PCI requirements. The merchant is not allowed to save the card number.



Service type Callcenter:

If the merchant provides a solution for accepting the customers card by phone, the merchant would normally have an operator that enters the card number in the payment dialog on behalf of the customer. 3D Secure autentication is disabled, since the merchant is not allowed to ask for the customer's 3D Secure password. The merchant needs to have a special agreement with their Aqcuirer in order to use this service type. The merchant operator can enter the customer's card number at a Nets webpage, or at the merchant's own web page if the merchant meets the PCI requirements.




PCI DSS (Payment Card Industry Data Security Standard) is a standard created by the card companies that requires the merchants and the payment providers (like Nets) and the acquirers (that the merchants have payment agreements with), to implement solutions that will secure and safeguard the customer's card information during a payment transaction, and when saved in a database. Such a solution will be validated at least yearly by external inspectors, at the costs of the ones hosting the solution. In order for the merchants to save costs, it is recommended to use a Nets hosted service type (se above) to minimize the requirement for PCI.


Recurring Payment

Merchants have the option (based on agreement with Acquirer) to perform repeating payment of Card holder, without any Card holder interaction after the initial payment. After the initial payment, the payment provider will make a hash of the card number, and store the hash. The Merchant will also be given the hash, and can use this hash in future payments to charge the card holder, without the need for card Holder interaction. The payment provider will map any hash with the actual card number during a following payment in a secure way in accordance with PCI.



Merchants have the option (based on agreement with Acquirer) to store a hash of the customer's card number.  With a hash present at the merchant, the customer only have to enter the security code on backside of the payment card (3 to 4 digits) to complete the payment. This payment option is called EasyPayment. The first time the customer visits the merchant, normal payment must be completed, including entering the card number and authenticate himself/herself at 3D Secure. If this payment completes OK, the merchant is given a hash from Netaxept that represent the customer's payment information. Next time the customer visits the merchant, the merchant will use this hash, and the customer will only have to enter the security code in order to complete the purchase. Merchants using EasyPayment do not have to be PCI compliant.


In order for Netaxept to return a card number hash, the Register command must include the Recurring type = "S" in the Reccuring section. This will create a hash without any limits on time periode and frequency that a regular recurring agreement requires (Recurring type = "R").

It is also possible to create a hash the first time without any purchase from the customer if you set the UpdateStoredPaymentInfo = "True" in the Register command. This is an alternative to Recurring type = "S" which requires an initial purchase from the customer. You can find more information about these parameters under API and Register.

Depending on you agreement with your acquirer you may or may not have to ask the customer for the CVC code for each transaction. EasyPayment supports both variants. Certain industries (mostly travel related) have an excemption from using the CVC code. Please consult your acquirer for further info.

Please be advised that EasyPayment without entering CVC code for subsequent transactions does not work with Dankort due to technical restrictions. If implementing this functionality for Dankort you need to follow the instructions for Recurring Payments which gives the same user experience and functionality


If you are a PCI compliant merchant, you can start a "First time Payment" with Register using ServiceType=M and host input fields collecting card data at mechant site.


Direct banks


The configuration of direct banks is done by via Netaxept admin (Options -> Agreement).  Supporting a direct bank requires that the merchant has an agreement with each particular bank. The bank will in turn issue credentials which Netaxept uses to configure a merchant for this bank. The number of credentials varies – between 1 and 3, and the terminology also varies. In any case, the merchant needs to manually add this information in Netaxept admin, or ask the customer support for help.


For more information about integrating with direct banks, go to the full description of the integration process.