HTTP redirection in the browser
Advice Use the HIDDEN PARAMETERS instead!
Why use static landing pages if you can use dynamic landing pages with the hidden parameters instead? Dynamic parameters give more flexibility towards ‘multiple shops’ and/or session-id’s!
The parameters are: ACCEPTURL, DECLINEURL, EXCEPTIONURL, CANCELURL.
HINT=> Don’t forget the HOMEURL and BACKURL
I want to receive transaction feedback parameters on the redirection URLs: advice yes
Ogone will add the postsale parameters (like status, payment method, error code) to your redirection URL’s (ACCEPTURL, DECLINEURL, EXCEPTIONURL, CANCELURL)
By this, your server get’s the (final)-status along with the return of the buyer!
Use this status update next to the server-to-server update to create a fluid and ‘alternative backup’ process.
Note1: Especially with high-volume processing this option is important because real-time database updates can’t be used!
Note2: As the parameters are shown in the URL, you must use SHA OUT to secure the workflow to avoid abuse!
I would like Ogone to display a short text to the customer on the secure payment page: advice no
If needed this option is nice to warn buyers about any HTTPS-to-HTTP-messages given by some browsers.
However, buyers intend to close their window after reading this. And because your shop needs the feedback parameters back with the redirection URL’s, our advice is not to use this option!
Timing of the request
Advice Always deferred
Always deferred because the buyer will already bring back the post-sale parameters realtime/online with the redirection URL’s. And ‘deferred’ minimizes the chance of an update of a locked record. Also with high transaction volume online/realtime is no option. By this option Ogone will do the redirection first and after that will send the Postsale.
With this option, Ogone will redirect the cardholder first, that Ogone will send the Postsale. If Ogone don’t get a HTTP200 response from your server on the send Postsale, the Postsale will be send four times with an interval of ten minutes.
URL of the merchant’s post-payment page: Advice ‘Create a generic parameter update process’
IMPORTANT: This point is NOT used for the buyer/consumer (they will be redirected to redirection-URL’s, which you send to Ogone initially as hidden parameters). With this option is the Ogone-server updating your orderdatabase!
You have to write a little program which accepts the post-payment transactions parameters which Ogone will post towards your script. It’s like:
Just keep your script the same for successful and declined transactions because it’s better just to update the order database and interpret the transaction status! Status 5 and 9 are successful. Other transactions are not.
IMPORTANT: always update the order database with the Ogone transaction parameters. Also with cancelled (status 1) and declined transactions (status 2).
· List of status & error codes: secure.ogone.com/ncol/test/paymentinfos.asp
HINT: make sure to receive email notification of Ogone (see next ‘tab’) because Ogone shows the post-sale in the email conformation as well (easily reverse engineering).
Request method: Advice post
Most common setting.
Dynamic e-Commerce parameters
Select all the parameters
All the parameters which are selected have to add to the SHA-OUT STRING to HASH.
· All parameters that you send will be included in the string to be hashed.
· All parameter names should be in UPPERC ASE (to avoid any case confusion). Except: orderID, currency and amount.
· All parameters need to be arranged alphabetically.
· Parameters that do not have a value should NOT be included in the string to hash.
· Between each parameter and value you have to fill in the SHA-OUT pass phrase and on the end of the total STRING to HASH
amount=1090pass phrasecurrency=EURpass phraseNCERROR=0pass phraseorderID=1001110pass
phrasePAYID=22200013pass phraseSTATUS=9 pass phrase
I want Ogone to display a ‘processing’ message to the customer during payment processing
Today buyers know to wait a few seconds and don’t need a ‘pop-up message’ anymore. And because transaction processing became so fast, in many cases the buyer will think the message is an error-message.
I want Ogone to re-launch the ‘end of transaction’ process
In case the re-direction back to the website of the merchant was unsuccessful, or the client refreshes his web browser or plays around with the back/forward-buttons, Ogone will redirect the client again to the same landing page as Ogone used for the initial transaction.
If you only update the order database, this should not lead to complications.
Note: Be aware this could mean your webshop get’s an additional (same) update.
SHA_OUT Pass phrase:
Of course it’s more secure to use different SHA-IN and SHA-OUT pass phrases. Practically we see almost every webshop vendor and/or ICT-integration company use the same to avoid miscommunication and mistakes.
HTTP request for status changes, Timing of the request: Advice For each offline status change
Some payment methods could deliver deferred additional payment statuses (like charge backs). Or, depending on the integration, some Ogone back office actions like (partial)-refunds will result in a new transaction status. For these situations Ogone is able to send the new payment status again to your order database/webshop!
URL on which the deferred HTTP requests should be delivered: Advice ‘Same script as Direct HTTP-request’
If your Direct HTTP server-to-server script is only updating the status into the order database of the webshop, we advice to use the same script for this delayed update as well!