Billig + Swedbank-pay

Våren 2020 ble det sendt ut en mail til alle PayEx/Swedbank sine kunder om at det snart vil være obligatorisk å migrere til deres nye tjenester. Vi har tidligere brukt PayEx sin direct-modell, og planen er å bytte til Swedbank sitt tilsvarende API.

Swedbank-pay-API

Vi har hatt litt kontakt med kundeservice hos Swedbank, og det ser ikke ut som de er helt klare til at folk skal begynne å bruke API-et. Dokumentasjonen er ikke på nett, og når vi fikk den tilsendt fant vi ut at den hadde noen rimelig store mangler. Den ligger på cassarossa under /home/cassarossa/itk/felles/dok_swedbank_pay.pdf .

Billettkjøpsflyt

Et kjøp hender roughly sånn her:

1. En bruker poster dataen sin til billettsalg.samfundet.no, og create_purchase reserverer en billett. Ordren lagres i databasen med state = 1.

2. Vi lager et JSON-kjøpsobjekt og poster det til /payment. Dette objektet må inneholde pris, valuta, redirect-linker, og litt annet stæsj, samt at det kan ha med noen parametere som hjelper Swedbank å vurdere "kjøpsrisikoen".

3. Swedbank svarer forhåpentligvis med et payment-objekt og et operations-objekt. Det førstenevnte inneholder en id, noe av dataen vi sendte tidligere, og informasjon om kjøpstilstanden. Det andre inneholder en hel masse URI-er som brukes sendere for å snakke med APIet. Dersom vi mottar en gyldig response, setter vi state=2 på ordren i databasen.

4. Dokumentasjonen er noe uklar på neste steg. Den ber oss om å sende en GET til /$id-en_fra_payment_objektet, men dette returnerer et duplikat av svaret du får fra steg 3, så det gir ikke helt mening. Teorien nå er at de forsøker å si er at vi skal sende en POST til en av URL-ene fra operations-objektet. Denne URI-en eksisterer ikke i dokumentasjonen av operations-objektet, men den skal være der og skal hete noe á la "direct-authorization" i følge introduksjonen. Dette vil få Swebank til å reservere pengene.

5. Dersom 3-D secure er på (Som det formodentlig er om dagen, skjønt, Swebank ser ut til å støtte funksjon for å skru det av automatisk dersom de ser på det som et lavrisikokjøp.), vil vi få mest sannsynlig få en URL som vi videresender brukeren til. Etter dette sendes brukeren til en url vi har satt i payment-objektet. Dette er egentlig en del spekulering, siden det ikke er dokumentert ordentlig.

6. Brukeren har enten fullført eller avbrutt kjøpet i 3-D secure. Hvis brukeren har avbrutt underveis spekulerer vi at dette videresender dem til en annen URL vi har satt opp, samt at det endrer tilstanden i payment-objektet hos Swedbank, så kan timeout-payex plukke det opp senere. Men igjen, dette er ikke så voldsomt dokumentert. Dersom 3-D secure gikk igjennom sjekker vi tilstanden til ordren hos swebank ved å sende en request. Hvis den er authorized setter vi state=3, hvis den er captured setter vi state=4 i vår egen database. Vi videresender så brukeren til en success-side (capture av transaksjonen og utsending av billetter håndteres av timeout-payex neste gang det blir kjørt. (merk: her må flowchartet under oppdateres)

7. timeout-payex gjør en GET-request for å få status til payment-objektet. Dersom kjøpet ble avbrutt på et av stegene etter pengene var reservert, vil timeout-payex avbryte transaksjonen med en POST-request til create-cancel-operasjonen som blir returnert i GET-requesten. Hvis ikke, gjennomfører timeout-payex den reserverte transaksjonen med en POST-request til create-capture-operasjonen som blir returnert i GET-requesten. Deretter sender timeout-payex epost med billetter til brukeren.

Her er en flowchart
Utkast til mer detaljert flowchart
https://home.samfundet.no/~bjornargh/billigswedbankpaymedstates.pdf

Lenker: Start

Mail: itk@samfundet.no | Telefon: 992 15 925 | Sist endret: 2020-03-01 14:33 | Revisjon: 5 (historie, blame) | Totalt: 1601 kB | Rediger