Den svenska banktjänsten Swish är fantastiskt trevlig att använda när man som privatperson behöver föra över pengar till en annan privatperson. ”Alla” har en mobil och ett mobilnummer är allt man behöver veta för att skicka pengar. I stort sett bra tänkt.
När tjänsten kom var vi många som direkt såg möjligheten att kunna betala för saker via Swish, t ex när man handlar något på en sajt. Det måste väl ändå Swish-gänget ha tänkt på? Nä, deras sajt sa inte ett ord om det. Inte var det särskilt lätt att kontakta dem heller, de har inga kontaktuppgifter på sin sajt och företaget tycks inte ens ha ett publikt telefonnummer.
Nåja, de hade faktiskt en facebooksida där någon svarade på frågor. Återigen, vi var många som frågade efter ett API för e-handel. Tyvärr var svaret alltid detsamma, här är ett ur högen:
Någonstans längs vägen tycks det ändå ha gått upp ett ljus. Under sommaren presenterades nyheten att det inom kort skulle gå att använda Swish för e-handel. Strålande, läge för en brasiliansk dubbel-tumme!
Ok, jag kanske var överdrivet optimistisk. När jag fick tag i dokumentationen slängde jag mig genast över den för att se hur de tänkt sig kopplingen. Efter en kort stunds läsande var min spontana tanke att det skulle vara gott med en rejäl whisky eller något annat stärkande. Här kan det vara intressant att veta att jag sällan dricker alkohol men att jag har rätt lång erfarenhet av att designa lösningar för kommunikation mellan finansiella system.
Om vi håller oss till betalningslösningar för webben så har de i omkring 20 år varit baserade på samma grundmodell.
Vanligtvis skickar webbshopen en fråga till sin kortinlösare / betalväxel, något i stil med ”vi skulle vilja ha 42 spänn av den här kunden. godkänner ni det?”. Systemet i andra änden gör sin grej, tex verifierar att kortet är giltigt och svarar sedan ”ok” eller ”inte ok” till sajten.
I stort är det också så Swish API fungerar. I alla fall i teorin, på en mer praktisk och implementationsteknisk nivå skiljer det sig markant. De flesta betalningslösningar accepterar nämligen kommunikation över en helt vanlig SSL-kanal. Det är en rimlig säkerhetsnivå och går enkelt att implementera i de flesta plattformar. Swish nöjer sig inte med det.
Swish kräver nämligen också ett klientcertifikat. För att få ett sådant måste man
- generera ett PKCS#10 certifikatrequest i sin server
- logga in i Swish admin-gränssnitt (under förutsättning att man blivit utsedd till CPOC)
- ladda upp sitt CSR
- generera ett certifikat (valfritt PKCS#7 eller PEM, vilken obeskrivlig glädje e-handlaren måste känna över att få göra det valet!)
- Ladda ned certifikatet
- Installera certifikatet i sin server
Klart som korvspad. Visst? Nja…
Om webbshopen heter tex Dustin eller Webhallen så är det knappast något problem, de har kompetent personal som fixar det här. Men, med en mer verklighetsnära synvinkel så är det förstås så att väldigt många webbshopar körs på plattformar som är gjorda för att även småföretagare enkelt ska kunna sälja sina varor. Många av dessa körs i shared hosting där det inte nödvändigtvis ens är tekniskt möjligt att installera något certifikat.
Jag antar att Swish kommer att slå ifrån sig såna invändningar och hänvisa till att betalväxlar, integratörer och konsulter kan hjälpa till och det här är onekligen en ”konsultvänlig” lösning. Men vore det inte bättre att leverera lösningar som är bra för kunden?
Nåväl, det gav mig något att raljera över och det har kanske ett värde i sig. Dessutom har jag gjort en liten WooCommerce-plugin som försöker göra de tekniska detaljerna lite mer användarvänliga och göra det möjligt att Swish-betala till en WooCommerce-shop. Om jag får tillgång till Swish testmiljö så jag kan verifiera att det funkar så dyker pluggen upp hos wordpress.org så småningom.