When integrating with Swish API the following guidelines will support stable performance of the system and a smooth consumer experience.
Each payment request transaction sent to the API must be initiated by a physical paying consumer. The merchant must make sure that the consumer does not receive what he/she perceives as “spam” or unwanted payment requests.
When sending the payment request or refund a call-back is provided to the merchant of the status of the payment. This is the normal usage scenario, which should be used in most cases.
As a backup there is also a “Retrieve” for Payment Requests and Refunds for reconciliation in the case that the normal call-back fails for some reason. Note that this is a backup – and not the standard flow for receiving payment status.
The “create refund” message is intended for real-time one-by-one calls. It is not intended for batching up a large quantity and then sending the whole batch in a short period of time.
There should be at least 1 second between each refund transaction and if more than 100 transactions are to be sent in a sequence they should be sent during night time.
The validity of the client TLS certificate is two years. It is the merchant’s responsibility to generate new keys and certificate in due time, prior to the expiry of the old certificate, in order to ensure uninterrupted functionality of the commerce site. The merchant could authorize another company (a partner to the merchant) to manage the certificate renewal process.
When enrolling to Swish the merchant will receive a Swish alias (123 XXX YYYY) which uniquely identifies the enrolment and which is used as an alias to the payee’s bank account.
We recommend e-commerce and m-commerce merchants not to expose this to consumers since it
The Swish alias for transactions generated by payment requests or refunds will not be displayed by the Swish app or the bank’s consumer interfaces.