Common errors in legacy integrations

ExistingPayment (Payment id is invalid)

Web store's account id (pmt_sellerid) and payment id (pmt_id) form a unique key pair for identifying the payment event in a New Payment Request. Therefore a payment id that the web store has already used before can not be used again with the same Web Store's account id. In general, a pmt_id is registered in the Svea Payments service at the moment it is received as a part of a Svea Payments payment request. That is, the basic rule is that a formerly received pmt_id cannot be reused even if the buyer cancels or interrupts the payment process. This applies for both Svea Payments test and production environments.

If the payment id is calculated or derived e.g. from the web store's order numbers and the web store is reinstalled or moved to a new installation, webstore must ensure that either
the order numbering starts from previously unused number or
the pmt_id calculation uses (new) calculation rules that produce pmt_id-values that do not conflict with the previously used pmt_id-values

E.g. in Svea Payments payment module for WooCommerce the web store admin can choose to add a separate prefix for the payment ids. Therefore even if the web store order numbering has been reset, the pmt_id calculation rules in the module program code do not need to be changed but adding (or changing) the prefix in the store admin is sufficient.

An example of a scenario where the problem occurs

The web store forms Svea Payments payment ids using a rule pmt_id = {pmt_orderid} + "ABC".

Before opening the web store for customers the vendor makes a test purchase (pmt_orderid=0001, pmt_id=0001ABC) which is received and registered in the Svea Payments service. After a successful test the vendor clears the orders database in the store and opens the store for actual customers. When the first customer makes an order the web store starts order numbering again from the start (1) and forms a pmt_id "0001ABC" for the order.

As the pmt_id "0001ABC" had already been used before, Svea Payments service does not accept the order and returns an error. As the payment fails the web store rejects the order and order number 1 is left unused for the next order. In the future all the orders are given the order number 1 and pmt_id "0001ABC" and as they all are always rejected no new payments can be successfully made before the order numbering has been manually changed to start from a bigger order number.

Hash value is invalid

"Errors in Payment message, hash value is invalid"

This error can occur with all interface requests that require hash verification.

The hash is generated by first concatenating message fields and a secret key into a single string where each field is separated by a & character. Difference in one character results into different hash value. The secret key is never sent as part of the message. Its only purpose is to be a secret part of the string from which the hash is calculated from, only known by web store and Svea Payments. This means that even if outsider could get their hands on all the information in the message, they can not generate a hash value that would match the hash value calculated in the receiving end because of the unknown salt that the secret key is.

Yet, web store software or a payment module can still generate a invalid hash. For example:

• The string is missing one or more fields specific to the API being called.

• The string contains fields that is not supposed to

• The fields have not been concatenated in correct order.

• The web store ID or secret key are incorrect (e.g. test and production environment have completely separate credentials). For more help, see section Tips for hash calculation

• Some fields contain whitespaces or control characters that were not part the message but have been taken into account when creating the string; or the other way around.

• The message fields contain characters outside US-ASCII character set and at the same time the pmt_charset contains different charset that actually have been used for the hash calculation. For example, the message field pmt_charset=UTF-8 but the web store software calculated hash using ISO-8859-15 character set. This way for example umlauts and em dash etc. result into different hash values at the receiving end. For example character 'ä' has value 'c3e4' in UTF-8 and 'E4' in ISO-8859-15.

In addition, when the product information is copy pasted from rich text editors (for example Microsoft Word) to the web store, some special characters might cause problems later in the hash calculation since also product specific information (for example pmt_row_nameN or pmt_row_descN) is part of the string from which the hash is calculated from. These special characters might be taken into account when calculating the hash but at the same time they are not visible in the web store and are not sent as part of the pmt_row... message field values.

To tackle these special character issues etc., it is highly recommended that the webstore sanitizes the field values for both hash calculation and the request values sent to Svea Payments. This is also kind of a security enhancement.

To debug hash issues even in production environment (but only for a short period of course), web store can use generic test credentials (sandbox credentials) and the resulting diagnostics test page. One can the compare the string they used for hash calculation in their code and the string Svea Payments used. See next page.

The string in the diagnostics test page:

Open

The string from webstore logs:

Read more: Hash Generation

Skip to contents in this page