Webwinkel Forum

Iemand enig idee hieromtrent?

Ik ben inmiddels zover dat ik sisow betalings"methode" heb kunnen implementeren
binnen php. Althans, in test modus.

Nu heb ik het zo dat ik na klikken/kiezen van de bank e.d. ik uitkom op een pagina met xml (met een url er in die je weer nodig hebt om de betaling bij sisow te voltooien(niet de gekozen bank zelf))...

Wat ik verwacht is dat ik naar de gekozen bank ga, en de betaling wordt volbracht met de gewenste gegevens.

Wat is de bedoeling dat ik met die XML doe?

Ik begrijp even het stukje niet tussen xml en de gewenste stap naar de gekozen bank waar ik de betaler wil laten uitkomen...

Iemand die het kan uitleggen misschien?

Met die eerste request zet je een iDEAL-transactie klaar. De response bestaat uit een XML-document waarin je onder andere de unieke transactie-ID terugvindt en een redirect-URL. Die ID sla je ergens op (in je database) en de URL gebruik je om de client om te leiden naar de iDEAL-site van de gekozen bank.

Ward, dankjewel

Dus als ik het goed begrijp moet ik de url uit die xml gaan halen...
Klopt het dat je dat met "curl" doet? Enig idee misschien?

Gr Eric

Ja dat klopt, maar dan omgekeerd: je haalt het XML-bestand op met cURL en daarna verwerk je de response met bijvoorbeeld SimpleXML.

Je kunt bij Sisow zelf overigens PHP-voorbeelden aanvragen. Verder vind je er verschillende op GitHub.

ok...
Ja, ik heb dat voorbeeld ook. Maar als ik die gebruik blijft de url waarnaar ik submit zeggen dat ik een inactive account heb/gebruik. En dat klopt, want hij staat in testmodus.
Maaaarrr.....
Als ik zelf de url maak en daarmee naar de handler van sisow ga, krijg ik wel mooie xml code, mét 'issuerurl'... en mag ik wel test transacties doen.

Dus ik snap nog niet helemaal waarom dat met die payment.php nou niet goed gaat...
Ik heb daartoe Sisow maar even een mail gestuurd...

In elk geval dank zover!
Mocht het nodig zijn, moet ik het anders maar handmatig zelf programmeren...(waar ik dan weer niet echt heel blij van wordt )
'k Wacht eerst even de mail van Sisow af maar...

Inmiddels het probleem (zelf) gevonden. De hulp van Sisow was helaas niet toereikend
Mocht iemand het ooit eens nodig hebben of ertegenaan lopen:

Als je wil testen met de aangeleverde payment.php en sisow.cls5.php ga dan naar regel 207 in sisow.cls5.php.

Wijzig die dan in: if (!$this->send("TransactionRequest?testmode=true", $pars))

---
Nog 1 laatste vraag...
Ik kan zelf een return url aangeven. Als ik een testbetaling doe krijg ik dan zoiets terug:
.../success.php?status=Success&trxid=TEST080412345678&ec=mijnomschr&sha1=14ae1281e83407b6b99979078bc6bv463c2793ef

Hoe bepaal ik nou m.b.v. die url welke gebruiker betaald heeft?
Ik bedoel eigenlijk, kan ik manipuleren met de sh1 code?

erict21 schreef:Het enige wat ik wil is dat een buitenstaander handmatig dingen kan manipuleren in de return-url, waardoor een persoon onterecht een markering betaald in de database krijgt.

Dat is de achilleshiel van iDEAL: de return-URL vervalsen om te “faken” dat er is betaald.

Zorg dat je dit onderdeel onder de knie krijgt. Anders gaan studenten eindeloos gratis pizza bestellen… (true story)

Ward schreef:

erict21 schreef:Het enige wat ik wil is dat een buitenstaander handmatig dingen kan manipuleren in de return-url, waardoor een persoon onterecht een markering betaald in de database krijgt.

Dat is de achilleshiel van iDEAL: de return-URL vervalsen om te “faken” dat er is betaald.

Zorg dat je dit onderdeel onder de knie krijgt. Anders gaan studenten eindeloos gratis pizza bestellen… (true story)

Sorry, dit is een foutje mijnerzijds! Dit had uiteraard moeten zijn:
"Het enige wat ik wil voorkomen is dat een buitenstaander..."

Ik heb mijn vraagstelling inmiddels hierboven wat aangepast...
(Hoe bepaal ik nou m.b.v. die url welke gebruiker betaald heeft?
Ik bedoel eigenlijk, kan ik dat uit de sha1 code halen?)

Je kunt grofweg op 2½ manier controleren of de betaling is geslaagd:

1. Push: de PSP meldt aan je webshop dat de betaling is geslaagd.

2. Pull: je webshop vraagt aan de PSP of de betaling is geslaagd.

3. Beide: push + pull.

In géén geval heeft de client die de transactie start (de bezoeker/klant) ook maar iets te maken met dit dataverkeer tussen jouw webserver en die van de PSP. Dat is dé klassieke standaardfout bij iDEAL-implementaties: de bezoeker bepaalt niet of de transactie is geslaagd, dat doe jij zelf of de PSP.

Hmzzz....ok. Dan moet ik even iets anders gaan bedenken.
Het is in elk geval helder... waarvoor dank!

Waarom ik het wil is eigenlijk vanwege het volgende (het gaat om een lidmaatschap van een vereniging):

Situatie:
- iemand meldt zich aan. Gegevens worden weggeschreven naar dB.
- volgende pagina wordt dan de betaling. Maar als aanmelder er achter komt dat er bijv niet voldoende saldo is, zal deze de betaling cancellen.
- in het geval van cancellen moet de ingeschreven persoon weer uit de database, of een markering 'niet betaald' krijgen in de db (met als logisch gevolg dat dan bij een succesvolle betaling dat ook aangegeven moet worden).

Ik denk dat ik het op kan lossen door de referer op te vragen i.c.m. het transactieID.
Ik ga in elk geval nog even wat puzzelen en denken

Heel veel dank voor de hulp!

Vr gr Eric

Elke transactie die gestart wordt heeft een unieke transactie ID. Ik doe bij elke gestarte transactie in een aparte DB tabel opslaan de transactie ID, het transactie bedrag en het ordernummer.

Bij het terug komen op de website worden deze waardes vergeleken met de huidige status van de order.

Dan haal je meerdere potentiële misbruik methodes er uit. Doordat je het bedrag bij het transactie ID bij de start van de transactie opgeslagen hebt, kunt je bij de afronding het transactie bedrag en het orderbedrag op dat moment vergelijken. Daarmee voorkom je de bug waar JustEat een aantal jaar geleden mee te maken had met de studenten met de gratis pizza.

Return URL dingen in veranderen is vrij nutteloos. De order van de klant koppel je immers toch aan een sessie en niet aan de return URL? Daarbij is de kans, dat iemand een valide transactie ID raad wel immens klein... onmogelijk?

Dat heb ik gedaan om te proberen de gaten in ideal te dichten. Dat is denk ik met SiSow ook afdoende?

NOP Webdesign schreef: Return URL dingen in veranderen is vrij nutteloos. De order van de klant koppel je immers toch aan een sessie en niet aan de return URL?

Precies! Daarom wil ik ook voorkomen iets met de return url te doen
Ik zal eens kijken naar die transaction id aan het begin. Dankje!

NOP Webdesign schreef:Return URL dingen in veranderen is vrij nutteloos. De order van de klant koppel je immers toch aan een sessie en niet aan de return URL? Daarbij is de kans, dat iemand een valide transactie ID raad wel immens klein... onmogelijk?

Je kunt in de return-URL wel een transactie-ID meegeven, bijvoorbeeld om volledig onafhankelijk te zijn van (verlopen) sessies, zolang je bij de return maar een extra controle uitvoert: een request verzenden naar de PSP om de huidige status van de transactie op te halen. Dat is de pull-methode.

De push-methode werkt omgekeerd. Daarbij post de PSP een request met de actuele status naar een (verborgen en beveiligde) applicatie op jouw server. Dat is nog betrouwbaarder, omdat je ook status-updates ontvangt wanneer de bezoeker niet op je server actief is (maar bijvoorbeeld in de iDEAL-omgeving van zijn bank) en wanneer de bezoeker eventueel helemaal niet terugkeert. De push-methode loopt helemaal buiten de bezoeker om en is daarom niet afhankelijk van een return-URL.

Iemand kan betalen (transactie geslaagd) maar vervolgens niet terugkeren naar je site omdat een internetverbinding eruit vliegt of een overijverige browser een redirect weigert. Daarom mag je het slagen/falen van een transactie sowieso nooit afhankelijk maken van een return-URL of een lokale sessie.

Ik loop tegen hetzelfde probleem als erict21 in het begin. Ik krijg een XML reply met daarin een URL. Alleen de URL ziet er zo uit:

<issuerurl>
https%3a%2f%2fwww.abnamro.nl%2fnl%2......................</issuerurl>

Hoe kan die opschonen naar dit:
https://www.abnamro.nl/nl/ideal/....

Ik snap dat ik het met simpleXML het moet verwerken.

Dat kan met de PHP-functie urldecode().

Al het begin is moeilijk, maar bedenk wel goed of je de betaalfunctie wel helemaal zelf wilt programmeren als je kennis op dat gebied wellicht beperkt is. Wil niemand ontmoedigen wat te leren, maar is wel belangrijk dat dat onderdeel van je webwinkel veilig is.