Adding unsupported payment methods

Me again

How difficult would it be to add extra payment methods for other online credit card payment facilities? I'm in the UK, and there are some commonly used ones here which are not in Isotope.

Tom

Hi Tom-

We're really only adding them on a pay-for-project basis at this point. It's not terribly difficult for anyone with basic programming skills. I would suggest either contacting Fred or Andreas or any of the other devs here and get a quote from them on the implementation.

I would also hope that any payment modules that get developed get contributed back to the community in the repository...

No no - I definitely meant doing the work myself, so I'm glad to hear it should not be too difficult. Not interested in contracting the work out. For Isotope to grow, I imagine this is a major area which requires extensibility, especially in international markets.

I shall have a look at the templates, and see if I can start from there to work out how it all works. If I get somewhere, I'll look into how to put an extension together, or hand the work over to the Isotope team.

Thanks

Tom

In addition to the question above: how about payment method ideal?

I have not yet chosen what CMS to use.
Contao combined with Isotope seems to tick all boxes, except... payment by customers.

Documentation on iDEAL can be found here. http://www.rabobank.nl/images/handleidi ... ionbar=yes
Unfortunately documentation is in Dutch; I have tried to putting it through google translate but it's too big. If you scan the text for technical terms it should not be too difficult to understand the basis concept of this payment method.

In addition to this, there's a service provider MOLLIE that offers an out-of-the-box API for using this payment service:

Here's a technical description how the payment process works.
Original text in dutch: http://www.mollie.nl/support/documentat ... ten/ideal/
Google translation: http://translate.google.com/translate?j ... ten/ideal/

And here's the API in PHP for download:
http://www.mollie.nl/betaaldiensten/ideal/modules/

Now, my problem is: how to determine the amount of work to integrate iDEAL with Isotope, for payment processing. Although I work in ICT myself, I'm not a programmer. Of course I understand this is a custom development, but the question is: how much effort is this going to be for someone who knows basic PHP? Days? Weeks?

And how complex is this going to be? I have access to someone who has reasonable PHP skills, but he's not a pro.

Menno,

nice info on iDeal.

Some info for non-Dutch readers; iDeal is the online payment system in the Netherlands. Almost every Dutch webshop uses iDeal, most of them directly via the shop some others via a service provider like Mollie or Ogone.
These external providers provide plug-ins for eCommerce systems that talk to their services so from an iSotope point of view that's different from iDeal (I think this is something like PostFinance from Swiss Post).

I've only been looking at Contao for a long week and at Isotope for a bit shorter of a week but this week brought me much more than the months I spent struggling with OS-Commerce, Magento, Drupal, Typo3, WordPress and more... Although all these systems get you up&running fairly quick, it's not always as easy to expand the system.
Implementing a new payment module does not look that difficult - we just need a good starting point.
I'd be willing to do some implementation work for this - I also need this for a friend's shop although I am not to sure about the version of iDeal to use (Lite, Basic, Professional) or if there are still protocol differences in these. I know there are different contract versions with banking companies with different payment schemes (per transaction payment and optional monthly payment) - depending of the number of transactions one or the other method is cheaper for the shop owner.

Where do we need to start?

iDeal uses 3 different protocols:

• Directory Protocol
  The shop performs a directory request to the bank to request the list with accepted banking card.
  Rabobank suggests that once a week should be OK since this is more or less a static list.[/*:m:nrdqqwrt]
• Payment Protocol
  A two level protocol: First the shop asks his bank for a transaction ID for the customer's banking card. After this he redirects the customer to his/her bank and the customer will, after payment, be directed back to the shop with a transactionID.[/*:m:nrdqqwrt]
• Inquiry protocol
  Now the shop perform an inquiry with his/her bank to check acceptance of the payment, after which the shop completes the order transaction with the customer.[/*:m:nrdqqwrt]

All there are plain HTTP(S) POST and GET requests with an XML record

AFAIK this differs from online credit card payment where you enter all information on the shop's website after which the shop performs the payment/inquiry protocol with the banking company.
So which of the available modules has a similar Payment/Inquiry protocol? that would be a good starting point.

Rob

I did some research in Isotope and on iDeal payments.
I've settled for TargetPay, they are not too expensive, do not have a monthly charge (which is good for a shop that does not handle that much transactions) and they provide ample documentation and sample PHP code on their protocols.

I used PayPal as an example to figure out how the process works (I'm not a kid anymore but still like to play in the sandbox ;) )

• Customer places an order, selects PayPal and clicks on the "Pay now" button.
  function checkoutForm() in the PaymentPaypal module is being called, this module creates an HTML form with the data for the PayPal transaction. Customer is now redirected to PayPal using this form data.[/*:m:kyv8fj7w]
• After payment is complete, customer is looking at the "payment has been done" screen at PayPal.
  Now PayPal sends a confirmation by sending a POST to to system/modules/isotope/postsale.php
  the processPostSale() function in the PaymentPaypal module is being called and this one sets (a.o.) the payed_date to confirm payment[/*:m:kyv8fj7w]
• In Paypal the customer clicks on the "Return to the shop" button, this redirects back to Isotope (index.php/checkout/step/complete.html).
  At this time the processPayment() function is called - i think just before the customer sees the order confirmation..
  [/*:m:kyv8fj7w]

I think I know what this processPayment() function is for: the shop waits here for the paypal payment to be confirmed by paypal (step 2). Due to internet it could be the case that the customer returns to the shop before PayPal sends us the confirmation that payment is OK. If paypal decides that payment is not OK, we do want to inform the customer about this.
Is that a correct assumption ?

I think I found a bug in the system:

• The order is not 'fixed' when the customer does not click on the "Return to the webshop" button in paypal or another banking system.
  The order is available in the tl_iso_order table.[/*:m:kyv8fj7w]
• The order number is re-used when this (or another) customer later on makes a new order.[/*:m:kyv8fj7w]
• But ... the date_payed field in tl_iso_orders does show payment date - even if this order has not been payed for online.[/*:m:kyv8fj7w]
• The paypal accounts of both the customer and the shop owner now show an order that has been payed for with an order number that is not valid anymore.[/*:m:kyv8fj7w]

Therefor orders numbers must be fixed as soon as it is handed over to an external party, an order number may only be handed out once, even if the order is canceled during on-line banking.

If the customer does not return to the shop, there should be a way to still complete the order (manually).
A number of on-line banking systems do not 'push' a payment notification to the webshop, iDeal (and PostFinance) need Isotope to send a HTTP GET to confirm payment with the bank. Normally this takes place in processPayment() when the customer returns to the shop, if the customer does not return - the payment status is lost. We should then be able to set the date_payed ourselves.
As long as orders that are payed for online may be removed when the customer does not return to the shop after payment the system is not fool-proof. I could place a warning on the page that redirects to the bank with a warning that one must return to the shop after payment (I know one shop doing this - looks very strange from a customer point of view).

Rob

Rob, I think you'd best create a ticket for the problem at the project website http://projects.winanscreative.com/projects/245. I have noticed something similar, but I solved it in the payment gateway by updating the order to the status 'pending' before letting the customer go through with the payment.

I've created an iDEAL extension that supports iDEAL basic/lite and iDEAL advanced/professional/zelfbouw. http://www.contao.org/extension-list/vi ... ideal.html. I'm pretty sure that is not directly compatible with targetPay but reading their documentation it seems similar to advanced. Perhaps I can add it as well, wouldn't be that hard.

Using iDEAL advanced it should be possible to retrieve they payment status at a later time if the customer didn't return to the store. I'll have to check that. Perhaps I should create a custom error page that offers a try again link if an error was received. But right now I'm not sure Isotope not already offers any of these options.