Hoe veilig is dit
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?
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.
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.
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).
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)
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.
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