Register
Description
The purpose of the Register call is to send all the data needed to complete a transaction to Netaxept. During the registration, Netaxept will accept and store the transaction, and reply with a transaction ID that refers to the transaction in question.
The input data is organized into a RegisterRequest, and the output data is formatted as a RegisterResponse. Example of the REST Register call and the corresponding response can be found in the "Sample code" section.
API call
REST
- Test: https://test.epayment.nets.eu/Netaxept/Register.aspx
- Production: https://epayment.nets.eu/Netaxept/Register.aspx
Please note that Server Name Indication (SNI) is required when connecting to Netaxept test environment URL https://test.epayment.nets.eu
Web Services
Register (string merchantId, string token, RegisterRequest request) -> RegisterResponse
Input parameters
Available input parameters in the Register are listed below. Please see proper validation rules at the “Validation” section.
Authentication (Required)
| Merchant ID | REST: merchantId | WebServices: merchantId |
| Required | Validation: Numeric | MaxLength: 8 |
| Unique ID generated by Nets for identifying each merchant in Netaxept. You need to send this ID to Netaxept along all API calls. Test accounts may have a maximum length of 8 digits, while production accounts has a maximum length of 6 digits. | ||
| Token | REST: token | WebServices: token |
| Required | Validation: Reference | MaxLength: 32 |
| Shared secret between the merchant and Netaxept that is used to authenticate the merchant and is provided to you by Netaxept. | ||
RegisterRequest (Required)
| Service type | REST: serviceType | WebServices: ServiceType |
| Optional | Validation: Alpha | MaxLength: 1 |
| Indicates the payment window to be used for this transaction. If omitted, Netaxept will use the default value "B". Valid values are:
| ||
| Transaction ID | REST: transactionId | WebServices: TransactionId |
| Optional [Netaxept generated] | Validation: Reference | MaxLength: 32 |
| Unique ID identifying each transaction within the Merchant ID in Netaxept at any point. If omitted, Netaxept will generate a unique Transaction ID for the transaction and return it in the Register response. | ||
| Transaction reference number | REST: transactionReconRef | WebServices: TransactionReconRef |
| Optional | Validation: Reference | MaxLength: 25 |
| 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 Transaction reference number sent to Netaxept along the Register call will serve as a default reference unless the new transaction reference number is sent along the Process call. | ||
| Description | REST: description | WebServices: Description |
| Optional | Validation: Custom | MaxLength: 4000 |
| Free-format textual description of this part of the transaction / operation determined by the merchant and displayed to the merchant in Netaxept Admin. In Netaxept Admin, the field displayes also an IP address and/or a username that has been used for the transaction. Please note that this is different than OrderDescription that is displayed to the end-customer on a payment window. | ||
| IsApp | REST: isApp | WebServices: isApp |
| Optional (used for Vipps) | Validation: Boolean | MaxLength: 10 |
| If set to "true", the Customer phone number is not mandatory for Vipps payment when ServiceType=M. | ||
| Digital wallet ID | REST: digitalWalletId | WebServices: digitalWalletId |
| Optional (required for delegated authentication app transactions) | Validation: String | MaxLength: 32 |
| If you wish to apply delegated authentication exemption to the transaction originated from merchant´s certified delegated authentication app, pass the card scheme certified value in this parameter together with scaExemption=3. | ||
Order (Required)
This section contains order details for the transaction.
| Order number | REST: orderNumber | WebServices: Order.OrderNumber |
| Required | Validation: Alpha with characters within range hex 21 to hex 7E (decimal 33 to decimal 126) in the ASCII table. | MaxLength: 32 |
| Transaction identifier defined by the merchant. Nets recommends to generate each transaction a unique order number but if wanted the same order number can be used several times. Digits and letters are allowed except special characters and scandinavian letters like Æ Ø Å Ä Ö. | ||
| Currency code | REST: currencyCode | WebServices: Order.CurrencyCode |
| Required | Validation: Alpha | MaxLength: 3 |
| Currency code for the transaction amount, following ISO 4217. For example "NOK", "SEK", "DKK", "EUR" and "USD". | ||
| Amount | REST: amount | WebServices: Order.Amount |
| Required | Validation: Numeric | MaxLength: 10 |
| 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 max amount possible for this value is to specify 2147483647, the maximum value of a signed 32 bit integer. Amount is optional if updateStoredPaymentInfo="true" is set in the Register call. | ||
| Force 3D Secure | REST: force3DSecure | WebServices: Order.Force3DSecure |
| Optional | Validation: Boolean | MaxLength: 10 |
| If set to "true", the customer must be fully authenticated by 3D Secure or equivalent authentication method to be able to complete the transaction. | ||
| Update stored payment info | REST: updateStoredPaymentInfo | WebServices: Order.UpdateStoredPaymentInfo |
| Optional | Validation: Boolean | MaxLength: 10 |
| 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, and instead of "Pay" button, the customer will see "Register" button as 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 | ||
| SCA exemption | REST: SCAExemption | WebServices: Order.SCAExemption |
| Optional | Validation: Alpha | MaxLength: 1 |
| 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:
| ||
| Validate customer | REST: validateCustomer | WebServices: Order.ValidateCustomer |
| Optional (used for Walley) | Validation: Boolean | MaxLength: 10 |
| If set to "true", it triggers SCA for Walley. As of today, this functionality works for the following countries:
When using this parameter, Transaction ID needs to be at least 21 characters. | ||
| Delivery date | REST: deliveryDate | WebServices: Order.DeliveryDate |
| Optional | Validation: Numeric | MaxLength: 8 |
| Date when Netaxept automatically executes the Process(Capture) call for the transaction, on 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 the taken care of by Netaxept. | ||
| Authorization type | REST: authType | WebServices: Order.AuthType |
| Optional (required for AFD / EV charging transactions) | Validation: Alpha | MaxLength: 32 |
| Indicates the authorization type. These features are in pilot phase with selected merchants. Please contact Nets before starting to use them. Valid values are:
| ||
| Goods | REST: | WebServices: Order.Goods |
| Optional (required for invoice) | Validation: Custom | MaxLength: N/A |
| The Goods list is an array of Item entries, one Item representing one product line / row. The Goods object is a mandatory object for invoice and instalment payment methods implemented via Netaxept. Read more about invoices and instalments For each Item in the Goods list, the following parameters are available. When working with REST interface, the format of these 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. In Web Services, numberOfGoods parameter is not used.
Amount 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. ArticleNumber A string that specifies the unique identifier for the item. Discount Discount for the item. Use the "." character as delimiter. Handling Specifies whether the handling is included in the item data, on the boolean format: true or false. IsVatIncluded Specifies whether the VAT is included in the item price, on the boolean format: true or false. Quantity Quantity of items bought in the specific Item object. Shipping Specifies whether the shipping is included in the item data, on the boolean format: true or false. Title A string that specifies the descriptive name or description for the item. UnitCode Assigned to each item. The unit code should start from 0 and it will get incremented based on the number of items. VAT 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 passing a VAT, the IsVatIncluded needs to be set to "true". When refunding the payment, the VAT% for the item to be refunded should match the VAT% of the corresponding original item. | ||
Environment (Required if Web Services)
| Web service platform | REST: N/A | WebServices: Environment.WebServicePlatform |
| Required (if Web Services) | Validation: Custom | MaxLength: N/A |
| Indicates which Web Services technology is used when calling Netaxept. This field is required to allow us to track problematic technologies which may 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 a SecurityException. Check our whitelisted and blacklisted Web Services platforms here. 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" to get the Register call through, problems will probably occur in the future if you do this. | ||
| Operating system | REST: OS | WebServices: Environment.OS |
| Optional | Validation: Custom | MaxLength: N/A |
| Indicates which operating system is being used on the merchant's platform. | ||
| Language | REST: environmentLanguage | WebServices: Environment.Language |
| Optional | Validation: Custom | MaxLength: 1500 |
| Indicates which programming language is being used to implement the merchant's solution. | ||
Terminal (Optional)
This section contains information about the behavior of the payment window. It is optional for call centre transactions (that is, when the ServiceType is set to "C").
| Order description | REST: orderDescription | WebServices: Terminal.OrderDescription |
| Optional | Validation: Custom | MaxLength: 1500 |
| Free-format textual description determined by the merchant for the transaction. This can be HTML-formatted. If you are using 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. | ||
| Language | REST: language | WebServices: Terminal.Language |
| Optional | Validation: Custom | MaxLength: 5 |
| 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. Valid values are:
| ||
| Redirect URL | REST: redirectUrl | WebServices: Terminal.RedirectUrl |
| Optional | Validation: URL | MaxLength: 1024 |
| Indicates where to send the customer after the transaction passed 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 centre transactions. | ||
| Payment method action list | REST: paymentMethodActionList | WebServices: Terminal.PaymentMethodActionList |
| Optional | Validation: Custom | MaxLength: N/A |
| The paymentMethodActionList is an array of PaymentMethodAction entries. That is, JSON objects, each representing a rule on how to handle payment method, fee and certain actions for selected payment method. For example: [{"PaymentMethod":"Visa","Fee":"100"},{"PaymentMethod":null,"Fee":"200"}] Any rules here will overrule the corresponding rules set in Netaxept Admin's "Issuer fees" section. For each rule in the action list, the following parameters are available:
PaymentMethod Payment methods that are displayed in the payment window in the specified order. The payment methods should be comma separated. If omitted, all payment methods will be displayed in the default order. Also, it should be noted that the payment window will only display the payment methods that are activated for the merchant. Valid values are: Payment cards
Direct banks
Invoice and instalment
Gift cards and prepaid solutions
Wallet based payment methods
Other
Name The name of the payment method. Fee Fee set to the payment methods, 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. The fee will apply to all payment methods if no PaymentMethod value is specified. For example: [{"PaymentMethod":null,"Fee":"200"}] CardType Type of the card(s) for which the fee or rule is defined. Valid values are: Debit, Credit, All. "All" is the default value. CardOrigin The origin of the country issuing the card(s) for which the fee or rule is defined. Valid values are: International, Domestic, EU, NonEU, All. "International" is the default value. CardProductType Product type of the card(s) for which the fee or rule is defined. Valid values are: Private, Corporate, All. "All" is the default value. BIN The 6 digits at the beginning of the card number for which the fee or rule is defined. For example: "123456". Action The action you want to execute to the transactions that meet the rule(s) you have defined. Valid values are:
| ||
| Payment method list | REST: paymentMethodList | WebServices: Terminal.PaymentMethodList |
| Optional | Validation: Custom | MaxLength: N/A |
| This parameter is deprecated, and we strongly urge that you do implementation through the Payment method action list (above). Indicates which payment methods to display in the payment window and in which order. The payment methods should be comma separated. If omitted, all payment methods will be shown in the default order. Also, it should be noted that the payment window will only show payment methods that are activated for the merchant. The list of the valid payment methods is specified in the Payment method action list (above). An example of a valid payment method list is: MasterCard,Visa,Dankort | ||
| Fee list | REST: feeList | WebServices: Terminal.FeeList |
| Optional | Validation: Custom | MaxLength: N/A |
| This parameter is deprecated, and we strongly urge that you do implementation through the Payment method action list (above). Specifies the fee set to certain payment methods. For the fee list, which is per transaction, to work as expected, the paymentMethodList must be present. The number of entries in the fee list must match the number of entries in the paymentMethodList. An example of a feeList is: 100,200 Given a paymentMethodList of Visa,MasterCard, Visa transactions will have a 100 fee applied and Mastercard transactions will have a 200 fee applied. The amount format is in the lowest monetary unit for the given currency. | ||
| VAT | REST: terminalVat | WebServices: Terminal.Vat |
| Optional | Validation: Numeric | MaxLength: 10 |
| 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. Please note that VAT is included in the original amount, meaning that Netaxept regards this amount as a 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. | ||
| Automatic authorization | REST: autoAuth | WebServices: Terminal.AutoAuth |
| Optional | Validation: Boolean | MaxLength: 10 |
| 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 allows merchants to send out a payment request using other means than a reqular 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
| ||
| Automatic sale | REST: autoSale | WebServices: Terminal.AutoSale |
| Optional | Validation: Boolean | MaxLength: 10 |
| 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 allows merchants to send out a payment request using other means than a reqular 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
| ||
| Terminal design | REST: terminalDesign | WebServices: Terminal.Design |
| Optional | Validation: Custom | MaxLength: 128 |
| Name of the terminal template you have created in Netaxept Admin and that will be used for the payment. With this parameter you can control the look 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 | REST: templateData | WebServices: Terminal.TemplateData |
| Optional | Validation: Custom | MaxLength Key: 64 |
| 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". When using REST, use the field templateData which expects JSON data on the following form: {"key1":"value1","key2":"value2"}. Remember, that like all other input values, this field needs to be properly URL encoded. When using Web Services, create an array of KeyValuePair entries, and set the Key and Value fields as desired. | ||
| Terminal single page | REST: terminalSinglePage | WebServices: Terminal.SinglePage |
| Optional | Validation: Boolean | MaxLength: N/A |
| If set to "true", Netaxept hosted payment window changes from two-page to single page. Because of the nature of this mode, single page payment window works only for card payments, and excludes 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 entering the card number, the selected card type will light up as visual feedback to the customer. | ||
| Terminal layout | REST: terminalLayout | WebServices: Terminal.Layout |
| Optional | Validation: Custom | MaxLength: N/A |
| Layout of the payment window to be used for the transaction. Valid values are:
| ||
| Redirect on error | REST: redirectOnError | WebServices: Terminal.RedirectOnError |
| Optional | Validation: Boolean | MaxLength: 8 |
| If set to "true", Terminal will redirect back to the merchant site if error occurs. | ||
Customer (optional)
This section contains information about the end-customer. The data entered will be shown only to the merchant via the Query call and in Netaxept Admin.
| Customer number | REST: customerNumber | WebServices: Customer.CustomerNumber |
| Optional | Validation: Custom | MaxLength: 64 |
| The customer's ID that can be used to identify the end-customer or the customer group. The same customer number can be used several times. | ||
| Customer email | REST: customerEmail | WebServices: Customer.Email |
| Optional (required if direct banks via Paytrail) | Validation: Custom | MaxLength: 128 |
| The customer's email address. | ||
| Customer phone number | REST: customerPhoneNumber | WebServices: Customer.PhoneNumber |
| Optional | Validation: Custom | MaxLength: 64 |
| The customer's phone number. The phone number should be given on the format of +[country code][phone number]. For example: +4712345678, +469876543, +35850123456. | ||
| Customer first name | REST: customerFirstName | WebServices: Customer.FirstName |
| Optional (required if DnBNorDirectPayment or direct banks via Paytrail) | Validation: Custom | MaxLength: 64 |
| Customer's first name. | ||
| Customer last name | REST: customerLastName | WebServices: Customer.LastName |
| Optional (required if DnBNorDirectPayment or direct banks via Paytrail) | Validation: Custom | MaxLength: 64 |
| Customer's last name. | ||
| Customer address 1 | REST: customerAddress1 | WebServices: Customer.Address1 |
| Optional (required if DnBNorDirectPayment or direct banks via Paytrail) | Validation: Custom | MaxLength: 64 |
| Customer's address. | ||
| Customer address 2 | REST: customerAddress2 | WebServices: Customer.Address2 |
| Optional | Validation: Custom | MaxLength: 64 |
| Customer's secondary address. | ||
| Customer post code | REST: customerPostcode | WebServices: Customer.Postcode |
| Optional (required if DnBNorDirectPayment or direct banks via Paytrail) | Validation: Custom | MaxLength: 16 |
| Customer's postal code. | ||
| Customer town | REST: customerTown | WebServices: Customer.Town |
| Optional (required if DnBNorDirectPayment or direct banks via Paytrail) | Validation: Custom | MaxLength: 64 |
| Customer's city. | ||
| Customer country | REST: customerCountry | WebServices: Customer.Country |
| Optional (required if invoice, Paypal or direct banks via Paytrail) | Validation: N/A | MaxLength: N/A |
| Customer's country, following ISO 3166-1 Alpha 2 code. For example: "NO", "SE", "DK", "FI". | ||
| Customer is company | REST: customerIsCompany | WebServices: customer.CustomerIsCompany |
| Optional (used for Collector and Klarna) | Validation: Boolean | MaxLength: 10 |
| If set to "true", only business-to-business payment window (company related fields) will be displayed to the customer. Required if B2B payment window is to be requested. | ||
| Customer social security number | REST: customerSocialSecurityNumber | WebServices: Customer.SocialSecurityNumber |
| Optional | Validation: Custom | MaxLength: 20 |
| Customer's social security number. | ||
| Customer's company name | REST: customerCompanyName | WebServices: Customer.CompanyName |
| Optional | Validation: Custom | MaxLength: 128 |
| The customer's company name. | ||
| Customer's company registration number | REST: | WebServices: Customer.CompanyRegistrationNumber |
| Optional | Validation: N/A | MaxLength: N/A |
| The business ID of the customer's company. | ||
| Customer notification mode | REST: | WebServices: Customer.NotificationMode |
| Optional (used for Collector and Klarna) | Validation: Custom | MaxLength: 32 |
| Indicates the way how invoice is to be sent.
| ||
CardInfo (optional)
This section contains card data needed to complete the transaction. It is only required for call centre transactions (that is, when the Service Type is set to "C").
| PAN | REST: pan | WebServices: CardInfo.Pan |
| Optional | Validation: Numeric | MaxLength: 20 |
| The card number without spaces to be used for this transaction. | ||
| Expiry date | REST: expiryDate | WebServices: CardInfo.ExpiryDate |
| Optional | Validation: Numeric | MaxLength: 4 |
| The expiry date for the card to be used for this transaction, on the format MMYY. | ||
| Security code | REST: securityCode | WebServices: CardInfo.SecurityCode |
| Optional | Validation: Numeric | MaxLength: 4 |
| 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) is the last 3 digits printed on the back of the card. The American Express verification code (CID) is a 4-digit number printed on the front of the card. | ||
Recurring (optional)
This section contains the information needed to save card details for subsequent transactions and perform later transactions on a card. It is only required when merchant uses our tokenization services. Read more about the tokenization services
| Recurring type | REST: recurringType | WebServices: Recurring.Type |
| Optional (required if panHash is supplied) | Validation: Alpha | MaxLength: 1 |
| Defines the tokenization type. Valid values are: Initial transaction
Subsequent transaction
| ||
| Recurring frequency | REST: recurringFrequency | WebServices: Recurring.Frequency |
| Optional (required if recurringType = "R") | Validation: Numeric | MaxLength: 5 |
| Indicates how often the merchant is allowed to charge a card based on the agreement made with the customer, in days. A frequency of "1" will allow the merchant to make recurring payments on the card every day. Minimum frequency is 0 day, meaning no limitation on the number of transactions per day. Maximum is 365 days. | ||
| Recurring expiry date | REST: recurringExpiryDate | WebServices: Recurring.ExpiryDate |
| Optional (required if recurringType = "R") | Validation: Numeric | MaxLength: 8 |
| Date when the agreement made between the merchant and the customer expires. The date is described on the format YYYYMMDD. | ||
| Recurring transaction type | REST: recurringTransactionType | WebServices: Recurring.RecurringTransactionType |
| Optional (required if recurringType = "M") | Validation: Alpha | MaxLength: 1 |
| Indicates the MIT transaction type (excl. recurring payment). Valid values are:
| ||
| PanHash | REST: panHash | WebServices: Recurring.PanHash |
| Optional (required if subsequent transaction) | Validation: Base64 | MaxLength: N/A |
| The token value used in subsequent transaction 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 a frontend system exposed to the internet or directly on mobile devices. | ||
| PanHash secret | REST: panhashSecret | WebServices: Recurring.PanHashSecret |
| Optional | Validation: Base64 | MaxLength: 20 |
| Merchants can add an extra layer of protection to their panHash parameters by adding a secret token linked to these parameters. | ||
| Use 3D-Secure | REST: recurringUse3DS | WebServices: Recurring.Use3DS |
| Optional | Validation: Boolean | MaxLength: 5 |
| If set to "true", together with recurringType=S, serviceType = B or M 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. | ||
LoyaltyInformation (optional)
This section is optional and contains the information needed to offer loyalty benefits for customers shopping online. It is only required when merchant uses our loyalty services.
| Customer loyalty ID | REST: customerLoyaltyId | WebServices: LoyaltyInformation.CustomerLoyaltyId |
| Optional | Validation: Custom | MaxLength: 32 |
| Membership identifier for loyalty program. The ID is validated only by its length which can be 10 digits. The same ID can be used several times. | ||
| Transaction loyalty amount | REST: transactionLoyaltyAmount | WebServices: LoyaltyInformation.TransactionLoyaltyAmount |
| Optional | Validation: Numeric | MaxLength: 32 |
| 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". | ||
| Payment method benefit amount | REST: paymentMethodBenefitAmount | WebServices: LoyaltyInformation.PaymentMethodBenefitAmount |
| Optional | Validation: Numeric | MaxLength: 32 |
| Eligible amount for payment method benefit, described as the lowest monetary unit for the given currency without punctuation marks. For example: 100,00 EUR is noted as "10000". | ||
| Card link | REST: enableCardLink | WebServices: LoyaltyInformation.EnableCardLink |
| Optional | Validation: Boolean | MaxLength: 8 |
| If set to "true", the card will be enrolled in CardLink service while saving card details for future. With CardLink service merchant is able to identify and award their loyalty customers across different sales channels. When using enableCardLink=true, updateStoredPaymentInfo needs to be set to "true". Parameter customerLoyaltyId is optional, however, if not specified by merchant and present, the unique value will be created and returned to merchant. | ||
PaymentFacilitatorInformation (optional)
This section is optional and contains sub-merchant data needed to complete the transaction. It is only required and can be used for companies acting as Payment facilitators for their sub-merchants.
Netaxept and Nets acquiring support the Payment Facilitator model in eCommerce for Visa and Mastercard. The Payment Facilitator acts as a single point of contact for their sub-merchants and is responsible for payouts and agreements towards the sub-merchants.
| MCC | REST: PaymentFacilitatorMCC | WebServices: PaymentFacilitator.MCC |
| Required (if Payment facilitator) | Validation: Custom | MaxLength: 4 |
| Sub-merchant's merchant category code (MCC) assigned by the acquirer. | ||
| Merchant descriptor | REST: PaymentFacilitatorMerchantDescriptor | WebServices: PaymentFacilitator.MerchantDescriptor |
| Required (if Payment facilitator) | Validation: Custom | MaxLength: 64 |
| 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 ID | REST: PaymentFacilitatorSubMerchantId | WebServices: PaymentFacilitator.SubMerchantId |
| Required (if Payment facilitator) | Validation: Custom | MaxLength: 15 |
| Sub-merchant's merchant ID assigned by the acquirer or Payment facilitator. | ||
AvtaleGiro (optional)
This section is only used when using AvtaleGiro (direct debit) as a payment method. To give the customer this option, the following parameters need to be supplied along the Register call.
| KID (Customer ID) | REST: avtaleGiroKid | WebServices: AvtaleGiro.Kid |
| Required (if AvtaleGiro) | Validation: Numeric Validated by AvtaleGiro to a legal KID number | MinLength: 2 MaxLength: 25 |
| The customer's ID that can be used to identify the customer. | ||
| Account number | REST: avtaleGiroAccountNumber | WebServices: AvtaleGiro.AccountNumber |
| Optional (will be fetched from merchant's settings if not sent) | Validation: Numeric Validated by AvtaleGiro to a legal account number | MinLength: 11 MaxLength: 11 |
| 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. | ||
| Company name | REST: avtaleGiroCompanyName | WebServices: AvtaleGiro.CompanyName |
| Optional (will be fetched from merchant's settings if not sent) | Validation: N/A | MaxLength: 256 |
| The company name of the webshop. The name must match exactly 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. | ||
| Amount limit | REST: avtaleGiroAmountLimit | WebServices: AvtaleGiro.AmountLimit |
| Optional (suggestion will be calculated if not sent) | Validation: Numeric | MaxLength: 16 |
| The suggested amount limit of this AvtaleGiro agreement between the customer and his bank. That is, the maximum amount of each capture. Please note that the amount limit can be changed by the customer when they are signing the AvtaleGiro agreement. | ||
Output parameters
Available output parameters in the RegisterResponse are listed below.
| Transaction ID | REST: TransactionId | WebServices: RegisterResponse.TransactionId |
| Required | Validation: Reference | MaxLength: 32 |
| Unique ID identifying each transaction within the Merchant ID in Netaxept at any point. If merchant has generated Transaction ID by themselves and sent it along the Register call to Netaxept, the same Transaction ID value is returned in the Register response. If omitted, Netaxept will generate a unique value for the transaction in question and return it in the Register response. | ||
| Wallet URL | REST: WalletURL | WebServices: RegisterResponse.WalletURL |
| Optional | Validation: N/A | MaxLength: N/A |
| The app switch URL to be used to enable app-switching from merchant app to the payment method's app. | ||
Exceptions and response codes
If something goes wrong when communicating between your system and Netaxept or in the middle of the payment process, Netaxept declines the transaction and returns an exception. All exceptions are wrapped in the outer Exception tag, with an Error tag inside. The type (xsi:type) of the Error tag indicates which exception it is. In most cases, the exception includes the error code indicating the error, as well as an error message explaining the code. The Register call can throw the following exceptions. Read more about exceptions and response codes
- AuthenticationException
- BBSException
- MerchantTranslationException
- UniqueTransactionIdException
- GenericError
- ValidationException
- SecurityException
Next step
Send the customer to the payment window
If you used service type "B" (Netaxept hosted payment window) or "M" (Merchant hosted payment window) in the Register call, use the Terminal call to send the customer to the payment window for entering their payment method information. Read more about the Terminal call
Process Call Centre transaction
If you used service type "C" in the Register call, use the Process (Auth) call to authorize the payment or the Process (Sale) call to authorize and capture the payment. Read more about the Process calls
Send payment link to the customer
If you don't have a webshop, but have done the registration successfully, you can send a payment link to the customer for example by email, SMS or by other text media. This payment link URL follows the same format as the URL used with the Terminal call. If you decide to send payment links to your customers, you need to set the AutoAuth or AutoSale (automatic authorization or automatic sale) to "true" in the Register call. Read more about Link Payment