This documentation is deprecated and only available for supporting old/legacy integrations using for example hashes.
New documentation can be found here: Home
Svea S2S invoice
HOX This part of Invoicing with a Finnish personal ID
through Svea’s Webpay-interface is used only by separate agreement
USING A FINNISH PERSONAL ID TO CREATE A NEW INVOICE
Â
Calling Payment API
REQUEST:
The V4 interface is used in a server-to-server type fashion. The web store transfers the payment data directly as an HTTP POST -request. The web store can choose which http client product to use for this.
TEST:Â http://test1.maksuturva.fi/NewChargeWithTokenActionExtended.pmt
PRODUCTION:Â https://payments.maksuturva.fi/NewChargeWithTokenActionExtended.pmt
The general instructions for the V4 payment interface can be found in Svea Payments’ integration guidelines: http://docs.sveapayments.fi/api/payment-api/payment/.
In the request, the version information and pre-selected payment method should have the following values in the interface information:
pmt_version=4204
pmt_paymentmethod=FI70
pmt_token=< the Finnish personal ID of buyer/invoice recipient >
Â
AUTHENTICATING THE REQUEST:
You can use one of the following:
Hash value:
pmt_hash: Calculate hash value as described in general instructions for the V4 payment interface.
While creating the string to be hashed, add pmt_token value after the pmt_sellercosts data
HTTP Basic Auth:
Use merchant's seller_id as the username and secret key as the password for a standard HTTP Basic Auth Header.
Exclude parameters pmt_hash and pmt_hashversion from the request
Skip to contents in this page
RESPONSE:
Example of an OK response:
Â
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<chargeWithTokenResponse>
   <pmt_action>NEW_PAYMENT_EXTENDED</pmt_action>
   <pmt_version>4204</pmt_version>
   <pmt_id>100000169</pmt_id>
   <pmt_reference>00000000001000002696</pmt_reference>
   <pmt_amount>50,00</pmt_amount>
   <pmt_currency>EUR</pmt_currency>
   <pmt_sellercosts>5,00</pmt_sellercosts>
   <pmt_paymentmethod>FI70</pmt_paymentmethod>
   <pmt_escrow>Y</pmt_escrow>
   <pmt_resultcode>00</pmt_resultcode>
   <pmt_hash>**** </pmt_hash>
</chargeWithTokenResponse>
Example of an error response:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<chargeWithTokenResponse>
 <pmt_resultcode>99</pmt_resultcode>
 <error name="pmt_userlocale" type="field">pmt_userlocale is invalid</error>
</chargeWithTokenResponse>
Error codes (pmt_errorcode) for a charge made with a token or for a status query:
ALREADY_PAIDÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â = Order has already been paid
ERRORÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â = Unknown error
ERROR_CARD_AUTHENTICATION_FAILEDÂ Â Â Â Â Â = 3DS authentication of card payment failed
ERROR_CARD_AUTHORIZATION_FAILEDÂ Â Â Â Â Â Â = Authorization of card payment failed
ERROR_CARD_AUTHORIZATION_TIMEOUTÂ Â Â Â Â Â = Authorization or charging of card payment timed out
ERROR_CARD_TOKENIZATION_FAILEDÂ Â Â Â Â Â Â Â = Card can not be used for recurring payments
ERROR_IN_PAYMENTÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â = Error in processing of payment
ERROR_IN_REQUEST_PAYER_DATAÂ Â Â Â Â Â Â Â Â Â Â = Error(s) in information that can be edited by buyer
ERROR_IN_REQUEST_TECHNICAL_DATAÂ Â Â Â Â Â Â = Error(s) in the technical data of the payment
ERROR_PAYMENT_INSTRUMENT_EXPIREDÂ Â Â Â Â Â = The payment instrument is not valid
ERROR_PAYMENT_INSTRUMENT_LIMIT_EXCEEDED= The limit for the given payment instrument is exceeded
ERROR_PAYMENT_INSTRUMENT_NOT_FOUNDÂ Â Â Â = The given payment instrument can not be found
ERROR_PAYMENT_METHOD_NOT_AVAILABLEÂ Â Â Â = The payment method chosen in the web store was not allowed
EXTERNAL_SERVICE_DENIEDÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â = The chosen payment service denied the transaction
EXTERNAL_SERVICE_ERRORÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â = The chosen payment service gave an error response
NOT_FOUNDÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â = Order can not be found
PAYER_CHOSE_METHOD_AND_VANISHEDÂ Â Â Â Â Â Â = Payer chose a payment method but has not paid
PAYER_INTERRUPTEDÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â = Payer cancelled the payment and returned to the web store
PAYER_VANISHEDÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â = Payer vanished without paying
WAITINGÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â = Waiting for information on possible payment
Status query for Invoice payment
Version 5 of Svea Payments’ normal status query interface can be used for the status query of tokenized payments or recurring payments made with tokens. General instructions can be found in here .
TEST:Â https://test1.maksuturva.fi/PaymentStatusQuery.pmt
PRODUCTION: https://payments.maksuturva.fi/PaymentStatusQuery.pmthere
In case the response includes the information pmtq_token, it is also added as last in the hash calculation. The response hash (pmtq_hash) will then include the following data:
pmtq_action
pmtq_version
pmtq_sellerid
pmtq_id
pmtq_amount
pmtq_returncode
pmtq_returntext
pmtq_sellercosts  (if included in the response)
pmtq_paymentmethod  (if included in the response)
pmtq_escrow  (if included in the response)
pmtq_certification  (if included in the response)
pmtq_paymentdate  (if included in the response)
pmtq_token  (if included in the response)
<secret key>
Â
Below an example of a situation, where tokenization and payment has been performed, settlement of the transaction has been made to the web store and lastly, a status query has been done:
Hash calculation
General instructions for hash calculation can be found in hash generation part
Testing
Recurring payments can be tested in Svea Payments customer test environment (http://test1.maksuturva.fi) with personal test credentials. Instructions for ordering the credentials can be found personal test credentials part
General instructions for integration testing can be found in here.
Â