Netaxept Soap API

Transaction identifier defined by the merchant. Nets recommends to generate each transaction unique order number, but the same order number can be used several times if desired. Digits and letters are allowed except special characters and Scandinavian letters like Ø Ä Ö.

Currency code for the transaction amount according to ISO 4217. For example 'NOK', 'SEK', 'DKK', 'EUR' and 'USD'.

Transaction amount described as the lowest monetary unit for the given currency without punctuation marks and excluding any fees. For example: 100,00 NOK is noted as '10000' and 9.99 USD is noted as '999'.

The maximum amount possible for this value is 2147483647, the maximum value of a signed 32 bit integer.

Amount is optional if updateStoredPaymentInfo=true is set in the Register call.

If set to true, the customer must be fully authenticated by 3D Secure or the equivalent authentication method to be able to complete the transaction.

Used when saving card details for subsequent transactions. If set to true, it indicates card registration or update of earlier stored card details, without processing a full purchase. Read more about tokenization services.

When using updateStoredPaymentInfo=true, no transaction amount and order description are displayed in the payment window. Instead of "Pay" button, the customer will see the "Register" button to register their card in the payment window.

When using UpdateStoredPaymentInfo, the Process (Verify) call should be used for the transaction if it is available for the payment method. This call will confirm that the card used in the purchase is currently valid and active and can be used for later transactions. Read more about Process (Verify) call.

Indicates the SCA exemption type applied to the transaction. Use this parameter to request an exemption from Strong Customer Authentication (SCA) without the need to perform 3D Secure authentication. Note that exemptions are not allowed to be used in connection with initial transactions when card details are saved for subsequent transactions. Valid values are:

• 1: Low value payment. Do not add this parameter if the amount is higher than 30 EUR.

• 3: Delegated authentication. Please contact Nets to enable this for your Merchant ID.

If set to true, it triggers SCA for Walley. This functionality currently works for the following countries:

• 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

When using this parameter, Transaction ID needs to be at least 21 characters.

Date when Netaxept automatically executes the Process (Capture) call for the transaction, in the format YYYYMMDD. When using this parameter, the merchant needs to run the Process (Auth) after the Register call as normal, but then the Process (Capture) will be managed by Netaxept.

Indicates the authorization type. These features are in pilot phase with selected merchants. Valid values are:

• Fuel: Authorization for transaction originated from automated fuel dispenser. 3D Secure (or equivalent) authentication is required for the transaction.

• Electric: Authorization for electric vehicle charging. Currently supported in Nets acquiring.

Indicates which Web Services technology is used when calling Netaxept. This field is required to allow us to track problematic technologies which might cause merchants' implementations to break when Netaxept API is upgraded. If using Web Services and this parameter is omitted, the transaction will be rejected with SecurityException.

Check our whitelisted and blacklisted Web Services platforms](). If your technology is not on either list, please contact Netaxept Customer Support for your country to have your technology evaluated. Do not just pick one randomly to get the Register call through - problems will probably occur in the future if you do this.

Indicates which operating system is being used on the merchant's platform.

Indicates which programming language is being used to implement the merchant's solution.

Free-format textual description determined by the merchant for the transaction. This can be HTML-formatted. If you are using a Netaxept-hosted payment window, this description will appear in the payment window for the customer. Unlike the other fields, the order description will not cause the call to fail if it exceeds its maximum length. Rather, the field will be truncated to its maximum length.

Indicates which language is used in the Netaxept-hosted payment window (that is, when using ServiceType=B). If omitted, the language is set to Norwegian. See also the list of valid languages.

Indicates where to send the customer after the transaction passes the Register call and Terminal phase. This URL can contain GET parameters. The redirect URL is optional when using AutoAuth, and shouldn't be used with Call center transactions.

An array of PaymentMethodAction entries. These are JSON objects, each representing rules on how to handle payment method, fee and certain actions for the selected payment method. The format is specified at Payment method action list.

This parameter is deprecated, and we strongly urge you to do the implementation through the Payment method action list (above).

This parameter is deprecated, and we strongly urge you to do the implementation through the Payment method action list (above).

Specifies how much of the transaction amount is value added tax (VAT), described as the lowest monetary unit for the given currency without punctuation marks. For example: 100,00 NOK is noted as '10000' and 9.99 USD is noted as '999'. The VAT will be presented in the payment window and in Netaxept Admin.

Note that VAT is included in the original amount, meaning that Netaxept regards this amount as part of the total transaction amount as to not affect this amount. This is different from fee that is always added to the original amount.

If set to true, Netaxept runs automatically the Process (Auth) call to the transaction after the Register call and Terminal phase. During the authorization, a cash provision is made for the customer's account for the agreed amount.

Using automatic authorization enables merchants to send out payment requests using ways other than a regular webshop, for example a payment link via email or SMS (that is, Link payment). If used without a redirect URL, the payment window will show a localized "Payment completed" type of message.

Please note that:

• autoAuth and autoSale should not be specified together, because they are mutually exclusive.

• By default, some payment methods (e.g. wallets and some invoice payment methods) run the Process (Auth) call to the transaction after the Terminal phase, even if the merchant does not set autoAuth=true.

If set to true, Netaxept runs automatically the Process (Sale) call to the transaction after the Register call and Terminal phase. During the sale, a cash provision is made for the customer's account for the agreed amount and the account is captured for the same amount.

Using automatic sale enables merchants to send out payment requests using ways other than a regular webshop, for example a payment link via email or SMS (that is, Link payment). If used without a redirect URL, the payment window will show a localized "Payment completed" type of message.

Please note that:

• autoAuth and autoSale should not be specified together, because they are mutually exclusive.

• By default, some payment methods (e.g. direct bank payments) run the Process (Sale) call to the transaction after Terminal phase, even if the merchant does not set autoSale=true.

Name of the terminal template you have created in Netaxept Admin that will be used for the payment. With this parameter, you can control the appearance of the payment window on a transaction basis. If this parameter is sent in, it will overrule any template that has been marked as active in Netaxept Admin and look up the correct template from the template names in the list of available templates. If the template cannot be looked up by name from Netaxept Admin, the default template will be used.

Template data is an array of key/value pairs and contains all the tags and their values that will replace the special HTML tags inside the template. This data is per transaction and will be merged into the active template. Several tags can be placed within curly brackets, and different tags and their values are separated by a colon. If the template contains tags on the form {keyname /}, the region will be replaced by the value associated with the key "keyname".

Create an array of KeyValuePair entries, and set the Key and Value fields as desired.

Maximum length of key: 64. Maximum length of value: 8000.

If set to true, the Netaxept-hosted payment window changes from two-page to single page. Because of the nature of this mode, the single-page payment window works only for card payments, not for other payment methods. Also, mobile terminal doesn't support single-page mode.

In single-page mode, the card input fields will be consolidated into a single input field, with the different card options shown as small icons. When the customer enters their card number, the selected card type will be highlighted as visual feedback to the customer.

Layout of the payment window to be used for the transaction. Valid values are:

• mini: The minimized version of the payment window is used to only include input fields for cards. The minimized version is ideal within the Terminal design templates, so that you can get the most out of the web page area for your own design. If an iPhone/iOS template is used for Netaxept mobile, the top navigation bar will not be shown if terminalLayout is specified as "mini". This doesn't apply to the other templates.

• custom: If you use Custom templates, set the terminalLayout to 'custom'.

If set to true, Terminal will redirect back to the merchant site if an error occurs.

Customer's social security number.

Customer's email address. Required if direct banks via Paytrail.

Customer phone number. Returned if the merchant has sent it to Netaxept along the Register call. The phone number should be given on the format of +[country code][phone number], for example: +4712345678, +469876543, +35850123456.

Customer ID that can be used to identify the customer or the customer group. The same customer number can be used several times. Returned if the merchant has sent it to Netaxept along the Register call.

Customer's first name.

Customer's last name

Customer's postal code

Customer secondary address. Returned if the merchant has sent it to Netaxept along the Register call.

Customer's postal code.

Customer city. Returned if the merchant has sent it to Netaxept along the Register call.

Customer's country according to ISO 3166-1 Alpha 2 code. For example: 'NO', 'SE', 'DK', 'FI', 'DE'.

The customer's company name.

The business ID of the customer's company.

Indicates the way an invoice should be sent. Valid values are:

• MAIL: Invoices will be sent to customers by post after each transaction.

• EMAIL: Invoices will be sent to customers by email after each transaction. Customer email address is mandatory in Register call.

• AGGREGATEDINVOICE: All incoming invoices during the same month will be aggregated to one invoice that has the same reference number every month and will be sent to the customer by email. Customer email address is mandatory in Register call. Can be used only for Walley invoices, where it is a so-called "Account" invoice type.

If set to true, only business-to-business payment windows (company related fields) will be displayed to the customer. Required if a B2B payment window should be requested.

Only used for the payment method SEPA Direct Debit via PPRO. Customer's IBAN number. Required if the customers are to enter their IBAN number on your website.

The card number, without spaces, to be used for this transaction.

The expiry date for the card to be used for this transaction, in the format MMYY.

The verification code for the card to be used for this transaction.

For example, the verification code for Visa (CVV2), Mastercard (CVC2) and Diners Club (CVV) consists of the last 3 digits printed on the back of the card. The American Express verification code (CID) is the 4-digit number printed on the front of the card.

Defines the tokenization type. Valid values are:

Initial transaction

• S: Indicates that card details are saved for future Easy payments or MIT transactions (excl. recurring payment).

• R: Indicates that card details are saved for future recurring payments.

Subsequent transaction

• S: Indicates that stored card details are used to perform subsequent Easy payments by card. RecurringType of the initial transaction must be 'S'.

• R: Indicates that stored card details are used to perform subsequent recurring payments by card. RecurringType of the initial transaction must be 'R'.

• M: Indicates that stored card details are used to perform MIT transactions (excl. recurring payment). RecurringType of the initial transaction can be either 'S' or 'R'.

Indicates how often the merchant is allowed to charge the card based on the customer agreement, in days. A frequency of '1' allows the merchant to make recurring payments on the card every day.

The minimum frequency is 0 days, meaning no limitation on the number of transactions per day. Maximum is 365 days.

Date when the agreement made between the merchant and the customer expires. The date is in the format YYYYMMDD.

Indicates the MIT transaction type (excl. recurring payment). Valid values are:

• 1: Unscheduled card-on-file (UCOF) Supported by all acquiring connections)

• 2: Delayed charge (Not supported in Swedbank acquiring)

• 3: No-show (Not supported in Swedbank acquiring).

The token value used in subsequent transactions to identify the transaction.

It is independent of the PAN and is not considered as a hash value. It is the merchant's responsibility to store tokens in a secure way and restrict access to data on a need-to-know basis. The merchant undertakes not to store tokens on frontend systems exposed to the internet or directly on mobile devices.

Merchants can add an extra layer of protection to their panHash parameters by adding a secret token linked to these parameters.

If set to true, together with recurringType=S, serviceType=B and panHash is specified for the subsequent transaction, the payment window will prompt the customer to perform 3D Secure or equivalent authentication. Otherwise subsequent transactions with stored cards are non-3DS authenticated.

Membership identifier for loyalty programs. The ID is validated only by its length which can be 10 digits. The same ID can be used several times.

Eligible amount for loyalty, described as the lowest monetary unit for the given currency without punctuation marks. For example: 100,00 EUR is noted as '10000'.

Eligible amount for payment method benefits, described as the lowest monetary unit for the given currency without punctuation marks. For example: 100,00 EUR is noted as '10000'.

If set to true, the card will be enrolled in the CardLink service while saving card details for future. With the CardLink service, merchants can identify and award their loyalty customers across different sales channels.

When using enableCardLink=true, updateStoredPaymentInfo must be set to true. The parameter customerLoyaltyId is optional, however, if not specified by the merchant and present, the unique value will be created and returned to merchant.

Sub-merchant's merchant category code (MCC) assigned by the acquirer.

Sub-merchant's marketing name (15), address (12), city (13), postal code (10), region (3), and country (3). All subfields need to be left justified with trailing spaces (or padded from the right with blanks if necessary). For example:

Katti Oy Kaitalantie Helsinki 00510 FIN"

Sub-merchant's merchant ID assigned by the acquirer or Payment facilitator.

The customer's ID that can be used to identify the customer. Minimum length: 2.

The account number of the webshop's account to which the money should be transferred for each AvtaleGiro capture.

Netaxept will store this value in the merchant's settings, but the stored value can be overridden by sending the account number parameter along the Register call.

The company name of the webshop. The name must exactly match the company name defined in the agreement between the merchant and AvtaleGiro. Netaxept will store this value in the merchant's settings, but the stored value can be overridden by sending the company name parameter along the Register call.

The suggested amount limit of this AvtaleGiro agreement between the customer and their bank. This is the maximum amount of each capture.

Note that the amount limit can be changed by the customer when they sign the AvtaleGiro agreement.

Only used for the payment method SEPA Direct Debit via PPRO. Description that appears on the customer’s bank statement. Description sent to Register call is reused for credit. Note, that it is up to each bank how many characters will be displayed on customer's bank statement or the bank may ignore the description altogether.

Only used for the payment method SEPA Direct Debit via PPRO. Indicates the party responsible for mandate and pre-notification sent to customer. Required unless transaction is subsequent. Valid values are:

• MANAGEDBYPPRO = Mandate and pre-notification are managed by PPRO.
• MANAGEDBYMERCHANT = Mandate and pre-notification are managed by merchant. In this case, also SepaMandateUrl is required.

Only used for the payment method SEPA Direct Debit via PPRO. URL for SEPA Direct Debit mandate. Required when PPRO.SepaMandate=MANAGEDBYMERCHANT. Should start with https:// or http://.

Indicates the price of the individual item including the possible VAT. It can have maximum of two decimal places. The amount needs to be described as the lowest monetary unit for the given currency without punctuation marks and excluding any fees. For example: 100,00 NOK is noted as '10000' and 9.99 USD is noted as '999'. Please note 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.

Specifies the unique identifier for the item.

Discount for the item. Use the '.' character as delimiter.

Specifies whether the handling is included in the item data.

Specifies whether the VAT is included in the item price.

Quantity of items bought.

Specifies whether the shipping is included in the item data.

A descriptive name for the item.

Assigned to each item. The unit code should start from 0 and it will get incremented based on the number of items.

The value-added tax percentage (VAT%) for the item. Use the '.' character as a delimiter. For example: VAT 24% should be set as 24.00 or 24.

When refunding the payment, the VAT% for the item to be refunded should match the VAT% of the corresponding original item.

Transaction identifier defined by the merchant. Nets recommends that you generate a unique order number for each transaction, but the same order number can be used several times if desired. Digits and letters are allowed except special characters and Scandinavian letters like Ø Ä Ö.

Transaction amount described as the lowest monetary unit for the given currency without punctuation marks and excluding any fees. For example: 100,00 NOK is noted as '10000' and 9.99 USD is noted as '999'.

The maximum amount possible for this value is 2147483647, the maximum value of a signed 32 bit integer.

Currency code for the transaction amount according to ISO 4217. For example 'NOK', 'SEK', 'DKK', 'EUR' and 'USD'.

For card payments this is the date when Netaxept automatically executes the Process (Capture) call for the transaction, in the format YYYYMMDD. When using this parameter, you must run the Process (Auth) after the Register call as normal but then the Process (Capture) will be managed by Netaxept. For SEPA Direct Debit it is the planned due date (the earliest day when the money will be debited from the customer's bank account.

An additional charge determined by the merchant for the transaction, described as the lowest monetary unit without punctuation marks. For example: 100,00 NOK is noted as '10000' and 9.99 USD is noted as '999'. The fee will be added to the original amount.

Free-format textual description determined by the merchant for the transaction. This can be HTML-formatted. If you are using a Netaxept-hosted payment window, this description will appear in the payment window for the customer. Unlike the other fields, the order description will not cause the call to fail if it exceeds its maximum length. Rather, the field will be truncated to its maximum length.

Timestamp indicating when the operation in question was finished. This timestamp is generated on the Netaxept server.

The sum of transaction amount fee described as the lowest monetary unit for the given currency without punctuation marks. For example: 100,00 NOK is noted as '10000' and 9.99 USD is noted as '999'.

Rounding amount defined by the merchant for the transaction, described as the lowest monetary unit for the given currency without punctuation marks. For example: 100,00 NOK is noted as '10000' and 9.99 USD is noted as '999'.

Indicates the SCA exemption type applied to the transaction. Use this parameter to request an exemption from Strong Customer Authentication (SCA) without the need to perform 3D Secure authentication. Note that exemptions are not allowed to be used in connection with initial transactions when card details are saved for subsequent transactions. Valid values are: 1 = Low value payment. Do not add this parameter if the amount is higher than 30 EUR. 3 = Delegated authentication. Please contact Nets to enable this for your Merchant ID.

Identifies which external authentication protocol, if any, has been used for the transaction. This field is set only for card transactions and currently can only be '3-D Secure'.

The status of the 3D Secure authentication. Valid values are:

• Y: Authentication successful. Cardholder was successfully authenticated.

• N: Cardholder not enrolled in 3D Secure or equivalent authentication service.

• U: Authentication could not be performed. Authentication could not be completed, due to technical problem.

• A: Authentication attempted. Performed authentication could not be completed, but proof of authentication attempt (CAVV) was generated.

The authentication result that is returned if the transaction has been authenticated by 3D Secure authentication services:

• 05 or 02: Card enrolled, authenticated OK.

• 06 or 01: Authentication attempted, but the payment card was not enrolled for the authentication service.

• 07 or 00: The merchant was not registered for the authentication service.

Indicates whether the transaction was downgraded by the card issuer and is returned only in that case. If ECI value is downgraded from fully authenticated transaction value, your chargeback rights will be diminished.

If AvtaleGiro data was sent on the current transaction, an AvtaleGiro status is required to give the status of the signing of the AvtaleGiro agreement. Valid values are:

• Ok: The signing of the AvtaleGiro agreement was OK.

• Cancel: The signing of the AvtaleGiro agreement was cancelled by the customer.

• Error: Something went wrong when signing the AvtaleGiro agreement.

Card number used for this transaction, masked with asterisks.

Indicates which payment method was used for this transaction. This parameter will contain the same value as CardInformation.PaymentMethod.

Expiry date for the card used for this transaction, on the format YYMM.

Token value used in subsequent transaction to identify the transaction. It is independent of the PAN and is not considered as hash value. It is the merchant's responsibility to store tokens in secure way and restrict access to data on need to know basis. The merchant undertakes not to store tokens on frontend system exposed to the internet or directly on mobile devices.

Country where the payment card used for the transaction was issued, formatted following ISO 3166-1 Alpha code. For example: 'NO', 'SE', 'DK', 'FI'.

Identifier for the payment method being used. May be either positive or negative.

Indicates which payment method was used for this transaction. Please see the valid payment methods at the Register call page in the 'Payment Method Action List' => 'PaymentMethod' parameter. For wallet based transactions, this parameter shows information about the underlying card whereas the name of the wallet used for the payment can be found in the 'Wallet' section.

Customer's email address. Returned if the merchant has sent it to Netaxept along the Register call.

Customer's phone number. Returned if the merchant has sent it to Netaxept along the Register call. The phone number should be given on the format of +[country code][phone number], for example: +4712345678, +469876543, +35850123456.

IP address of the customer's browser connection.

Customer's ID that can be used to identify the customer or the customer group. The same customer number can be used several times. Returned if the merchant has sent it to Netaxept along the Register call.

Customer's first name. Returned if the merchant has sent it to Netaxept along the Register call.

Customer's last name. Returned if the merchant has sent it to Netaxept along the Register call.

Customer's address. Returned if the merchant has sent it to Netaxept along the Register call.

Customer's secondary address. Returned if the merchant has sent it to Netaxept along the Register call.

Customer's postal code. Returned if the merchant has sent it to Netaxept along the Register call.

Customer's city. Returned if the merchant has sent it to Netaxept along the Register call.

Customer's country, following ISO 3166-1 Alpha code. For example: 'NO', 'SE', 'DK', 'FI' Returned if the merchant has sent it to Netaxept along the Register call.

Customer's social security number. Returned if the merchant has sent it to Netaxept along the Register call. Mandatory for certain payment methods.

Customer's company name. Returned if the merchant has sent it to Netaxept along the Register call.

Business ID of the customer's company. Returned if the merchant has sent it to Netaxept along the Register call.

Indicates that only B-to-B payment window (company related fields) have been displayed to the customer. Returned true if the merchant has sent customerIsCompany=true to Netaxept along the Register call.

Indicates which tokenization type is used for this transaction. Valid values are:

• Recurring (Init)

• Recurring (Pull)

• Store (Init)

• Store (Pull)

'Recurring' refers to recurringType=R and 'Store' refers to recurringType=S. In addition, 'Init' means the initial transaction where card details have been stored for subsequent transactions whereas 'Pull' means the later transaction where panHash connected to the initial transaction is used.

Indicates how often the merchant is allowed to charge card based on the agreement made with the customer, in days. frequency of '1' will allow the merchant to make recurring payments on the card every day. Minimum frequency is day, meaning no limitation on the number of transactions per day. Maximum is 365 days.

Date when the agreement made between the merchant and the customer expires. The date is described on the format YYYYMMDD.

The token value identifying the card transaction. It is independent of the PAN and is not considered as hash value. If recurringType was specified, and no panHash was supplied, this is the panHash generated by the payment card registration and should be used for the later transaction.

Secret token linked to their panHash parameters by the means of adding an extra layer of protection to their panHash parameters.

If set to true, together with recurringType=S, serviceType B or and panHash is specified for the subsequent transaction, the payment window will forward customer to perform 3D Secure or equivalent authentication. Otherwise subsequent transactions with stored cards are non-3DS authenticated.

Specifies which financial operation was tried to perform for the transaction when the error occured. Valid values are:

• REGISTER

• AUTH

• ACCOUNT VERIFICATION

• SALE

• CAPTURE

• CREDIT

• ANNUL

• HISTORY

• QUERY

• ADJUST (Positive) or ADJUST (Negative)

Read more about the different operations at the Flow outline section.

The amount of this part of the transaction operation described as the lowest monetary unit for the given currency without punctuation marks and excluding any fees. For example: 100,00 NOK is noted as '10000' and 9.99 USD is noted as '999'.

Free-format textual description of this part of the transaction operation determined by the merchant and displayed to the merchant in Netaxept Admin. The field can show also an IP address and/or username that has been used for the transaction. Please note that this is different than OrderDescription parameter and hereby is not shown to the end-customer to the payment window.

Specifies which settlement batch this operation belongs to. Is present if the financial operation is done to the transaction is question.

Timestamp indicating when the operation in question was finished. This timestamp is generated on the Netaxept server.

Reference number allocated to the transaction by the merchant. The transaction reference number will be returned to the merchant with the settlement if the chosen acquirer supports the return of the transaction-specific reference number. It can also be seen in the merchant's bank statement when direct bank payments are in question. Read more about transaction reference numbers In this parameter you will find the transaction reference number used for this part of the transaction. It can be sent to Netaxept along the Register call when it will serve as default reference for the transaction. Alternatively, it can be sent in along the Process call.

Invoice ID generated for each invoice. Usually one invoice transaction has one invoice ID, however, if you run for example partial capture for an invoice transaction, an invoice with its own invoice ID will be created.

Response code for this part of the transaction. Only failed operations are entered into the error log, so this parameter will never contain the string 'OK'. Read more about response codes.

Response text message explains the error code and gives more detailed description of the error helping the merchant to find out why the transaction failed. Read more about response messages.

Textual description of which part of the system generated the error code. The error codes are divided into groups according to the source. Read more about error sources.

Specifies which financial operation was tried to perform for the transaction when the error occured. Valid values are: 'REGISTER', 'AUTH', 'ACCOUNT', 'VERIFICATION' 'SALE', 'CAPTURE', 'CREDIT', 'ANNUL', 'QUERY', 'ADJUST(Positive)' or 'ADJUST(Negative)'. Read more about the different operations at the Flow outline section . Max length: 16

Response code for this part of the transaction. Only failed operations are entered into the error log, so this parameter will never contain the string 'OK'. Read more about response codes > Max length: 4

Response text message explains the error code and gives more detailed description of the error helping the merchant to find out why the transaction failed. Read more about response messages Max length: Custom

Textual description of which part of the system generated the error code. The error codes are divided into groups according to the source. Read more about error sources Max length: 16

Timestamp indicating when the operation in question was finished. This timestamp is generated on the Netaxept server.

Country of the IP address of the customer's browser connection, following ISO 3166-1 Alpha 2 code. For example: 'NO', 'SE', 'DK', 'FI'.

Indicates whether or not the country of the customer's IP address matches the country of the card Issuer.

Customer's browser information.

Timestamp indicating when the customer has visited in the payment window. This timestamp is generated on the Netaxept server.

Timestamp indicating when the customer has been redirected or has been attempted to redirect from the payment window to the URL specified by the merchant. This timestamp is generated on the Netaxept server. Check this parameter to verify when Netaxept redirected the customer or tried to redirect.

Sub-merchant's merchant category code (MCC) assigned by the acquirer.

Sub-merchant's marketing name (15), address (12), city (13), postal code (10) and country (3). All subfields need to be left justified with trailing spaces (or padded from the right with blanks if necessary). For example:

Testi Oy Kaitalantie Helsinki 00510 FIN

Sub-merchant's merchant ID assigned by the acquirer or Payment facilitator.

Tells the name of the wallet based payment method being used. The actual payment card used for the payment can be found in CardInformation.PaymentMethod.

Invoice ID generated for each invoice. Usually one invoice transaction has one invoice ID, however, if you run for example a partial capture for an invoice transaction, an invoice with its own invoice ID will be created.

Amount captured on this transaction, described as the lowest monetary unit for the given currency without punctuation marks. For example: 100,00 NOK is noted as '10000' and 9.99 USD is noted as '999'. Check this parameter to confirm the payment is made.

Amount credited on this transaction, described as the lowest monetary unit for the given currency without punctuation marks. For example: 100,00 NOK is noted as '10000' and 9.99 USD is noted as '999'.

Indicates whether or not the authorization of this transaction has been cancelled.

ID given to an authorized transaction by the issuer.

Indicates whether or not this transaction has been authorized. Transaction is flagged as authorized if it has been processed with AUTH or SALE call. Max length: Custom

Only used for the payment method SEPA Direct Debit via PPRO. Indicates if transaction has received chargeback. The amount is described as the lowest monetary unit for the given currency without punctuation marks. For example: 100,00 EUR is noted as '10000'.

Aggregated amount captured in the transactions displayed.

Aggregated amount credited in the transactions displayed.

Aggregated amount positively adjusted in the transactions displayed.

Aggregated amount negatively adjusted in the transactions displayed.