Page Comparison

Lack of Payment Status Query implementation

When everything goes as planned the payments are confirmed by the payer's browser when they return to the webstore; the payer is transferred by a redirect to the pmt_okreturn -URL that was in the payment process initiation.

Sometimes the payer does not return to the webstore. Loss of connection could be one cause for such event. Sometimes there could be other reasons for the payment confirmation to fail. That's why we recommend that every web store should integrate our Payment Status Query API so the web store platform can query the status of the payment if needed.

Hashing pitfalls

This section is meant to troubleshoot hashing problems. Information about how to generate hash can be found from here Hash Generation .

It is highly recommended to copy and paste e.g. the secret key through for example Notepad or some other plain text editor. It is common problem that the hash calculation fails simply because there are invisible whitespaces or line feeds / carriage returns in the value when it has been copied from rich text editors (e.g. MS Word) or email clients (e.g. MS Outlook).

At first, test your hash calculation with messages that have NO special characters, umlauts or other than US-ASCII character set, for that matter. That is, first try with an order without any special or control characters and without European national letters like ÄÖÅ. If hash mismatches with messages that contain any of the aforementioned characters, it is obvious there is something wrong with characters set (something else is used for calculation than told in the message):

pmt_charset field tells the character set that has been used to calculate the hash value for input data. Currently supported values are: ISO-8859-1, ISO-8859-15 and UTF-8. Hash calculation is always done from binary data, which is not obvious in some programming languages. You must handle the transformation from character based data to binary data before hash calculation correctly. If it’s not possible to define the character set for hash calculation function, you must find out which character set is used internally by the hash algorithm. For example character "Ä" have different hash values for UTF-8 and Latin-1 character sets.

pmt_charsethttp field tells the character encoding of the input data. Svea Payments payment interface handles HTTP request parameters according to this character encoding. Practically this is the character set reported by the browser, when you’re browsing the checkout pages in the webstore.

Please make sure that the string to be hashed does not contain two consecutive & chars (ampersands). Each field in hash string should be followed by exactly one ampersand. Empty or null fields are never put in hash string. The last character of the hash string should also be &.

Please check the parameter list again from the interface definition document. It is different from the list of parameters to be passed as all the parameters are not mandatory and some are not necessary to be “signed” by hash calculation.