Frequently asked questions
- How to show modules after a payment?
- [Virtuemart] No redirect to payment after checkout
- Customising the “Select your bank” page
- Foutmelding van iDEAL: Failure in system
- iDEAL error: required fields missing
- Payment status not updated or is always “not paid, please retry”
- How to disable Bootstrap or jQuery in cciDEAL
- [MOLLIE] Not redirected to iDEAL after selecting bank
- [TARGETPAY] Laden XML bestand mislukt/failed to load external entity
- [TARGETPAY] Could not fetch response
- [ING/RABO/ABN] Invalid electronic signature SE2700
- [ING/RABO/ABN]Warning: fopen() …. [function.fopen]: failed to open stream
- [ING/RABO/ABN]Value too short, Field too short, Value too long, Field too long
- [ING/RABO/ABN]PHP Fatal error: Call to undefined function: openssl_x509_read()
- [ING/RABO/ABN]iDEAL and Windows IIS issues
- [ING/RABO/ABN]Warning: openssl_sign() … supplied key param cannot …
- [ING/RABO/ABN]Warning: openssl_sign() … Unknown signature algorithm …
- [ING/RABO/ABN]Authentication error – Field generating error: Signature Bank fout code : SE2000
- [OMNIKASSA] Error: Er is een fout opgetreden. Neem contact op met uw dealer.
- [OMNIKASSA] How to use the different ID’s for my administration?
- [OMNIKASSA] After return from OmniKassa, pop up error about insecure items
- [OMNIKASSA] At bank: “The server detected an error.”
- [OMNIKASSA] Don’t always get e-mails after an order, but the status is updated
How to show modules after a payment?
cciDEAL will automatically register what modules are shown on the last page before the customer goes to payment. When he returns, those same modules will be shown in the return message. So actually, you have to do nothing to show these modules.
[Virtuemart] No redirect to payment after checkout
Problem: after placing an order in Virtuemart, Virtuemart does not redirect to cciDEAL or the payment provider.
This problem can have multiple causes and solutions:
- If you have custom templates for the checkout, try disabling them. Does Virtuemart then redirect? In that case there is an issue in your templates (maybe they are outdated) that you need to research and solve.
- If you are using a One Page Checkout (OPC) extension with Virtuemart, please remember to always use the latest version of that OPC extension, with the latest version of Virtuemart and cciDEAL. You might otherwise get issues with payments if you only update Virtuemart or cciDEAL and not the OPC extension.
Customising the “Select your bank” page
Some payment providers shows a “Select your bank page” on your website where your customer can choose his bank. This happens before they are sent to iDEAL or other payment methods.
This page can be customized. It uses the default CSS framework of Joomla! 3, Twitter Bootstrap 2.3.2. You can either use CSS classes from Bootstrap to change the design of the page, or develop your own design. When you do, be sure to use Joomla! Template overrides, even via the Template Manager to do this. This will make sure that your changes will not be lost when you update cciDEAL. You can find the files to edit in /components/com_ccidealplatform/views/ccideal/tmpl/default_bankform.php.
Foutmelding van iDEAL: Failure in system
There can be two causes for this issue:
- ING Advanced/Rabobank Professional only: go to Components > cciDEAL Platform and make sure the value “SubID” is entered (for example “0”). Then make a test payment again.
- Otherwise this is a iDEAL system warning (code: SO1000) which means there is maintenance happening on iDEAL. Pause for now and do a test payment again after 5 hours to see if the bank has completed the maintenance.
iDEAL error: required fields missing
Not all configuration details are entered correctly. Go to Components > cciDEAL Platform and check if all details are present, then save the configuration. If you then still have the issue, please create a new ticket.
Payment status not updated or is always “not paid, please retry”
- Localhost: You can not use/test iDEAL or cciDEAL Platform on your localhost, you need to test it on a real server. So move the current website to a live server (a test directory is possible) and test it there.
- HTTP to HTTPS redirect: does your site run on HTTPS? Make sure users can only access the site on HTTPS. Otherwise payment providers might get webhook communication issues when the HTTP communication is redirected to HTTPS, which causes the POST information to be removed from the webhook communication. Also make sure System > Global configuration > Server > Force SSL is set to “Entire site”. And possibly add a hard-coded redirect from HTTP to HTTPS to your .htaccess file (Search for details on how to do this).
- Offline mode: during iDEAL/payments testing the website should not be in “Offline mode” (Site > Global Configuration > Site Offline), as this will block the iDEAL communication.
- Firewall or htaccess authorization: during iDEAL/payments testing the website should not be hidden behind any kind of “full site firewall” or htaccess authorization. It’s fine to only secure the /administrator folder with htaccess, but putting the entire site behind htaccess will block the iDEAL communication back to the site.
- Security extensions (RSFirewall, sh404SEF, Akeeba Admin Tools) and a more restricting .htaccess file than default Joomla! will in some cases also block the iDEAL communication. Turning them off is not always the solution (sh404SEF), you need to uninstall them to make sure they are not the cause of this issue.
- RSFireWall: in the case of RSFirewall, disable “System – RSFirewall! Active Scanner” plugin. If you want to keep using the RSFirewall Active Scanner, go to Firewall Configuration > Active Scanner > Deny access to the following User Agents, disable “Java” and make sure country blocking is disabled!
- Akeeba AdminTools:
- Go to AdminTools > .htaccess Maker > Block access from specific user agents and set that to “no”.
- In “Allow direct access to these files” add components/com_ccidealplatform/models/ccideal.php and components/com_ccidealplatform/controller.php.
- Go to “Allow direct access, including .php files in these directories”, and add “components/com_ccidealplatform/”.
- Disable the CSRF shield.
- Webhosting companies: Your webhosting company might also block communication by Mollie. Explain the issue to your webhoster and tell them to check their access logs or Firewall logs for bot requests to a URL containing /index.php?option=com_ccidealplatform. This communication (by the payment provider) should not be blocked.
- Gzip compression: Is Gzip compression enabled in the Joomla global configuration? Try disabling and try again.
- Communication test: It’s possible that external communication to cciDEAL is blocked (by a firewall, security extension). In your terminal type curl yourdomain.com/index.php?option=com_ccidealplatform and make sure that you don’t get any messages like “Blocked, likely Malware” or things like that. The response should be a Joomla template, any almost all responses are okay (302 Found, document moved), just not messages with an error or block.
- Joomla 1.6-1.7: There appears to be a conflict (for now only with Mollie?) in Joomla! 1.7 (and maybe 1.6 and 2.5) when the plugin “Language filter” (Taal filter) is enabled. We are investigating this now. Please check in Extensions > Plugin Manager if you have this enabled. If you do, disable it, and test making a payment again. Please let us know if you run into this issue.
How to disable Bootstrap or jQuery in cciDEAL
ccNewsletter 2.x and up: In ccNewsletter 2.x+ we implemented “Chill Creations Bootstrap” to load Bootstrap and jQuery in sites that do not load them already. You can disable “Chill Creations Bootstrap” in the configuration of our extensions. Older versions: Assuming that your template folder is called mytemplate, copy: media/akeeba_strapper/strapper.ini to templates/mytemplate/media/akeeba_strapper/strapper.ini Then read the contents of strapper.ini to learn how to disable Bootstrap and/or jQuery. These settings will automatically apply to all extensions that use Akeeba Strapper, such as ccNewsletter, ccInvoices, CookieConfirm and all extensions from Akeeba.
[MOLLIE] Not redirected to iDEAL after selecting bank
Question: After selecting iDEAL, I select a bank in the dropdown, but after that I am not redirected to the bank iDEAL page, sometimes I am redirected back to the site home page instead.
Please check all these options:
- Make sure mollie.com account is active for receiving iDEAL payments, as described in the manual.
- If you have set Mollie to test in cciDEAL Platform, make sure its also set to test on mollie.com under “Mijn betaaldiensten > Instellingen > iDEAL API testmode > iDEAL API testmode aan”. Or if its set to production, make sure testmode is disabled.
- Make sure the payment amount total is more then €2.
- In cciDEAL Platform find the Mollie ID, then go to mollie.com and under “Mijn account > Account gegevens > Partner ID / klant ID” make sure the ID’s are 100% the same.
- Ask the hoster if they have “fsockopen” enabled and not firewalled. This is needed for the XML communication of mollie.com.
[TARGETPAY] Laden XML bestand mislukt/failed to load external entity
The PHP module “allow_url_fopen” needs to be enabled. Ask your webhoster to enable this.
[TARGETPAY] Could not fetch response
Instructions after September 2015:
In cciDEAL 4.5.0 I my own cacert.pem to cciDEAL for TargetPay, because (a) webhosters have outdated versions on their server and have no idea how to update them (bad sign, find a new hoster!), and (b) TargetPay is too lazy to add one to their API Client themselves. So, that’s why you guys and galls buy cciDEAL. 🙂
Instructions before September 2015:
The GlobalSign certificate on your server is probably expired, your hoster should look into this. Send this information to your hoster.
Het GlobalSign root certificaat op uw server is mogelijk verlopen. U kunt met behulp van het onderstaande commando testen of dit op uw server het geval is. Vanaf de commandline moet dan het onderstaande commando worden uitgevoerd. Als er nu een foutmelding verschijnt dan moet er een update van het GlobalSign root-certificaat worden geïnstalleerd.
If the hoster does not respond quickly enough you can use the following (temporary) work around:
- Via FTP go to components/com_ccidealplatform/ccideal_targetpay
- Open the file TargetPay.class.php
- Search for the text “curl_setopt” to find the line “curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1) ;”
- Beneath that line add “curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);”
- Save that file, TargetPay payments should now work!
[ING/RABO/ABN] Invalid electronic signature SE2700
When you get this error, there is an issue with the certificates:
- they might be expired
- the private key for the certificates is incorrect
- they might be corrupted on the site
- they might be out of sync (others used in site and in dashboard
In all cases, the easiest solution is to create new certificates (see the manual), and upload them to cciDEAL and to the iDEAL test and production dashboard. It is important to do this with great care, to make sure you uploaded the correct certificates in all locations.
[ING/RABO/ABN]Warning: fopen() …. [function.fopen]: failed to open stream
One example error message:
Warning: fopen(../components/com_ccidealplatform/ccideal/thinmpi.log) [function.fopen]: failed to open stream: Permission denied
It means that the file mentioned in the underlined section, does not have the correct CHMOD/permissions. You will need to go to files via FTP and CHMOD it to the correct settings (most of the time CHMOD to 644), depending on your server settings. If CHMOD 644 does not work, try 755, and otherwise 777. When you need to use 777, you should know that this is not secure, and you should ask your hoster to configure the server better, for example by using suPHP.
If you use ING Advanced with iDEAL 2 (account from before 01-10-2012), in FTP change the file permissions of these files:
If you use Rabobank Professional with iDEAL 2 (account from before 01-10-2012), in FTP change the file permissions of these files:
If you use ING Advanced or Rabobank Professional with iDEAL 3 (account from after 01-10-2012), in FTP change the file permissions of these files:
[ING/RABO/ABN]Value too short, Field too short, Value too long, Field too long
- Solution 1
- Go to Components > cciDEAL Platform > Configuration > iDEAL Account
- Check that the value in iDEAL ID is entered and has 9 characters (format is 00xxxxxxx, the 0’s are required!).
- Also check that the SubID value is entered (0 most of the time) and the Private Key is also entered.
- Now make a payment to see if this solved the issue.
- Solution 2
- Create new certificates (see link in the manual) with a longer (7 characters) private key
- only lowercase letters and numbers
- no special characters like ; + * ( ) etc
- no spaces
- no uppercase/capital letters
- Upload the new certificates to the TEST and PRODUCTION dashboard of your bank
- Upload the new certificates to cciDEAL
- Retry testing cciDEAL, if you still get this issue send a support email.
- Create new certificates (see link in the manual) with a longer (7 characters) private key
[ING/RABO/ABN]PHP Fatal error: Call to undefined function: openssl_x509_read()
Most of the time, this issue is resolved by the following: OpenSSL is disabled by default in php.ini. You need to modify php.ini to change this. If you do not know how to do this, contact your webhoster and point them to this FAQ item.
1. Find the following code in php.ini.
2. Change this, remove the “;” so it becomes:
[ING/RABO/ABN]iDEAL and Windows IIS issues
Possible error: Warning: fsockopen():no SSL support in this build
OpenSSL has not been properly installed or enabled.
- See: http://kb.ucla.edu/articles/using-ssl-socket-in-php-under-windows
- (Ask the hoster) to install latest version of PHP
- Turn on the extension php_openssl.dll in .htaccess
[ING/RABO/ABN]Warning: openssl_sign() … supplied key param cannot …
This error message can have different causes:
- The certificates (for ING Advanced or Rabobank Professional) have not been added to cciDEAL Platform, or both of the bank dashboards (test and production)
- The private key used for the certificates is not the same as the one mentioned in cciDEAL Platform, please check.
- The generated certificates for ING Advanced and Rabobank Professional are corrupted. Create new certificates and re-add them to cciDEAL Platform and the bank dashboards
[ING/RABO/ABN]Warning: openssl_sign() … Unknown signature algorithm …
[ING/RABO/ABN]Authentication error – Field generating error: Signature Bank fout code : SE2000
There are a few possible causes for this error:
- The private key for the certificates or the certificates themselves is not correctly added in test AND production dashboard AND cciDEAL
- The certificates are corrupted. Best solution is to create new certificates and add them in test, production dashboard and cciDEAL
- The merchant ID is not correct or the same value in the test/production dashboard and cciDEAL.
[OMNIKASSA] Error: Er is een fout opgetreden. Neem contact op met uw dealer.
This error can be caused by different issues. Please review them all.
- Contact the Rabobank (your dealer). The selected payment method is not activated for this Rabo OmniKassa account. To activate the payment method, contact the Rabobank or use the Rabo OmniKassa dashboard.
- The URL/website address that requests the payment is not the same one as registered with the Rabobank. Even http://www.yourdomain.nl and http://yourdomain.nl are seen as different URLs. Contact the bank and ask what domain they have on file, then use htaccess to make sure the correct domain is always used. This issue can be caused by enabling “Redirect www and non-www adresses” in Admin Tools > .htaccess maker.
[OMNIKASSA] How to use the different ID’s for my administration?
For your bookkeeping (boekhouding) it is important to identify payments and orders in your software and your bank account statements. If a payment is made in your software (for example in Joomla! with Virtuemart) the software will generate an ID (order ID, purchase ID, invoice ID or payment ID). Accountants would love to see this orderID or other customer details in your bank statement, so the accountant can easily identify a payment, and connect it to a certain order.
OrderID in webshops bank statement
Unfortunately, the orderID will never be shown in the bank statement of the webshop. Income from Rabo OmniKassa is paid to your bank account in a batch, and therefor individual orderID’s can not be shown on your bank statement.
OrderID in the webshop customers bankstatement
The orderID might be shown on the bank statement of your customer, but because the OrderID is not a mandatory field, most of the times it is not. We have absolutely no control over when it is or is not shown. We have discussed this with the Rabobank and they have confirmed this is not a bug, but intended behaviour.
Solution: do a cross-reference
As a middleman between the software (Virtuemart or RSForm Pro) and the bank (Rabo OmniKassa by the Rabobank) we do not have control over what exact information is shown in the bank statement. The Rabo OmniKassa system does not allow us to send other information directly to the bank statement. The real control is off course with the Rabobank. Therefor, we choose to show all possible ID’s and information used in a payment via cciDEAL in cciDEAL > Payments. The Rabobank shows all possible IDs in the CSV file that can be exported from the payments overview in the Rabo OmniKassa dashboard. Our advice, is to use (1) the payments overview in cciDEAL, (2) the payment CSV export in the Rabo OmniKassa dashboard and possibly (3) the order/payments overview in the extension you use (Virtuemart, RSForm Pro etc) and cross-reference the payments and ID’s to each other. The Rabobank gives the advice to use the “transaction reference” as the ID to cross-reference the different lists. Please also note that more information about each payment can be found in the e-statement, the excel sheet attached to all Rabo OmniKassa payment notification e-mails (sent by the Rabobank, not by Joomla! or our extensions).
We are already sending all possible information, including the orderID to Rabo OmniKassa. The bank chooses what details are shown in the bank statement. If you want the webshop orderID te be shown in the bank statement of the webshop and customers of the webshop, report this as a feature request at the Rabo OmniKassa helpdesk.
[OMNIKASSA] After return from OmniKassa, pop up error about insecure items
The full error in Dutch: “Hoewel deze pagina is beveiligd zal de informatie die u hebt ingevuld over een niet-beveiligde verbinding worden verzonden en kan deze gemakkelijk worden gelezen door derden. Weet u zeker dat u wilt doorgaan met het versturen van deze informatie?”
The full error in English: “Although this page is encrypted, the information you have entered is to be sent over an encrypted connection that could easily be read by a third party. Are you sure you want to continue sending this information?”
This happens with sites that are not secured with a HTTPS communication (not required for Rabo OmniKassa) and only in some browsers, as far as we know: Firefox, Safari and some versions of IE.
This error will occur in some browsers and for sites without HTTPS communication. Rabobank advices to use HTTPS communication for the site. The Rabobank has confirmed that we can not fix thos from our side/in cciDEAL, the only solution is to either live with it or use HTTPS communication on the site.
[OMNIKASSA] At bank: “The server detected an error.”
This can happen when you are testing multiple payments and have OmniKassa cookies already (automatically) installed in your browser. Our tip is to use the browser Google Chrome in Incognito mode, as cookies will not be saved and you can test your Rabo OmniKassa installation without this issue.
[OMNIKASSA] Don’t always get e-mails after an order, but the status is updated
The Virtuemart mails depend on if the customer comes back from Rabo OmniKassa. If they come back to the site, those mails can be sent. If they do not come back, the status will be changed, but no mails are sent by Virtuemart. This is a limitation by the combination of Virtuemart and OmniKassa. To send the mails, Virtuemart requires that the payment is redirected to a URL with special characters like “&” etc. Rabo OmniKassa does not support these characters in the Automatic return URL (the one used to communicate the payment status when the user does not go back to site after payment). Therefor we created a special automatic return URL outside of Virtuemart to update the status, but due to technical limitations that can not send the Virtuemart emails.