Skip to content
Jonathan Niklasson Godar edited this page Nov 14, 2024 · 2 revisions

Swish integration

The swish payment part of the django application was built to be as modular as possible, meaning that it should be as decoupled as possible from the other "business" logic.

Structure

The Swish part of the app originates in bittan/backend/bittan/services/swish/__init__.py. It defines a class which is (should be) the only connection between the rest of the backend and the swish part of the backend. When we want to request a payment we can call the "create_swish_payment" on an instance of the Swish class. Because initializing a swish instance everytime we want to create a payment is annoying you can use the Swish.get_instance() method to get the active instance of swish. When the Swish instance is initialized a "callback_function" is passed. This function is the only way the swish part of the API sends updates to the other part of the backend.

To summarize, interaction with Swish is done via calling methods on the Swish object and by processing the calls on the callback_function

Testing

At the moment there are no automated tests on the Swish-part. To manually trigger a call to "create_payment_request(...)" you can send an http request to "http://localhost:8000/swish/dummy/". This endpoint is only available when the DEBUG environment variable is set. The endpoint is only there for convenience sake. You can also pass a message to simulate swish error codes:

curl -X POST "http://localhost:8000/swish/dummy/" # Creates a payment (which should succeed)

curl -X POST "http://localhost:8000/swish/dummy/?msg=RF07" # Simulates a payment which the user cancels.
Clone this wiki locally