In plaats van de documentatie aan te passen moet je de foutmeldingen aanpassen in de testomgeving. Alle problemen staan hierboven beschreven, je kan deze perfect allemaal reproduceren en matchen. Is het niet beter om de foutmeldingen dan te gaan uitbreiden in de testomgeving met extra informatie, dan de documentatie te gaan herschrijven. Het is tenslotte toch maar een test-omgeving. Een error zoals ‘unknown order/0/s’ zegt niemand iets…

Add-on: maak eens een goed werkend eenvoudig PHP voorbeeld van een Ogone implementatie. Met alle noodzakelijke features want dat is echt wel iets wat momenteel ontbreekt of onduidelijk is. Zet dat duidelijk in de docs dat je daar een voorbeeld kan downloaden, werk een systeem uit zoals PayPalX waar je stap voor stap je script kan configureren.

Bijkomende vraag: wanneer krijgt het Ogone Controlpanel eens een update want dat is echt niet meer van deze tijd .

op het betalingsplatform veranderd er niets in verband met SHA.

Het documentatie is ondertussen verbeterd en up-to-date. Er komt met ons volgend release (nov 2011) nog een extra waarschuwing in verband met de SHA passphrase op het einde van de string to hash, blijkbaar een veelgemaakte fout.

Indien jullie verder nog opmerkingen/vragen hebben ivm het documentatie mogen jullie altijd mailen naar: documentation@ogone.com

Mvg,
Hubert Vandermeersch
Documentation Coordinator, Ogone.

We raden je echter aan de library aan je project te koppelen via GIT of SVN. Dit laat op termijn toe om veel makkelijker een nieuwe versie (een nieuwe tag) van de library te gebruiken in je project.

Qua parameters zit alles in de API van de library verwerkt, dus daar kan je alles vlot in configureren.

We plannen nog een specifieke post op onze blog met volledig uitgewerkte voorbeelden.

Anders mooi werk!

Heb er uiteindelijk hetvolgende voor gedaan om de SHAsign te genereren:

$sha_string = (‘AMOUNT=’.$amount.$shain.’CURRENCY=’.$currency.$shain.’LANGUAGE=’.$language.$shain.’ORDERID=’.$orderid.$shain.’PAYID=’.$payid.$shain.’PSPID=’.$pspid.$shain);

$sha_signature = strtoupper (sha1 ($sha_string));

Hierin is de $shain het SHA-IN key die je in de Ogone configuratie hebt ingevuld op je account pagina bij hen.

Daar zat dan nog ergens een foutje in bij m’n eerste poging… had een paar variabelen door elkaar gekieperd… maar nu werkt het wel.

Hopelijk helpt het bovenstaande nog andere mensen die met hetzelfde probleem worstelen?

Toch bedankt voor alle hulp en info!

We (Marlon) hebben vandaag een open source Ogone PHP library gereleased op Github: https://github.com/marlon-be/marlon-ogone

Hopelijk kan dit bovenstaande problemen met de soms onduidelijke Ogone documentatie vlot oplossen.

Alle feedback is welkom.

Groeten,
Dieter

Met die code kan ik niet zo heel veel doen. Heb je geen specifiek geval? Desnoods mail me eens op info@minion.be met uw vraag dan kan ik deze beantwoorden.

Pieter

:p

$_POST["name"];
$_POST["orderid"];
$_POST["email"];
$_POST["tel"];

en eventuele anderen die ik zelf nog vergeten ben…?
Heel erg bedankt!

– start php
$sha1 = strtoupper(sha1(‘AMOUNT=MYAMOUNTMYSHA1INCURRENCY=EURMYSHA1INLANGUAGE=nl_NLMYSHA1INORDERID=MYORDERIDMYSHA1INPSPID=MYPSPIDMYSHA1IN’));
– end php

– start form
form action=”https://internetkassa.abnamro.nl/ncol/test/orderstandard_utf8.asp” method=”post”>
input type=”hidden” name=”PSPID” value=”MYPSPID”>
input type=”hidden” name=”ORDERID” value=”MYORDERID”>
input type=”hidden” name=”AMOUNT” value=”MYAMOUNT”>
input type=”hidden” name=”CURRENCY” value=”EUR”>
input type=”hidden” name=”LANGUAGE” value=”nl_NL”>
input type=”hidden” name=”SHASIGN” value=”">
input type=”submit” class=”input_button” value=”Start iDeal”>
/form>
– end form

<input type="hidden" name="SHASIGN" value="”>

Als je alles doorstuurt in UTF-8 moet je niet posten naar de default url https://secure.ogone.com/ncol/test/orderstandard.asp maar naar https://secure.ogone.com/ncol/test/orderstandard_utf8.asp

98% van de bestellingen zullen op de standaard url ook wel werken, maar van zodra er iemand bestelt met een accent in zijn naam of adres, loopt je bestelling vast. Ogone zal zijn SHA-IN anders interpreteren, waardoor je order niet gevalideerd wordt en ogone je de bekende ‘unknown order/1/s‘ geeft. René uit liège zal dus niks kunnen bestellen

Kwam toevallig bij het zoeken naar een oplossing hier uit dus ik dacht: ik geef het meteen eventjes mee

Ik heb alvast in de blogpost ook nog eens duidelijk vermeld dat je op het einde van de SHA string ook nog de passkey moet toevoegen.

Na alles 824 keer te hebben gecontroleerd (als ‘t niet meer is) heb ik maar eens geprobeerd m’n URLS te fixen.

Er stonden namelijk &’s in mn URLs. Ik heb bij elke URL het gedeelte ‘amp;’ weggehaald en het hele rampje opnieuw getest..

Eindelijk werkt ‘t!!

Goed zo Ogone!!! (k*t asp).

M’n ervaring met Ogone so far; zeer slecht.
niet gebruiksvriendelijk, log, onduidelijk, langdradig, saai.

Ik heb ook zitten schelden op iDeal Easy van ABN; Het is way-to-simple en niet helemaal duidelijk.
Vergeleken met Ogone had ik dat in ieder geval binnen enkele uren up-and-running.

Ik had de string laten samenvoegen m.b.v. de PHP functie ‘implode’ en na lang zoeken ( want het werkte maar niet ) kwam ik hier terecht en zag ik dat de SHA string moet eindigen op de passwordkey.

Rex, bedankt! En OGone: waarom staat dit niet in de documentatie?!

Voor mijzelf heb ik de volgende SHA-1 string conditions maar even in de code gezet, zodat ik ze niet vergeet, misschien handig voor iemand anders:

1. ALL PARAMETER NAMES IN CAPS
2. ALPHABETIC ORDER OF PARAMETERS IN STRING
3. FINAL SHA STRING MUST BE CAPITALIZE
4. SWITCH CHARACTER ENCODING ( AT OGONE SIDE ) TO UTF-8
5. parameters that do not have a value should NOT be included in the string to hash
6. END YOUR COMBINE STRING WITH THE SHA KEY

Het toevoegen van die return URLs kan best lastig zijn, aangezien je er wel voor moet zorgen dat de URLs waar je de signature mee maakt, 100% overeen komen met de URLs die je in het form zet.

Het is best een gedoe om die SHA sign strings goed te krijgen en te houden!

Communicatie is er dus eigenlijk totaal niet geweest…