Invoice solutions

Enable customers to receive goods first and pay later without affecting your cashflow


This page outlines the basics of using "buy now pay later" payment methods via Netaxept and gives you instructions needed for a fluent implementation.

Use for the end-customer

If the customer decides to pay with an invoice, they are directed from the merchant’s site either to Netaxept payment window or to the website of the chosen invoice service provider. In the Netaxept payment window or service provider's site, the customer is guided through the payment process and after finishing it, the customer will be redirected to the redirectURL specified by the merchant in the Register call, with a proper response code. The invoice service provider sends the customer an invoice for the purchase as agreed and settles the payment to the merchant within the agreed time.


To be able to use invoice solutions in your webshop, you need to sign an agreement with each particular invoice service provider you want to use. After the chosen service provider has processed your agreement, they will provide you credentials which you need to enter to Netaxept Admin to activate the payment method in question. You will need to add one agreement for each of the combination of invoice, instalment or account that you want to have, per currency. The merchant is responsible for activating these payment methods in Netaxept Admin and ensuring that all information entered is correct.

  • Log in to Netaxept Admin (test: or production:
  • Go to "Options" => "Agreement" tab.
  • Choose the correct payment method from the drop down list and click "Add" button.
  • Choose the correct currency and enter credentials. The number of credentials varies between different invoice providers, and the terminology varies as well.
  • Save your changes by clicking "Add" button.

Performing API integration

Implement the technical API in accordance with the standard Netaxept's API instructions. Read more about API

Transaction flow

Start the payment process by sending the information required for the payment to Netaxept by means of the Register call. Compared to the regular card integration, there are some mandatory parameters that need to be sent along the Register call to Netaxept. See below for more information.

After the successful Register call, perform the Terminal call to send the customer either to the Netaxept payment window or directly to the invoice provider's site for the payment. If the invoice provider supports SCA, it is triggered in this phase. Regarding financial operations done after the Terminal phase, there are some differences depending on which invoice payment method has been used. Invoice payment methods don't support all financial operations, which eliminates a step in the standard payment process done via Netaxept. To make sure your setup doesn't try to run not allowed steps, we recommend you to implement the following:

  • Use the "Payment method action list" parameter in the Register call to separate invoice from card and other payment methods in the checkout phase.
  • Perform the Query call after the Terminal phase to see which payment method was used for the payment, and make the further action based on the payment status.
  • Implement the supported financial operations per payment method as described in Payment methods

Mandatory parameters

Goods list

In the Register call, there is a Goods object, under the Order object, which is a mandatory object for all invoice payment methods implemented via Netaxept. The Goods object contains an array of Item objects, each containing a set of parameters. One Item object represents one product line / item. The full set of parameters is listed below. Boolean values are either "true" or "false". For float variables, use the "." character as delimiter, for example: 24 percent VAT is set as 24 or 24.00. Read more about these parameters

  • ArticleNumber (string) (required)
  • Title (string) (required)
  • Amount (integer) (required)
  • Quantity (integer) (required)
  • Handling (boolean)
  • Shipping (boolean)
  • IsVatIncluded (boolean)
  • Discount (float)
  • VAT (float)

When working with REST interface, the format of the parameters needs special formatting. As the number of items is variable, you need to send a parameter "numberOfGoods" indicating how many product lines / items should be expected in the Goods list. Then, indexed from 1 up to "numberOfGoods", pass the parameters as amount_N, articleNumber_N etc. where "N" is the serial number of the item. Below you can find an example of this kind of REST call. In Web Services, numberOfGoods parameter is not needed.

Purchase 120 euros that contains two items with the following info:
1. 200 pencils, cost 0,50 euros each, incl. VAT 24%
2. Shipping, cost 20 euros, incl. VAT 0%
3. Payment method is selected in the merchant's webshop and Netaxept payment window is skipped

The Register call:[{"PaymentMethod":"AfterPay"}]&numberOfGoods=2&amount_1=50&title_1=Pencil&quantity_1=200&articleNumber_1=1&VAT_1=24&IsVatIncluded_1=true&amount_2=2000&title_2=Shipping&quantity_2=1&articleNumber_2=2&VAT_2=0&IsVatIncluded_2=true&customerFirstName=Bill&customerLastName=Buyer&CustomerAddress1=Testadress&customerPostcode=00510&CustomerTown=Helsinki&customerCountry=FI

Customer information

Besides the Goods object, in most cases you need to provide customer information of the end-customer for invoice to be an option. The customer's country is mandatory for most of the invoice payment methods. It should follow ISO 3166-1 Alpha 2 code, for example: "NO", "SE", "DK", "FI".

There are also some customer information, like customer name, address, post code, town, email address, phone number and social security number that are required for some invoice payment methods. See more information from the table below. Customer information can be passed in the Register call or let customer to fill in the details in the Netaxept payment window. Read more about these parameters

Total sum of items

It should be noted that when accumulating the total sum of each item, it must match the sum specified for the transaction as a whole in the Amount / Order.Amount parameter in the Register call. In the example below, the one pizza (150 NOK) and two carrots (2 * 50 NOK) equals 250 NOK.

Order = new BBS.Order
Goods = new BBS.Item[]
new BBS.Item {
Amount = "5000",
Quantity = 2,
Title = "Carrots"
}, new BBS.Item {
Amount = "15000",
Quantity = 1,
Title = "Pizza"
CurrencyCode = "NOK",
Amount = "25000",
OrderNumber = "12345",
}, [...]

Triggering SCA for invoice payment methods

As of today, SCA is supported for Walley by sending the validateCustomer="true" along the Register call to Netaxept. When using this parameter, Transaction ID needs to be at least 21 characters. The authentication method is defined based on the following combinations:

  • Finland when customerCountry=FI and currencyCode=EUR
  • Norway when customerCountry=NO and currencyCode=NOK
  • Sweden when customerCountry=SE and currencyCode=SEK
  • Denmark when customerCountry=DK and currencyCode=DKK

For AfterPay, no separate parameter needs to be passed along the Register call, instead, Arvato will route the transaction to SCA based on the logic and rules on their side.

Partial credits and captures

When doing partial credit, you need to send the Goods object for that part of the transaction along the Process (Credit) call to Netaxept. The parameter values in the Goods list need to be comparable between the original payment and the credit, i.e. if there have been for example two items in the original Goods list with VAT24% and VAT0%, then the same items and VAT% need to be presented in the credit call too. Item prices may of course vary depending on the amount to be credited. For Klarna, also the Article number parameter is mandatory when doing partial credits. 

Netaxept also supports partial captures for some invoice payment methods (AfterPay, Walley and Klarna). When running partial capture, the Goods object for that part of the transaction needs to be sent in as part of the capture. Also, if you are running partial capture you later might want to credit, you need to be aware of the SubTransactionId parameter. The SubTransactionId becomes a requirement because when you are doing a partial capture, you are actually creating an invoice, with its own invoice number. The SubTransactionId is available as part of the ProcessResponse, so you get it immediately after running the Process(Capture) or Process(Sale) call. You can also fetch it at any time using the Query call.

When doing full captures and credits, the SubTransactionId and Goods object can be ignored. For the time being crediting invoice payments manually via Netaxept Admin is not fully supported. It means that in Netaxept Admin you can credit only full amounts but not partial amounts because Goods list function is not fully supported in the Credit page.

Adjusting the invoice amount

After an invoice has been activated, you can make adjustments to that invoice. Adjustments are amounts not limited to certain articles, instead, when doing an adjustment, you are adjusting the total invoice amount. Adjustments are applicaple for example to discounts, price adjustments, delivery and surcharge charges. Currently adjustments are supported for Walley.

When adjusting the total invoice amount, send the Process(Adjust) call to Netaxept. Adjustment can be either positive or negative which needs to be indicated in the parameter adjustmentType. The valid values are:

  • Positive = Amount will be added to invoice
  • Negative = Amount will be deducted from invoice

You cannot run the Process(Adjust) call before you have done the successful Process(Capture) call. Also, you are not able to adjust the amount to the invoice, if the transaction is already fully credited. Goodslist is mandatory when you perform adjustments through API. The SubTransactionID (i.e. Invoice ID) is mandatory in case adjustment needs to be performed on partially captured transaction. You can run the Query call to retrieve the adjusted details for a transaction. Likewise, adjusted information for a transaction are available in Netaxept Admin.

Process(Adjust) call:

Supported payment methods

Invoice solutions that are supported by Netaxept at each time are listed below. There are slight differences in mandatory parameters (except Goods list which is mandatory for all invoice and instalment payment methods), as well as supported countries and currencies, between different invoice payment methods.

Name Payment method name in API Supported countries Supported currencies Notes


New API integration

  • Supported B2C and B2B payment options: Invoice, installment (only for person), flex account (only for person), campaign invoice (flex and floating) and SEPA Direct Debit.
  • Customer information is mandatory
  • Order number needs to be unique 

AfterPay invoice 

Will be discontinued

GothiaInvoice FI, NO, SE EUR, NOK, SEK  

AfterPay instalment

Will be discontinued

GothiaInstallment FI, NO, SE EUR, NOK, SEK  

Walley invoice

Collector DK, FI, NO, SE DKK, EUR, NOK, SEK
  • Country and Currency matching
  • OrderNumber length <=20
  • Both ArticleNumber and Title required in Goods list
  • CustomerNotificationMode should be "EMAIL"

Walley B2C invoice with Walley hosted terminal 

In pilot use for selected merchants

WalleyB2C FI EUR
  • Customer is directed to Walley hosted terminal 

Walley B2B invoice with Walley hosted terminal 

In pilot use for selected merchants

WalleyB2B FI EUR
  • Customer is directed to Walley hosted terminal
  • customerIsCompany=true is required

Walley instalment

CollectorInstallment FI, NO, SE EUR, NOK, SEK
  • Country and Currency matching
  • OrderNumber length <=20
  • Both ArticleNumber and Title required in Goods list
  • Min amount 1000 SEK/NOK and 100 EUR
  • CustomerNotificationMode should be "EMAIL"

Klarna invoice

Discontinued as of October 1st, 2020

  • CustomerNotificationMode needs to be set
  • ArticleNumber required for partial credits
  • Requires authorization and capture by merchant

Klarna instalment

Discontinued as of October 1st, 2020

KlarnaInstallment DK, FI, NO, SE DKK, EUR, NOK, SEK
  • CustomerNotificationMode needs to be set
  • ArticleNumber required for partial credits
  • Requires authorization and capture by merchant

Enterpay B2B invoice

Enterpay FI EUR
  • Only Goods object is mandatory, customer information optional
  • Mandatory to generate unique OrderNumber for each transaction
  • Read more about Enterpay integration from the Getting Started Guide

Getting the invoice 


Getting the invoice is easiest done through Netaxept Admin. Alternatively, the invoice can be pulled directly from API using the SubTransactionId parameter.


Getting the invoice is easiest done through Netaxept Admin or Walley's Merchant Portal. You can also use CustomerNotificationMode parameter in the Register call to indicate how to send the invoice to the customer.


After a successful Sale or Capture the invoice will be created and can be downloaded from Klarna at[invoiceid].pdf. The invoice ID is available via the Query call, at the InvoiceInformation.InvoiceId parameter. You can also use CustomerNotificationMode parameter in the Register call to indicate how to send the invoice to the customer.


After the successful payment, merchant's chosen settlement partner will send the invoice to the customer in a chosen way.

Recurring billing

Besides the regular invoice, some invoice providers support also recurring billing for invoicing customers easily on a regular basis. For the time being, reucrring billing is supported for AfterPay.

In Netaxept, the recurring billing for AfterPay works in a similar way as regular Easy Payment functionality. Read more about Easy Payment

Initial transaction

When performing the initial transaction, send the following parameters to Netaxept along the Register call.

  • recurringType=”S”
  • Include “AfterPay” into paymentMethodActionList parameter

After the successful Register call, perform the Terminal call to send the customer to the payment window.

After the customer has successfully passed the Terminal phase, run the Process(Capture) and then the Query call on the transaction, to find the token from the parameter panHash, and store this token value on the customer profile for later transactions.

Subsequent transactions

When performing the subsequent transaction, send the following parameters to Netaxept along the Register call.

  • panHash=[stored token]
  • recurringType=”S”
  • serviceType="C"
  • Include “AfterPay” into paymentMethodActionList parameter

After successful Register call, perform the Terminal phase. The terminal for the consumer is bypassed but during this phase Netaxept runs automatic authorization on the transaction. After the successful Terminal phase, run the Process(Capture) call to process the transaction.