How to create/add a new payment provider extension

Hello all,

I would like to add a payment provider extension for just straightforward iDEAL payments (most common payment method in the Netherlands) without subscription/signup fee. There are numerous PSP's in the Netherlands that provide this. The Isotope currently supported PSP's that do provide iDEAL as method (epay, payone, saferpay) seem to have a higher cost structure, perhaps because of all the other payment methods provided.

In the very early versions of Isotope, Ruud provide an excellent iDEAL (lite) payment extension, but this particular interface is being discontinued by the banks, and is no longer supported in the recent incarnations of Isotope either. I was thinking that since most PSP's do provide php sample code and documentation, it is mostly a matter of connecting the right parts without really needing to code the payment logic itself. I would have thought that this 'case' of adding PSP X would occur more frequently, but to my surprise I found little on the forum regarding this. I suppose that with some 'sample' payment exension code, the mapping between the PSP sample code would be easier. Does anyone have an idea if such 'Isotope payment methode extension' sample code is available? Or should I peek into some of the existing payment extensions to see how they did it?

Thanks!

I suppose I gave the answer to my question already. This is an open source CMS, so ofcourse I should take a peek in the source. With the help of watching the standard payment method source files, and that of the isotope_transferujpl payment extension by Codefog, I was able to create my extension isotope_easyideal which was published today in the extension repository.

I justed wanted to post back here, so that it might be usefull for others that are considering adding a payment service provider of their liking. The place to look for inspiration is the system/modules/isotope/library/Isotope/Model/Payment folder. The cash.php is the most obvious, and the other files there that each implement a different payment method are mostly quite similar. Without much Contao/php experience (like me), the idea of how it works becomes clear by watching a couple of these payment method implementations.

With the checkoutForm method, the form with all the required data for the payment is prepared (using a template). The required data varies from one provider to the other, but the total amount, order number and a checksum hash over the data+secret is what you will in many cases have to provide. Also, a return url for returning to the shop after completion will be part of the data, and depending on your payment provider a separate postsale url (to notify the shop about the payment success or failure) may also be part of the data (and sometimes even a separate fail return url).

Isotope makes a distinction in the postsale url which is always {base_url}/system/modules/isotope/postsale.php?mod=pay&id=ID (ID being the Isotope record ID number of the payment method) and the return url, which depends on where your Isotope checkout module is configured in your Contao site. Some payment service providers will however not make such distinction and will assume a single return url where the shop is notified of the payment result as part of returning to the shop. In that case the postsale.php should be used, and from there the customer can be redirected to the checkout completion page.

The handling of the notification through postsale.php is handled in processPostSale method. Here you will process other post/get vars that are returned by the payment service provider (in addition to the ?mod=pay&id=ID that you made sure were also included so that Isotope can call your processPostSale method. Beware that a name conflict might occur here, because payment service provider might have gotten the idea to use &id= themselves to reference to the order or transaction number (as in my case). In that case, a little workaround with a hook is needed, and you can peek from the isotope_transferujpl payment extension or my isotope_easyideal extension how to do that. In any case, you will be verifying the payment data for non-tampering here before accepting the payment as valid and finalizing the checkout.

For the backend configuration of the payment method, a couple of extra input fields will be needed, like merchant id/key/code/secret/etc. These are ofcourse specified in the dca folder.

Well, that's it I suppose, in short.