[PHP] Betaling systeem voor webwinkel

[vdvleon]

Hallo iedereen,

Ik ben bezig met het maken van een webshop voor een Duitse winkel. De webshop is niet
alleen bedoelt voor Duitsers, maar ook Nederlanders, Engelse, Spaanse, etc. Ik moet nu een
betaal systeem implementeren.

In Nederland heb je bijv. IDEAL, maar deze techniek kost (redelijk veel) geld voor een winkel.
Wat zou nog meer een optie kunnen zijn? Is bijv. een systeem via Credit-cards aan te raden?
Waar moet ik opletten met dit soort keuzes?

Heeft iemand ervaring met betaalsystemen voor webshops?

Alvast bedankt.

[Spiked]

Wat dacht je van PayPal? ( https://developer.paypal.com/ )

Edit: Of gewoon over laten maken via IBAN/BIC?

[ Voor 30% gewijzigd door Spiked op 06-10-2009 17:34 ]

[sanzut]

Er zijn diverse payment providers op de markt, deze kunnen je vaak helpen met internationale betaling, of betalingen met meerdere betaalmiddelen.

Verder vallen via zo'n provider de kosten ook wel mee, vaak tussen een halve euro en 1 euro, afhankelijk van de provider.

[painkill]

Jezus, jij maakt een shop, nouja de website. En je kent Paypal niet?

Maar goed, dat is dus een goed internationaal systeem.
Mocht je shop gericht zijn op wat meer mainstreamklanten, dus winkel met boeken etc...
Dan is paypal niet echt geweldig aangezien lang niet iedereen er een rekening heeft.

Kijk anders maar eens naar internationale shops zoals amazon wat hun bedacht hebben

[Verwijderd]

iDeal is gratis bij de ING (maandelijkse kosten dan), bij Mollie etc kan je ook iDeal nemen (of MultiSafePay, ...).

PayPal is ook een optie, maar dan moet je een incassocontract tekenen. Over creditcardbetalingen betaal je volgens mij vaak een percentage over het gehele bedrag.

Ik zou letten op de veiligheid, snelheid van betalen en hoe betrouwbaar mensen de betaalmethode vinden. iDeal wordt over het algemeen als veiligste gezien, aangezien de winkel dan zeker in Nederland geregistreerd staat bij de KVK en dus de eigenaar bekend is. (alleen als er staat "ING Bank inzake MijnBedrijfsNaam")

Let op: iDeal is alleen in Nederland bij een beperkt aantal banken beschikbaar.

[r0b]

1. http://authorize.net/
2. http://www.bibit.net/
En [google=list of payment service providers]

Gratis gaat je niet lukken, met PayPal wil je niet beginnen (naast dat ze nog eens x% van de winst pakken, kan het ook klanten afschrikken - zoals mij, ik ben fan van PayPalSucks.com)
Authorize.net kost je geloof ik 99 USD aan sign-up fees en vervolgens een x aantal dollarcent per transactie.
Bibit werkt volgens hetzelfde principe maar kan ook lokale betalingsmethodes aanbieden (iDeal in Nederland, lokale internetbanking in Duitsland, etc..)

[ Voor 72% gewijzigd door r0b op 06-10-2009 17:41 ]

[vdvleon]

Bedankt voor de hulp. Ik ga overleggen met mijn klant.

En, dit is mijn eerste webshop. Natuurlijk heb ik wel gehoord van paypal, ideal etc. maar natuurlijk heb ik nooit de techniek er achter hoeven gebruiken aangezien dit dus pas mijn eerste webshop is. Maar ik zal de mogelijkheden afwegen.

[dev10]

Verwijderd schreef op dinsdag 06 oktober 2009 @ 17:37:
Let op: iDeal is alleen in Nederland bij een beperkt aantal banken beschikbaar.

Valt inmiddels wel mee hoor. Bij onze webshop hebben we bij iDEAL de volgende banken in staan:

- Rabobank
- ABN Amro Bank
- Fortis
- Friesland Bank
- ING
- SNS Bank
- ASN Bank
- SNS Regio Bank

Het lijkt mij dat je hiermee het grootste deel van de Nederlanders wel bereikt.

[macciez]

Pas op wat je daar allemaal wilt, want zodra je bijvoorbeeld creditcard gegevens wil gaan opslaan, wordt het meteen een heel ander verhaal.

[r0b]

macciez schreef op woensdag 07 oktober 2009 @ 11:24:
Pas op wat je daar allemaal wilt, want zodra je bijvoorbeeld creditcard gegevens wil gaan opslaan, wordt het meteen een heel ander verhaal.

Goed punt inderdaad; zie daarvoor o.a. https://www.pcisecuritystandards.org/ , http://www.pcicomplianceguide.org/ en Wikipedia: Payment Card Industry Data Security Standard

Het makkelijkste is meestal "fire & forget"; kaart accepteren, verwerken (al dan niet bij je Payment Provider) en de gegevens niet opslaan.

[ Voor 12% gewijzigd door r0b op 07-10-2009 11:50 ]

[RobIII]

r0b schreef op woensdag 07 oktober 2009 @ 11:49:

Het makkelijkste is meestal "fire & forget"; kaart accepteren, verwerken (al dan niet bij je Payment Provider) en de gegevens niet opslaan.

Als je een payment provider gebruikt krijg je vaak niet eens de (volledige) creditcard nummers. Je krijgt dus vaak 1234 56 XXXX 1234 ofzo. En je kunt de gedeeltelijke nummers prima opslaan, al is 't maar om de klant naderhand nog te kunnen vertellen met welke kaart 'ie ook weer betaald had.

Kijk ook eens naar Ogone (die stond nog niet in dit topic).

[ Voor 11% gewijzigd door RobIII op 07-10-2009 12:33 ]

[r0b]

Nog meer leuk leesvoer staat op http://stackoverflow.com/...rtial-credit-card-numbers

Hi,

The Payment Card Data Security Standard states that if you are handling cardholder data, then you are subject to the constraints of the PCI DSS (which is very comprehensive and a challenge to comply with). If you want to store part of a card number, and don't want to have to deal with the Standard, then you need to make sure that a) you store NO MORE THAN the first 6 and last 4 digits; b) you don't ever store, process or transmit more than this. That means that the truncation has to be carried out before the data enters your control.

Given that you are talking about an ecommerce site, I think you'll have to deal with the PCI DSS sooner or later (since if you're not taking full PANs, you can't process transactions). Realistically, then, you should avoid storing more than the first 6 and last 4 digits of a PAN; the Standard then does not 'care' about this data, and you can store it in whatever form you see fit. If you store, say, the first 7 digits, then Requirement 3 of the Standard kicks in (and you start having to really understand key management in encryption).

I hope that this is of use.

Cheers,

B

Wat RobIII dus ook net zei.
Als je alleen naar oplossingen als iDeal en dergelijke kijkt heb je dit natuurlijk een stuk minder / helemaal niet.

[ Voor 4% gewijzigd door r0b op 07-10-2009 12:32 ]

[Verwijderd]

Je zou eens kunnen kijken naar http://www.icepay.nl/. Heb ik best goede ervaringen mee.

[Verwijderd]

je zou ook nog ff kunnen kijken naar http://www.targetpay.com/

[ixi]

Ik zou nooit zelf een betaalsysteem gaan implementeren, zeker niet als je meerdere betaalmethodes wilt ondersteunen. Kies een degelijke payment provider, en leg die verantwoordelijkheid bij hun neer. Ik heb zelf ook goede ervaringen met icepay.nl, hoewel klanten vaak raar kijken en vragen "Was dat niet die ijslandse bank?": Nee

Specifiek voor icepay is de implementatie redelijk eenvoudig. Je stuurt de klant naar de site van Icepay en geeft een identificatiecode van de bestelling mee. Achter de schermen stuurt Icepay de bevestiging naar een (door jou op te geven) URL, waarbij je die code uiteraard ook mee krijgt.

Mijn ervaring met Ogone is wat minder, wat vooral met de kosten te maken had.

[Verwijderd]

Weet iemand of je ook PCI DSS compliant moet zijn om louter iemand zijn NAW-gegevens en rekeningnummer op te slaan?

Wij zijn een site aan het bouwen waar je als gebruiker verdient, dus we moeten verdiensten kunnen uitkeren.

[Pin0]

Volgens mij niet, alleen als je gegevens van betaalpassen als Visa en Mastercard opslaat volgens mij.
Maar als je werkt met bijv. TWYP (soort ogone van de ing) als payment provider, hoeft het niet.

[cariolive23]

Verwijderd schreef op donderdag 18 februari 2010 @ 14:52:
Weet iemand of je ook PCI DSS compliant moet zijn om louter iemand zijn NAW-gegevens en rekeningnummer op te slaan?

Wij zijn een site aan het bouwen waar je als gebruiker verdient, dus we moeten verdiensten kunnen uitkeren.

Zorg voor een goede beveiliging en zorg er dus voor dat niemand bij gegevens kan komen waar ze niet bij mogen komen. Wanneer jouw webusers geen rechten hebben om de kolom met rekeninggegevens in tabel X op te vragen, zullen ze deze dus ook niet kunnen opvragen. Zo kun je op db-niveau de boel al gaan dichtspijkeren en zo moet je dus alles dichtspijkeren.

Helaas blijft SQL injection hoog in de top-10 van hacks staan, er zijn nog steeds te veel programmeurs die niet weten hoe een database moet worden ingericht en moet worden beveiligd en ze vragen niet om hulp bij deze zaken...

Het is niet moeilijk maar je moet wel de juiste kennis in huis hebben of in huis halen.

[Verwijderd]

Bedankt voor jullie antwoorden.

cariolive23: Gelukkig weet ik wat SQL injection is en voorkom ik dat in iedere query. Ook zal ik er van alles aan doen om de boel goed te beveiligen. De web user heeft op geen enkele manier direct toegang tot tabellen.

Echter mijn enige vraag is: Heeft PCI DSS compliance betrekking op bankrekeningnummers? Dus mag ik bankrekeningnummers opslaan zonder PCI DSS compliant te zijn ?

Da's het enige (naast NAW) dat ik van de gebruiker vraag. Ik wil namelijk de gebruiker geld uitkeren op het rekeningnummer dat hij invoert.

[cariolive23]

Verwijderd schreef op donderdag 18 februari 2010 @ 15:22:
cariolive23: Gelukkig weet ik wat SQL injection is en voorkom ik dat in iedere query. Ook zal ik er van alles aan doen om de boel goed te beveiligen. De web user heeft op geen enkele manier direct toegang tot tabellen.

Maar blijkbaar dus wel indirect... Het klinkt niet alsof hier een DBA bij betrokken is, je kunt namelijk gewoon voorkomen dat een webuser er überhaupt bij kan komen door simpelweg geen rechten toe te kennen. Of gebruik je geen aparte databaserollen per soort gebruiker?

Dat je SQL injection voorkomt in iedere query is heel mooi, maar de kans dat jij en al jouw voorgaande en toekomstige collega's tot in eeuwigheid waterdicht weten te houden, is niet zo groot. Zorg er dus voor dat bezoekers van jouw site nooit voldoende rechten kunnen krijgen om deze data in te zien, ook niet na een succesvolle hack.

[Verwijderd]

Dank. Ga ik scheiden.

Weet iemand nog iets over de noodzaak van PCI DSS compliance als je alleen een bankrekeningnummer en NAW gegevens opslaat?