Hoe veilig is dit

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Snelle Jaap

Snelle Jaap

21/02/2019 12:46:22
Quote Anchor link
Ik heb een webshop waar ik vanaf de checkout pagina allemaal info stuur naar een script. Dit script roept een api op van een paymentprovider en genereerd een betaallink waarnaar ik aan het einde van het script naartoe laad.

Wanneer er betaald is via die link kom je op status.php deze pagina krijgt een paar parameters mee vanaf bijvoorbeeld afterpay of ideal. Een van die parameters is de status, 100 is betaling geslaagd en zo heb je er nog een aantal.

Ik wil op status.php de status uit de url halen met $_GET en checken als die 100 is dat er dan een mail wordt verstuurd naar de klant en de bestelling wordt opgeslagen, daarna ook in de database opslaan dat de bestelling door is, hiermee kan ik voorkomen dat hij op refresh nog een mail stuurt en een order meerdere keren wordt opgeslagen.

Mijn vraag is, hoe veilig is dat? Op status.php kan ik in de url zelf de status op bijvoorbeeld -90 zetten en dan veranderd de tekst van 'bestelling geslaagd' naar 'bestelling geannuleerd'. Kan iemand die waarde ook al aanpassen van te voren? Dus stel ideal wijst de betaling af en stuurt je naar status?orderId=hetorderid&orderStatusId=-90&paymentSessionId=blalala kan iemand dit manipuleren wanneer die wordt doorverwezen?
 
PHP hulp

PHP hulp

23/03/2019 16:31:09
 
Dennis WhoCares

Dennis WhoCares

21/02/2019 13:52:40
Quote Anchor link
Hi Jaap,


Als dit zo werkt, kan je inderdaad (zodra je het weet uiteraard) gewoon de browser afsluiten nadat de betaling is gestart.
En vervolgens handmatig die url aanroepen om de betaling te laten 'slagen' volgens jouw systeem.


Volgens mij hebben de meeste betalingsproviders een 'api' dat je eerst aanroep om een betaling-request aan te maken.
Vervolgens krijg je een link om de gebruiker naartoe te verwijzen.

In de API kun je vaak een 'feedback url' instellen. Deze wordt aangeroepen door de betalingsprovider. Waarop je een 'id' ontvang welke je dmv de API de status kan opvragen en dus in je eigen systeem kan verwerken.
Daarnaast een 'return-url' voor na de betaling ongeacht of het betaald is ja/nee.

De feedback url hoeft dan alleen maar orderid te bevatten om vervolgens de status te bekijken.


Zelf gebruik ik mollie voor betalingen, is lekker makkelijk en behoorlijk veilig en werkt zoals boven omschreven.

Op de feedback url controlleer ik de status, en als de status 'paid' 'cancelled' 'expired' is zet ik een veld 'viewed' op 1.

Alleen als 'viewed' 0 is zal deze email sturen enz.
 
Thomas van den Heuvel

Thomas van den Heuvel

21/02/2019 14:22:11
Quote Anchor link
En uiteraard wordt er onder water ook nog van alles bevestigd via allerlei (controle)berichten. Dit soort "betalingsflows" zijn over het algemeen redelijk gestandaardiseerd en altijd, als het goed is, uitvoerig gedocumenteerd. Ook heb je vaak een test-modus waarbij je een of een aantal betaalmethoden kunt testen. Het is dan dus wel zaak dat je de regels van het spel volgt, je kunt hier niet zelf allerlei dingen omheen gaan breien.

Het zal vaak ongeveer als volgt gaan: heel kort door de bocht hoeft de PSP alleen maar te weten naar welke pagina deze na afloop terug dient te keren, dus wanneer deze "klaar" is. Daar (dus op je eigen website) controleer je (nogmaals) wat het resultaat van een betalingspoging is. En daarvandaan besluit je hoe je verder gaat. Je raadpleegt dus na de (externe) betaling zelf intern wat het resultaat is, dit moet je de PSP jou vertellen en dit zou ook de enige partij moeten zijn die dicteert hoe dit resultaat luidt... zoals @Dennis ook al aangaf.

Ik ga er vanuit dat alles via HTTPS verloopt?

Het lijkt mij trouwens niet de bedoeling dat informatie die dus op een veilige manier bevestigd dient te worden gewoon in de URL ingevuld kan worden... zelfs niet voor de eigen boekhouding. Dit kun je beter intern bijhouden na externe verificatie.

Ook dit:
Quote:
hiermee kan ik voorkomen dat hij op refresh nog een mail stuurt en een order meerdere keren wordt opgeslagen.

lijkt mij nou niet bepaald de bedoeling.

Zoals jij de informatie nu presenteert klinkt de huidige aanpak niet veilig.
 
Rob Doemaarwat

Rob Doemaarwat

21/02/2019 19:22:30
Quote Anchor link
Thomas van den Heuvel op 21/02/2019 14:22:11:
Daar (dus op je eigen website) controleer je (nogmaals) wat het resultaat van een betalingspoging is.

Sisow levert bijvoorbeeld een hash mee die is berekend op basis van alle parameters en een "secret" (wordt dus niet in de link meegestuurd). Maar die hash moet je dus nog wel zelf controleren. Doe je dat niet, dan loop je het risico dat iemand gewoon zelf een return-URL in elkaar draait (met een zelf verzonnen / niet kloppende hash).
 
Ivo P

Ivo P

22/02/2019 00:20:17
Quote Anchor link
daarnaast moet je ook rekening houden met klanten die na betaling niet terugkeren naar je site.
Bijvoorbeeld omdat na de melding van de betalingprovider de pagina 'betaling geslaagd' komt en de klant niet op je site komt omdat
- de bel net gaat
- de koffie klaar is
- de link niet werkt omdat de wifi even weg is
- nog 100 redenen.

Dan moet jouw site wel op de hoogte zijn van de geslaagde betaling en leveren, want anders heb je straks boze klanten en slechte reviews.

Je moet varen op de communicatie vanaf je provider. En alleen dat gebruiken. Komt je klant terug, dan hoor je al te weten of de betaling gelukt is of niet. De provider zal dat namelijk eerst melden voordat de klant zijn link of redirect-header krijgt. (al is dat misschien maar 100ms eerder)
 
Rob Doemaarwat

Rob Doemaarwat

22/02/2019 08:06:37
Quote Anchor link
Ivo P op 22/02/2019 00:20:17:
al is dat misschien maar 100ms eerder

Veel meer is het vaak niet. Soms ben je de boel nog aan het controleren / in de database aan het wegschrijven, en dan is de klant al weer op je site. Hij heeft dus betaald, maar het staat (nog net niet) in je database. Voordat je de klant dus een "huh - niet betaald" melding geeft moet je soms eerst heel even wachten en je DB nog een keer checken.
 
Snelle Jaap

Snelle Jaap

22/02/2019 09:54:47
Quote Anchor link
Wat Dennis zegt klopt inderdaad, ik gebruik de api van pay.nl en daar stel ik een return url in waarnaartoe wordt verwezen nadat een user bij de betaallink is geweest, hij verwoorde het misschien wat beter. Ik vroeg me af hoe makkelijk dat te manipuleren is (ervoor zorgen dat een order gemarkeerd wordt als succesvol terwijl hij om wat voor reden niet betaald is).
 
Ivo P

Ivo P

22/02/2019 10:35:49
Quote Anchor link
op https://www.pay.nl/webshops/plugins#anchor-eigen-implementatie staat het helemaal voorgekauwd:

1) bij het starten meldt PHP dat aan pay.nl. Je krijgt een transactionsID om op te slaan (bij je winkelmandje) en een redirect-locatie waar de klant heen gestuurd wordt (pay.nl waarschijnlijk + een herkenning voor pay.nl dat het om jouw klant gaat die 10.25 moet betalen.

Je geeft in die stap ook aan waarheen de klant na afloop terug moet komen, en het exchange-script. Dat laatste is waar de melding van pay.nl komt mbt voortgang betaling.

2) in exchange.php kun je de status verwerken. Zo te zien middels een trigger waarbij jij weer opvraagt bij pay.nl wat de status nu geworden is.
Ik mis daarin wel het gegeven om welke transactie dat gaan. Misschien zijn er wel 5 klanten tegelijk aan het betalen?
Misschien zit dat in GET-parameters?

3) Op de return pagina kun je ook reageren met dezelfde handelingen als in stap 2.
Maar je kunt ook eerst even kijken in je eigen database of je daar al hebt staan dat de betaling gelukt is.

Ik zou zorgen dat je handelingen als "artikel versturen" en "bevestiging mailen" laten afhangen van stap 2.


Het enige dat je klant zou kunnen knoeien, is het aangeven van een ander transactieID bij terugkomst. Maar aangezien je toch bij Pay.nl opvraagt wat de status is, kan dat geen kwaad.

Je moet niet handelen op basis van opvragen van stap 3 alleen
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.