New payment V4 S2S (server-to-server)
Svea Payments' payment API can be called in two ways:
Preferred: payment parameters are sent as a server-to-server request, authenticated with HTTP Basic Auth
Deprecated: payment parameters are sent via payer's browser as a form submission and authenticated with a hash
This document describes the preferred server-to-server request.
General documentation related to payment API can be found here:
Payment process with S2S API
A new payment request (NewPaymentExtended.pmt, HTTP FORM POST) is sent by the webstore software (with no payer browser intervention).
The server-to-server request is authenticated by using standard Basic Authentication Header.
Use merchant's seller_id as the username and secret key as the password for Basic Auth Header.
Do not calculate hash! That is, leave out parameter
pmt_hash. This parameter is totally ignored in new payment requests using Basic Authentication and can be omitted.
The response is in XML document with root element "pmt".
These values are usually the same as in the request:
pmt_version, pmt_id, pmt_reference, pmt_amount, pmt_currency
This is the address where the payer can be redirected instantly to continue the payment process
or this address could be used as "payment link" that is sent to the payer for example by email
or this link can be shown somewhere in the webstore.
Payer is redirected to the
When the payer returns to the web store after payment, you MUST use some mechanism to validate the payment confirmation and make sure it was not fabricated by a malicious user. You can use one of these methods for this validation:
Use Payment Status Query instantly to validate the payment, especially when the payment confirmation message does not include hash. This is the case when the payment was initiated with S2S API and there was no information about hash version (
pmt_hashversion) in the initial request.
pmt_hashfrom the payment confirmation message. If you included
pmt_keygenerationparameters in the original payment API request, there will be a hash present in the payment confirmation message to the web store, whether it comes from payer’s browser or as a call-back message directly from Svea’s server to the web store.
You can do both. First b, then a. Hash algorithms have their weaknesses and this is the most secure way.
New payment request: http://docs.maksuturva.fi/en/html/pages/3_3_payment.html
Server-to-server requests are sent to address
All server-to-server requests use UTF-8 charset.