Kannatetaan lämpimästi. Suomalaisten maksusysteemien liittäminen Drupal -moduliksi on takuuvarmasti suurta osaa suomalaisia Drupal -kehittäjiä koskettava asia. Itse en valitettavasti pysty jeesaamaan ainakaan teknisen toteutuksen suhteen. Vinkkinä lienee ainakin se, että kehittäjien kannattaa tosiaankin huolehtia sopimuksista siten, että koodi olisi yhteisön käytettävissä ja ylläpidossa. Kaikille hyödyllistä, tilaaja ja pankit mukaanlukien.

... eli pari tähän aiheeseen liittyvää moduuliuutuutta. Toiseen maakohtaiseen maksujärjestelmään kaavailtu rajapinta: http://drupal.org/project/clieop Clieop is a specification of the dutch direct debit payment method 'automatische incasso'. The specifications are hold by http://www.equens.com/ and can be downloaded http://www.equens.com/support/file_layout/index.asp Ja ehkä hieman tutumpi maksupalvelu: http://drupal.org/project/gcheckout e-Commerce Google Checkout. This module provides a Google Checkout payment method for the e-Commerce suite of modules. Kummatkin ovat enemmän tai vähemmän suunnittelu/ideointiasteella. Mielenkiintoista seurata, kuinka muiden ratkaisut kehittyvät.

Se, mistä ostoskorirakenteesta nuo tuote- ja veloitustiedot moduuliin siirtyvät, on toissijaista, koska moduulissa on tietysti oltava selkeä API, joilla tiedot välitetään. Itse näkisin että kyseinen moduuli ennemminkin toteuttaa jotain valmista apia kuin että tätä kannattaisi ratkaista toteuttamalla itsenäinen moduuli apeineen. Pelkkä Suomalaiset verkkomaksut toteuttava moduuli olisi toki kehittäjille hyödyllinen työkalu, mutta tavallisten käyttäjien kannalta toteutus osana valmista ecommerce -järjestelmää olisi nähdäkseni hyödyllisin ratkaisu. PHP-koodi sekä maksujen, että tunnistuksen tekemiseksi on tosiaan melko yksinkertainen ja löytyy luultavasti valmiina kaikilta asiaan perehtyneiltä kehittäjiltä. Toteutustavasta huolimatta kaikkien pankkien maksut ja tunnistuksen toteuttavan mokkulan julkaiseminen avoimena lähdekoodina dokumentaatioineen olisi iso palvelus myös muille kuin Drupalia käyttäville kehittäjille. Eiköhän pistetä oma projekti pystyyn tämän ympäriltä. Luulen että kiinnostuneita löytyy runsaasti heti kunhan jotain edes etäisen toimivaa on saatu julkiseksi.

En ole ihan varma, mitä tarkoitat termillä plugin, tai siis miten se eroaa käytännössä Drupal-moduulista. Moduulin toteutuksen kannalta ei saisi kuitenkaan olla minusta eroa sillä, millaiseen ostoskoriin tai muuhun prosessiin se kytketään. Muuten tulee luotua sellaista koodia, joka ei ole uudelleenkäytettävää, jota joutuu säätämään tapauskohtaisesti ja joka voi mennä rikki kun jonkun toisen moduulin koodia muutetaan.

Maksumoduulin suunnittelussa kannattaa jollakin tavalla tietysti huomioida nuo yleisimmät ja todennäköisimmät vastakappaleet ja niiden rajapinnat.

Käytännön toteutuksessa ne voisi minusta erottaa kuitenkin omiksi sovittimikseen, joka eristää eri moduulien väliset tietorakenteelliset ja semanttiset riippuvuudet ja mahdollistaa uusien ostoskorien yhdistämisen prosessiin. Maksumoduulilla voi siis olla täysin oma "fiksattu" rajapinta, joka ei riipu muista ja on täysin yleiskäyttöinen.

Hatusta revittynä se voisi olla esim. jotain tämän tapaista:

interface iPankkiMaksu {

  // Yhteisiä kaikille i[xxxxx]Maksu -tyypeille:  

  public function luoMaksupyynto($ostoskori, ...);  

  public function kasitteleMaksupyynto();

  // iPankkiMaksu-kohtaiset:   

  public function luoMaksuPainikkeet($maksuPyynto);   

  public function kasittelePankinPaluusanoma($paluuSanoma);

}

Pankkikohtaiset toteutukset johdettaisiin iPankkiMaksusta:

class NordeaPankkiMaksu implements iPankkiMaksu {

  /* ... */   

  public function luoMaksuPainikkeet($tilaus)   

  {     

    return '<form><input x /><input y /></form>';   

  }

}

Tuon lisäksi olisi sitten jokin plugin-moduuli tietylle ostoskoriratkaisulle, joka ymmärtää sen tietorakenteet, tekee mahdolliset normalisoinnit iPankkiMaksu-tyypille ja kutsuu sitten maksutapahtuman aktivoivaa metodia.

Esim. normalisoinnissa voisi olla tämän näköistä koodia:

class UbercartinOstoskoriYleiseksiOstoskoriksi implements iOstoskoriSovitin {

  /* ... */   

  public function asetaAsiakasTiedot($ubercartinKori)   

  {     

    $maksaja = new Henkilo;   

    $maksaja->asetaNimi($ubercartinKori->sukunimi .' '. $ubercartinKori->etunimi);     $drupalOstoskori = new DrupalKori;

    $drupalOstoskori->asetaMaksaja($maksaja);   

  } /* ... */

}

Eli jos toisessa käsitellään nimeä etu- ja sukunimitasolla ja toisessa yhtenä kenttänä (muodossa "Sukunimi Etunimi"), niin sovitin hoitaisi näiden eri muotojen konversiot. Tällaiset tehtävät eivät kuulu maksukomponentin tehtäviin.

Itse asiassa koko maksumoduuli voitaisiin saman tien yleistää niin, että se sallii pankkimaksun lisäksi myös Finvoice-laskutuksen. En tarkoita, että Finvoicea pitäisi toteuttaa, mutta kun kerran tässä jo käsitellään tuotteita, hintoja, asiakastietoa, toimitustapoja jne., niin koossa ovat Finvoiceenkin tarvittavat palaset.

Kokonaistoteutus voisi mennä niin, että on ylätyyppi iTilaus, joka sisältää laskutettavan tilauksen tiedot omina alatyyppeinään (asiakas, tuote, tuotteen parametrit, maksutapa, viitenumerot). iTilaus voitaisiin sitten välittää joko iPankkiMaksu, iLuottokorttiMaksu-, tai iFinvoiceLasku -tyypeille, jotka hoitaisivat sen rahaliikenteen. (Finvoicelle tuo interface voi olla turha, jos toteutuksen johdannaisia on vain yksi.)

Koodista käsin ja siis "käyttäjän" näkökulmasta (jossa käyttäjä voi olla jonkun Ubercartin plugin-koukku, joka on tarkoitettu maksatuksen käynnistämiseksi - tai miten se sitten onkaan toteutettu), kutsuttaisiin kuitenkin aina pelkästään metodia iTilaus.hoidaMaksu();, ja tuo tekisi käytännössä joko pankkimaksun, luottokorttimaksun, Finvoice-laskun jne. riippuen siitä, mikä maksutapa on valittuna ja sallittuna ja mitä sovittimia on asennettuna.

Moi Teemu Mäntynen on julkaisut verkkomaksu moduulin VirtueMartille (GPL2) http://www.tyovaline.fi/oss/fipn/ Voisi olla aiheellista työskennellä yhdessä :)

Huomasin tällaisen projekitityngän: http://drupal.org/project/payment_api

Jos oikein ymmärsin, Payment API voisi toimia "välikerroksena" Drupalin ja eri maksurajapintojen välillä. Se siis hoitaisi tuon yleistämisen, jota aiemmassa koodiesimerkissä hahmottelin.

Haen parhaillaan ratkaisua mm. finvoice-laskutuksen integroimiseen drupaliin/übercartiin. Onkohan tämä projekti edennyt mitenkään?

Itse olisin myös kiinnostunut tästä aihekokonaisuudesta. Siis miten ja millä resursseilla saisimme tässä ketjussa esitetyt asiat toteutettua niin että ne olisivat avoimia ja kaikkien hyödennettävissä. Drupal/Ubercart ratkaisu on erittäin mielenkiintoinen, mutta siihen tulisi saada edellä esitettyjä toiminnallisuuksia. Uskoisin että tähän olisi löydettävissä myös julkista rahoitusta, jos vain tekijöitä löytyisi.

t. Mika

Löytyisiköhän Suomesta sponsoreita pienemmässä mittakaavassa jos tästä tai jostain vastaavista "yleishyödyllisistä" avoimen lähdekoodin hankkeista tekisi Summer of Code -tyyppisen hankkeen? Kansainvälistä rahoitusta voi olla vaikea saada tälläiselle ja ihan puhtaasti vapaaehtoisvoimin vähän kookas hanke. Päteviä opiskelijoita varmasti löytyisi ja menttoreitakin varmaan. Löytyisiköhän kiinnostunut koordinaattori etsimään sponsoreita ja miettimään miten käytännön tekniset muodollisuudet saadaan hoidettua? Julkistakin rahoitusta varmaan saisi jonkun verran, mutta ainakin osa pitäisi luultavasti saada yksityiseltä puolelta.

Pari muutakin vastaavaa hanketta varmaan löytyis D.fi:n ympäriltä. Ihan vaan ideana...

Minulla on pieni projekti, johon tarvitsisin myös verkkomaksusysteemiä suomalaisia (tai suomessa toimivia) pankkeja vasten.

Itse osaaan jonkin verran koodata php:llä, mutta valitettavasti olio-ohjelmoititaitoni ovat olemattomat/surkeat.
Jos valmista liityntää ei pankkien järjestelmiin (julkisesti) ole, niin kait se pitää sitten keksiä pyörä uudelleen. :)
Projektini on sen verran alkuvaiheessa vielä, että tuo maksurajapinta voi olla kumpaan vaan (ecommerce/übercart).

Kiitos tiedoista jo etukäteen.

Tiedän, että esim. osCommerceen on vastaava liityntä, mutta en haluaisi rakentaa tuota projektiani sen varaan (koska sen ylläpito on melkolailla tuskaa normikäyttäjälle).

Itseasiassa on jo tällä hetkellä työn alla. Jos sinulla on kiire kaikkien kotimaisten maksujen ja Übercartin kanssa ota käyttöön http://drupal.org/project/uc_checkoutfi
Suorat pankkiyhteydet tarjoava moduuli saatanee beta-versiona pihalle noin kuukauden sisällä.

Hienoa että tämä on mennyt eteenpäin. Myös tuo TUPAS autentikointi moduli on hieno asia. Onko se jo valmis tuotantokäyttöön?