FAQ

Do you have any questions? Just take a tour in our frequently asked questions section first and if you can’t find your answer feel free to contact us!

The Virtual Account Number (VAN, or Reference Number) is used by Kalixa Accept to match customer deposits into a bank account owned by either Kalixa Accept or the merchant with customer payment accounts. Each customer is assigned their own ProviderUserVAN by the system, which the customer must indicate in the “purpose of payment” section of their transfer request form.

How long you continue to use your previous payment system is up to you. Kalixa Accept only processes those transactions that are sent to our servers; any ‘splitting’ of payment processing responsibility between Kalixa Accept and another payment processor is handled by your system.

When initiating a withdrawal/outpayment, you have the option of pre-defining the amount or leaving the amount ‘open’ as a customer-editable field in the Payment Details page. In the case of an ‘open’ transaction, the Kalixa Accept Payment Service will notify your system of the amount requested before executing the payment, allowing you to apply limit or risk checks.

When the amount to be paid is predefined in the payment initiation (parameter grossAmount), the ‘amount’ section appears for the information of the customer, but it is a read-only (non-editable) field.

Yes, this is possible. Use the web method “getPaymentAccounts” to get the customer’s account details (provided that they are already registered with Kalixa Accept) and use the web method “initiatePayment” to initiate the transaction.

The IBAN and BIC fields are shown when Kalixa Accept has not been provided with the customer’s country (parameter countryCode2). If the customer’s country of residence is known, these fields are not shown.

This information is obtained via one of the various user-registration related web methods called by the merchant upon the customer’s first transaction. In order for these checks to function, the user’s registered country (parameter address) must be passed to Kalixa Accept by the merchant.

Yes. However, please be aware that not all payment methods support withdrawals/outpayments. For further details regarding the availability of withdrawals/outpayments via given payment method, please contact your Kalixa Accept Project Manager.

We use the Virtual Account Number (VAN, or Reference Number) to match customer deposits into a bank account owned by either Kalixa Accept or the merchant with customer payment accounts. Each customer is assigned their own ProviderUserVAN by the system, which the customer must indicate in the “purpose of payment” section of their transfer request form.

It’s up to you. Kalixa Accept only processes the transactions that are sent to our servers; any ‘splitting’ of payment processing responsibility between Kalixa Accept and another payment processor is handled by your system

When initiating a withdrawal/outpayment, you can pre-define the amount or leave the amount ‘open’ as a customer-editable field in the Payment Details page. In an ‘open’ transaction, the Kalixa Accept Payment Service will notify your system of the amount requested before executing the payment, allowing you to apply limit or risk checks.

A payment attempt is logged every time a user is redirected from the merchant’s site to the Kalixa Accept Redirect Payment pages. This check helps to counter money laundry operations by limiting the number of payment requests an individual may make over a specific time period. Logging takes place whether the attempt was successful or not, although the impact of breaching the limit on payment attempts can be configured in consultation with the Kalixa Accept Anti-Money-Laundry team.

This error implies that an element has either invalid data entered as its value, or there is an empty field where a value was expected. Ensure that all required elements have valid values, and that unused parameters have an ‘isNull = true’ property.

The Test Environment has a different URL, and payment initiation requests are made using different credentials from the Production Environment.

No, testing is done using the merchant’s template in the Test Environment first, and after tests are completed successfully, it becomes the Production Environment’s template.

Yes, although ideally you should access the Test Environment from your own test server or the PC from which your developer is testing or developing your website.

Payments on the Test Environment are initiated using ‘mock’ (fake) providers or using connections to the test environments of providers. The Test Environment never handles real money transactions.

.csr file: Certificate Request file .key file: Private Key file .cer file: Certificate Chain file These files should be sent to Kalixa Accept in an encrypted format and the security passphrase should be given by phone (NOT electronically).

No, normally this is only installed in the Production Environment.

No, not if the certificate has been issued by a standard Certificate Authority such as VeriSign or Thawte, as their public key is already included in our trusted store. However, if you are using an alternative Certificate Authority, a public key is needed. For more information and a list of those Certificate Authorities whose keys are already included in our trusted store, please contact your Project Manager.

Country, State, Locality, Organisation and organisational unit correspond to the merchant’s physical address. The common name, also known as the Fully Qualified Domain Name (FQDN) is the full name used for the host of the payment pages. Generally, this should be ‘payment.merchantname.com.’ where ‘merchantname’ is the main domain name of the merchant.

An Extended Validation certificate triggers visible security cues in the customer’s browser (such as a green address bar that displays the name of the organisation that owns the SSL certificate and the name of the Certificate Authority that issued it). An investigation of the EV certificate requesting entity is performed by the Certificate Authority before the certificate is issued. The following browsers that support this technology include Microsoft Internet Explorer 7, Mozilla Firefox 3, Safari 3.2, Opera 9.5, Safari 3.2, Flock 2.0, Google Chrome, and higher versions of these browsers.

Inclusion of dynamic content may impair the security of the Payment Redirect pages and distract the user from the payment process. In general, we don’t support or recommend dynamic content on the Payment Redirect pages. Please contact your project manager for more details.

We’ll support you in the implementation of your Payment Redirect template, but we can’t assist with template design. If you’re having difficulties in designing a custom Payment Redirect template, you could consider using the Kalixa Accept Standard template.

Yes. The language the Payment Redirect pages will be displayed in is determined by the parameter languageCode in web method “getRedirectDataRequest”. Languages currently available: English (en) German (de) Italian (it) Spanish (es) Swedish (sv) French (fr) Turkish (tr) Greek (el) Polish (pl) Norwegian (no) Danish (da) Catalan (ca) Czech (cs) Hungarian (hu) Dutch (nl) Portuguese (pt) Russian (ru) Slovenian (sl) Croatian (hr) Slovak (sk) Romanian (ro) Bulgarian (bg).

Please ensure that when calling the “getRedirectDataRequest” method that you specify the ISO two-character languageCode (e.g. en, de, fr). If this code is not specified, the default language for the payment controls is English.

No. For security reasons, images (and all other elements of the redirect payment pages) must be located on the secure payments server.

Yes, by using ProcessRedirectPaymentInPopup.

Yes, you may submit changes at any time to Kalixa Accept. Please note that while changes can be made quickly in the Test Environment, it may take some time to change elements in production due to security reasons. Contact your project manager or the Kalixa Accept Merchant Service team for more information.

Yes, the merchant can send Kalixa Accept a ‘favicon’ to be used on the Payment Redirect pages.

Yes. You may place whatever text you wish in this section of the HTML.

The WSDL documentation is available via the link in the KALIXA Integration Manual.

You can be notified on any state change you wish. KALIXA can provide a list of recommended notification states, as not all state changes may be significant from an order processing perspective.

While it’s possible to send reasons for these refusals, it is recommended that for the purposes of information clarity that you instead investigate such cases using the Payment Service Admin tool, where detailed information on the transaction in question is more readily available.

Whenever a customer attempts to complete a payment request, it is logged by the KALIXA Payment Service, and a suffix is added to the PaymentID to identify each attempt. Therefore, the third attempt for PaymentID 9876 would be displayed as 9876_03.

The merchant can define the time between authorisation and capturing of payments at initial setup. As capture requests are handled on a per-batch basis by the KALIXA servers, you can expect these capture notifications to arrive at a regular time each day.

The Payment Service Listener is used in both test and live phases.

No, it isn’t possible to receive notifications for the absence of certain actions.

The PS Listener doesn’t respond to requests. Rather, it contacts your web server by sending a notification there. If this notification isn’t answered (using one of the response codes listed in the Integration Manual), the PS Listener will by default attempt to resend the notification three more times, although this behaviour is configurable per merchant request.

Yes, this notification scheme can be configured.

The WSDL (Web Services Description Language) URL consists of a machine-readable list in XML of web services which are available on the Service URL. The Service URL is the address to which SOAP requests to call these web services should be sent.

Your logins to the Payment Service Admin only allow you to view transactions associated with your merchant/shop. Ensure that you have correctly entered your merchantID and shopID in your requests.

SOAP security headers are industry standard security protocols used to authenticate the client making a request to the Kalixa Accept Payment Service. They’re a mandatory part of any SOAP request made to Kalixa Accept, as they are integral to ensuring data security. For an example of a SOAP security header, please see the appendix to the Integration manual. The Kalixa Accept Payment Service is using the WS-Security standard as specified by OASIS standard V1.0 (for more details see http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss).

Due to security concerns, accounts for the back-office tool may only be assigned to real persons, not groups.

Your password must have at least:

  • Two capital letters
  • Two lower-case letters
  • Two numbers
  • Two special characters (such as ‘!’ or ‘?’)

A total of eight characters.

You are probably trying to access the back-offeice tool from a non-authorised IP address. Ensure that you are using an IP address that was approved by Kalixa for accessing the tool. You can verify your current IP on Windows machines by opening the command prompt and typing ‘ipconfig’.

Yes, as long as the connection takes place using a fixed IP address pre-registered with Kalixa Accept.

This is an online web application used by Kalixa Accept and our merchant partners to view, modify and execute actions upon payments initiated by end users. For more information on the capabilities and use of our bac-office tool, please contact your Kalixa Accept Project Manager.

In the interests of security a fixed IP address pre-registered with Kalixa Accept is required. Contact your ISP to receive a fixed IP address.

Yes. Please contact your Kalixa Accept project manager for a test credit card. Please note that we are unable to provide credit cards for testing purposes in the Production Environment.

Yes. If you choose to use your own merchant-subdomain for the payment pages, such as payment.merchantname.com, you’ll receive an IP address which you’ll have to configure in your DN. Contact your Internet Service Provider or Web Host for more information.

The parameter returnURL in the web method “getRedirectDataRequest” is used to define the ‘back’ button’s link.

You may wish to employ, at a minimum, IP restriction measures to ensure that only the KALIXA server can contact the Payment Service Listener. In addition, KALIXA supports WS-Security for SOAP and Basic Authentication for POX (HTTPS POST XML).

The bank code, account number, name of the bank, name of the account holder and physical address of the customer. In addition, the IBAN and BIC must be included if the customer is not in the same country as the merchant.

When the amount to be paid is predefined in the payment initiation (parameter grossAmount), the ‘amount’ section appears for the information of the customer, but it is a read-only (non-editable) field.

There’s no separate version of the WSDL for the Production Environment – the Test Environment’s implementation is identical.

The Kalixa Accept Payment Service will call the PaymentServiceListener (calling web method “handlePaymentStateChangedEvent”) multiple times until it receives a response. A list of the accepted response codes is available in the Kalixa Accept Integration Manual.

If your login attempts fail three consecutive times due to an incorrect password, you will have to wait one hour before trying again.

Yes

Kalixa Accept dates all transactions in UTC (coordinated universal time).

Yes, this is possible. To enable this feature, please contact your Integration Project Manager.