You can use Swish merchant payments in an MDriven web application by obtaining a merchant agreement, configuring the Swish certificates on the server that makes the request, and handling Swish's payment-result callback.
Before you begin
Swish is a Swedish mobile payment solution. A merchant integration requires a separate agreement with your bank.
For development, obtain the Swish merchant simulator package. The package contains the simulator instructions and the certificates used for simulator testing. Treat the supplied instructions as the authority for:
- the simulator URLs;
- the payment JSON object and its required fields;
- certificate names and passwords;
- callback registration and callback JSON; and
- response codes and payment status values.
Do not use simulator certificates or endpoints in production. Obtain and configure the production material through your bank and Swish merchant process.
Payment flow
A Swish merchant payment has two separate server-side interactions:
- Your application sends a PUT request to the Swish service. The request contains the JSON payment object defined in the Swish merchant documentation and uses the merchant certificate.
- The customer completes or rejects the payment in the Swish mobile app.
- Swish sends a POST request to your callback URL with the payment result as a JSON body.
- Your application reads the callback, finds the corresponding payment in its own data, and updates its status.
For example, when a customer places an order, your application creates a pending payment record and sends its reference in the Swish request where the Swish documentation requires it. When the callback reports the final result, the application updates that same pending record to paid, failed, or cancelled according to the received status.
Do not treat a successful PUT response as proof that the customer has paid. The callback is the result notification that your application must process.
Configure the certificates
The machine that initiates the request to Swish must be able to find and use the required private-key certificate. This is relevant both when debugging locally and when the application is deployed.
Local development
- Download the Swish simulator package and keep its certificates secure.
- Import the supplied
.pfxcertificate into the Windows certificate store on the development machine. If certificate discovery fails, start the Windows import by double-clicking the certificate file and complete the import there. - Run the application under the debugger.
- Check the debugger log to confirm that the application finds the certificate thumbprint.
The private key must remain available to the process that sends the Swish request. Do not add a .pfx file, certificate password, or private key to source control.
Azure web app deployment
For an Azure web app, install the Swish merchant .pfx certificate as a Private Key Certificate. Also install the corresponding Public Key Certificate.
One way to obtain the public certificate is to import the .pfx into the Windows certificate store on the development machine, then export its public key for upload to Azure.
Add the following application setting so that the web app can load the installed certificate:
| Setting | Value | Purpose |
|---|---|---|
WEBSITE_LOAD_CERTIFICATES
|
*
|
Makes installed certificates available to the web app. |
After deployment, use application logging to verify that the deployed process can locate the intended certificate thumbprint. The certificate requirement is comparable to the certificate-store consideration described for BankID.
Send the payment request
Implement the server-side operation that starts a payment according to the simulator guide.
- Create a pending payment record before calling Swish. Store enough information to identify the order and the payment request when the callback arrives.
- Build the JSON payment object exactly as specified by the Swish merchant documentation.
- Send the object in a PUT request to the configured Swish endpoint.
- Authenticate the request with the configured merchant certificate.
- Record the request outcome for diagnostics, without recording certificate passwords or other secrets.
- Present the next customer step in your application, such as instructing the customer to approve the payment in the Swish mobile app.
Keep the Swish HTTP request in server-side code. A browser client must not receive access to the merchant certificate or its private key.
Receive and process the callback
Swish calls your callback URL with an HTTP POST and a raw JSON body. Create a server endpoint that accepts this POST and reads the request content as a string before parsing the JSON according to the Swish specification.
- Configure a publicly reachable HTTPS callback URL in the Swish simulator or production configuration, as applicable.
- Receive the POST request at that URL.
- Read the raw request body as string content.
- Parse and validate the JSON using the fields and status values defined by Swish.
- Match the callback to the pending payment record using the payment identifier or reference defined by Swish.
- Update the payment and related business record only after validating the callback data.
- Return the response required by the Swish documentation.
Design callback processing so that receiving the same callback more than once does not mark an order as paid more than once. Keep a record of the processed result and make the status update idempotent.
Test with the simulator
Use the simulator to test the entire sequence, not only the outgoing PUT request.
| Test | Expected result |
|---|---|
| Payment approved in the mobile flow | The callback updates the matching pending payment to the approved status. |
| Payment rejected or cancelled | The callback records the corresponding non-paid status and the order is not fulfilled as paid. |
| Callback cannot be matched to a pending payment | The application logs the condition for investigation and does not update an unrelated order. |
| Certificate unavailable | Logs show that the certificate thumbprint cannot be found; correct the certificate-store configuration before retrying. |
Operational guidance
- Keep simulator and production settings separate, including endpoints, callback URLs, and certificates.
- Restrict access to certificate files, certificate passwords, and cloud application settings.
- Log correlation identifiers and payment state transitions to support troubleshooting. Do not log secrets.
- Make the callback endpoint available to Swish. A localhost-only endpoint cannot receive a callback from an external Swish service.
- Use the Swish simulator documentation for the authoritative request schema, callback schema, and expected HTTP responses; these details can change independently of your MDriven application.