2. Use Cases

2. Use Cases

The user stories below act as example to increase the understanding of the service Swish handel on a high level.

2.1 Swish handel application procedure

This user story describes on a high level how a merchant applies for the service Swish handel.

  1. The merchant contacts a Swish connected bank to sign an agreement for the service.
  2. The merchant confirms the business terms and signs the agreement with the bank.
    • The bank obtains and registers the necessary merchant information, including info about the appointed recipients of the API certificate – CPOC (Certificate Point Of Contact). The following personal information is mandatory about the CPOC: Social Security Number, Name, Company Registration Number. Optionally, some banks will also require additional information such as E-mail and phone number.
    • A Swish number is created for the agreement.
    • The bank sends an enrollment request to Swish security solution.
  3. The security solution receives and registers info about the CPOC connected to the Swish number. The CPOC’s are granted access to the certificate management system in the Swish security solution.

4. The merchant is now ready for Swish API access.

5. The merchant or the partner needs to generate a csr-file (Certificate Signing Request). 
This is normally done by the CPOC.
6. The CPOC logs in to the certificate management system using Mobile BankID, BankID on card or BxID and creates the certificate.
7. The CPOC installs the certificate in the merchant’s server and connects it to Swish API. If needed, Swish support function can assist with the connection.
8. The merchant verifies the connection.

2.2.1 Payment request in the Swish app - Swish m-commerce

The m-commerce flow should be used when the Swish app is on the same device as the merchant’s mobile site or app – hence a mobile device.

  1. Consumer chooses to pay with Swish for a product or a service in the merchant app.
  2. The merchant sends a payment request to the Swish system using the API.
    • The transaction contains data such as: amount, receiving Swish-number, merchant (payee) payment reference and an optional message to the consumer.
  3. The merchant receives a Request Token.
  4. Consumer’s Swish app is opened automatically by the merchant’s site or app showing the payment section that is preloaded with payment information.
    • The app is opened with the request token as a parameter.
  5. Consumer clicks Pay (”Betala”) and the Mobile BankID app opens automatically for signature of the payment transaction.
  6. Consumer confirms the payment transaction by signing with the Mobil BankID using his/her password.
  7. The amount is transferred in real-time from the consumer’s account to the merchant’s account.
  8. Consumer is linked back to the merchant app for payment transaction confirmation.
    • Note: the confirmation screen in Swish-app is not displayed in this flow.
  9. The merchant receives a confirmation of successful payment.
  10. Consumer can view the payment in the events section “Händelser” as a sent payment in the Swish app.

2.2.2 Payment request in the Swish app - Swish e-commerce

The e-commerce flow should be used when the Swish app is on another device than the merchant’s site.

  1. Consumer chooses to pay with Swish for a product or a service at the merchant website and enters his/her mobile phone number which is enrolled to Swish.
  2. Information on the merchant website should inform the consumer to open the Swish app to confirm the transaction.
  3. The merchant sends a payment request to the Swish system using the API.
    • The transaction contains data such as: amount, receiving Swish-number, consumer’s mobile phone number, merchant payment reference and an optional message to the consumer.
  4. Consumer opens the Swish app showing the payment section, which is preloaded with the information in the payment request.
  5. Consumer clicks Pay (”Betala”) and the Mobile BankID app opens automatically for signature of the payment transaction.
  6. Consumer confirms the payment transaction by signing with the Mobil BankID using his/her password.
  7. The amount is transferred in real-time from the consumer’s account to the merchant’s account.
  8. Consumer receives a payment confirmation in the Swish app.
  9. The merchant receives a confirmation of successful payment.
  10. Consumer receives a payment confirmation at the merchant website.
  11. Consumer can view the payment in the event section “Händelser” as a sent payment in the Swish app.

2.2.3 Payment request in the Swish app - Reject payment

Consumer wants to dismiss the payment request in the Swish app and clicks on “Avbryt”. The rejected payment request is deleted from the Consumer’s Swish app.

2.3 Refund

There are two ways to make a refund: through the bank channel or through the API channel. This section describes the API channel on a high level.

As a merchant, I have received a Swish payment and wish for some reason to refund the whole or part of the original amount to the payer.

The merchant chooses which payment that is to be completely or partially refunded. The merchant specifies the refund amount and sends the refund.

The merchant will also be able to send its own information that will be shown to the payer in the event section in the Swish app, and also on the payee bank account statement. The information will also be used by the company for tallying.

The merchant receives a confirmation that the refund has been completed.

As recipient of a refund, the payee receives a payment notification in the Swish app. The payment notification is marked “Återbetalning” in the event section in the Swish app.

Alternative flow – ”payment notification”:

In cases when the recipient of a refund cannot receive data push notifications at the moment, the refund will be visible in the Swish app next time the recipient logs in. The refund will also appear in the recipient´s bank account statement.

Alternative flow – ”refund receiver not connected to Swish”:

In cases when the recipient of a refund has terminated the Swish agreement since the original payment occurred, the merchant will receive an error message stating that the refund cannot be processed. Refund must in this case be done via another channel.

2.4 Termination Swish handel

  1. The merchant terminates the agreement with the bank. The service will stop working.
  2. The merchant is responsible for termination/revocation of the API certificates.
  3. Refunds will not be possible to do on the terminated Swish number.