Overleg:PrivacyBetaalGegevens: verschil tussen versies

Huidige versie van 5 okt 2012 om 13:29

SjorsK 3 okt 2012 22:59 (CEST):: Ik ben persoonlijk een fan om betaalgegevens elke zo snel mogelijk naar een offline archief te verplaatsen(ideaal: Binnen 1 week). Betaalgegevens zijn immers privacy & fraude gevoelig maar het kan vereist zijn dat deze informatie tijdelijk online staat in verband met het verwerken van transacties.

phedny 4 okt 2012 23:43 (CEST):: Betalingen zullen in het begin op 2 of 3 manieren mogelijk zijn:

• Middels iDeal
• Middels automatische incasso
• Eventueel middels bankoverschrijving

Automatische incasso

Voor betalingen via automatische incasso hebben wij bankgegevens van de gebruiker nodig. Deze hoeven echter niet op een online server te staan. Vanuit een offline server kunnen wij batches aanmaken en die vervolgens online aanleveren via een gecontroleerd proces. Bankgegevens hoeven daarom nooit op een online server te staan.

De voortgang van het innen via een automatische incasso wordt ons gemeld door een URL aan te roepen. Deze zal dus op de online server moeten staan. Wij kunnen overigens ook vanaf de offline server zelf opvragen wat de status is.

iDeal

Voor betalingen via iDeal hoeven wij geen bankgegevens voor lange termijn te bewaren. Wat we online moeten bewaren is het te betalen bedrag en bij welk account dit hoort. Wanneer de betaling gestart wordt, kunnen wij de status monitoren. Vanaf het moment dat de betaling wordt aangevraagd bij een bank is deze voor 10 minuten geldig. We kunnen dus niet in een batch vanaf de offline server betalingen starten en de gebruiker op gemak deze laten uitvoeren. De betaling moet gestart worden vanaf de online server. Wellicht kunnen we wel een manier bedenken om te zorgen dat op deze server geen betaalgegevens beschikbaar zijn zolang de gebruiker niet begonnen is met het uitvoeren van de betaling, bijvoorbeeld door de benodigde gegevens in een link te plaatsen die de gebruiker per mail krijgt, danwel te versleutelen en de sleutel in de link in die mail te plaatsen.

Wanneer de betaling wordt aangeboden krijgen we een transactie-ID terug, welke we kunnen gebruiken om de status van de betaling op te vragen. De online server kan de status van de betaling dus zelf volgen. Vanaf de offline server kunnen we de status alleen opvragen als het transactie ID bekend is dat de online server weet.

Bankoverschrijving

Betaling per bankoverschrijving zouden we op twee manieren kunnen doen. Optie 1 is dat we dit direct op de bankrekening van Limesco laten storten, maar dit zou betekenen dat er een handmatige slag overheen moet gaan. De andere optie is via de betaalprovider, waar we de voortgang van de betaling kunnen volgen. Hierbij geldt hetzelfde als bij de automatische incasso: op de online server wordt een aanroep gedaan wanneer er voortgang is m.b.t. een betaling en vanaf de offline server kunnen we zelf de voortgang opvragen met een status request.

--Probatom 5 okt 2012 00:54 (CEST):: Het lijkt me goed om te streven om bankgegevens (rekening/tenaamstelling) inderdaad zoveel mogelijk van de online server weg te houden. Het voorstel om bij iDeal dit crypted op te slaan en de gebruiker de key te geven vind ik een mooie oplossing. De betaalgegevens zelf, dus de bedragen, (wanneer is wat betaald, facturenoverzicht) lijkt me iets dat we online kunnen aanbieden als de gebruiker dat wenst (opt-in). In ieder geval zullen we deze gegevens willen bewaren (offline) voor controle/boekhouding.

--Probatom 5 okt 2012 01:07 (CEST):: Nog een ideetje naar aanleiding van de key per e-mail: We kunnen de mogelijkheid bieden dat gebruikers een (PGP of s/mime) public key uploaden, welke we op de offline server kunnen zetten. De offline server kan dan lokaal al encrypted mails genereren. Dan kan er in het traject dat begint bij het gegevens van de offline server halen die het internet op moeten tot in de mailbox van de gebruiker geen mogelijkheid tot lekken (onder aanname dat gebruikte crypto inderdaad secure is).

--phedny 5 okt 2012 14:18 (CEST):: PGP of S/MIME is zeker een goed idee hiervoor. We kunnen daarbij overigens ook digitale handtekeningen gebruiken om de authenticiteit van facturen of andere berichten aan te geven. Ik stel voor om in deze fase bij het ontwerp de mogelijkheid van PGP in het achterhoofd te houden, maar dit bij de implementatie nog niet mee te nemen. We hebben nu onze tijd nodig voor de kernfunctionaliteiten, dan kunnen we later dit jaar of begin 2013 encryptie eraan toe gaan voegen.