 Erelid |
|
Normaal gezien als je een betaling inleidt zijn er afhankelijk van de provider verschillende mogelijkheden.
- Mogelijkheid 1: je stuurt een request naar de server van de provider, die stuurt jou een uniek kenmerk terug. Dat stuur je dan mee, meestal POST, soms in de URL, naar de provider, waar de klant dan de transactie kan afronden. Eens die transactie 'klaar' is krijg jij een call terug naar jouw site en kan je die betaling als 'voltooid' markeren, waardoor die dus al geen 2x kan gebruikt worden.
- Mogelijkheid 2: jij dient een uniek kenmerk te genereren - ik zit in de hotel-branche en bij ons is dat bijvoorbeeld een reservatienummer - en dat volgens een bepaald stramien te hashen. Zo heb je bijvoorbeeld, bij Rabobank in NL SHA1(bedrag|munt|merchantID|nogiets|mijnkenmerk). Dat verstuur je naar de server - aangezien zij weten wat jouw merchant ID en secret 'nogiets' is, kunnen ze die hash namaken en weten ze dus dat die authentiek is. Dat 'mijnkenmerk' stuur je ook nog gewoon losjes mee - maar als iemand die manipuleert klopt die hash dan weer niet. Na de betaling stuurt de provider dan terug een call naar jouw site, met eenzelfde hash die enkel jij kan namaken en dus verifiëren. Ook hier kan je de transactie 'voltooid' markeren waardoor die slechts eenmalig gebruikt kan worden.
En dan heb je nog de betaalmethodes waar er helemaal niets client-side naar provider wordt.
Het implementeren van betaalproviders is eigenlijk helemaal niet moeilijk, maar je hebt wat inzicht nodig in server-client principes en basis hashing.
Dat helemaal terzijde is de opmerking van ArieMedia niet onterecht: mensen betalen enkel voor kwaliteit, of ze moeten echt geld teveel hebben.
|
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
Actiefste leden van de maand
