Using a confirmation-page for an external payment

[Guest]

Hi,
I'm working on a payment module. Right now, I'm searching a function to complete an order from an external server. This payment service is running on another server (putting all security relevant questions to this server) which supports a confirmation url from the shop. This way, the shop-server is directly informed about a successful payment and completes the order. In other modules, this is not done until the customer returns to the shop - and for "stupid" customers, this could mean having payed, but not having completed the order because this is done on returning to the shop. We have had this problem with PayPal: everybody thought, the order was completed when they saw the text on PayPal's site, but a minority did not use the "Back to shop"-link. So they had payed for the goods, but the shop server didn't know about this.
Back to topic: Is there an easy way to do this in PrestaShop?
Greetings from Darmstadt, Germany,
Nico

[ejectcore]

This module should help you ;-)
http://www.prestashop.com/forums/viewthread/3268/

[Guest]

As this is yours, you can surely help me along. Thank you for the link, but I don't know if its already the one I need. As I read it, the payment server redirects to the URL given in return_url when the payment is complete. But I need a solution where the shop server gets informed about the payment set but does not redirect the customers to the shop. Think about it as followed: The payment server completes your order by calling the return_url in background, then everything that needs to be done to complete an order is done (sending a mail to the customer, saving in the shop that this order has been payed). The customer may click onto a "next"-link on the payment-website, but does not need to.

[ejectcore]

As far as i am aware there has to be call back link with any payment merchant unless of course it is an API then the customers nether leaves the site. usually most merchants give the option of an auto call back in their control panel.

From what I gather you don't want to return the customer back to the site.
I can't see the logic behind this at all. What if they want to continue shopping maybe make a comment about there order.
without going back to the web site this would put most people off buying from your store :roll:

[Guest]

The problem is not that I don't want the customers to come back. But what if? Imagine they do all the payment stuff at paypal or elsewhere, and then they do NOT come back to my store. The payment is done, but the shop does not know about this, so the customer pays for something the store can not ship for him. Thats the problem, and thats why the service I use for payment via creditcard uses a url that notifies the store about the payment even before the customer returns.

[szymek242]

Hi,
I have also created a payment module for prestashop. It follows the paypal module design.
In prestashop generally the default place for the customer to return after external payment processing is order-confirmation.php file. It is not intended to payment confirmation that would be recorded in the prestashop database. It is merely there to display some confirmation for the customer that the order has been processed. Actual payment validation takes place in modules/paypal/validation.php. This is the address called by the payment processor aside from the customer actions flow. Take a look at this file, you shouldn't have many problems adopting it to work with your payment service. The actual method that you were looking for is $Paypal->validateOrder(...) inherired from PaymentModule class. Hope this was helpful.
Regards,
Jacek

[Jiropole]

Hi,

I'm just curious why more integrated payment systems have not been implemented for Prestashop. From my point of view, the best customer confidence is achieved when everything is handled from within the store interface. Even the built-in paypal module only implements the first level of integration, in which you leave the store to complete your payment on the paypal site.

This is not a good solution for my clients, so we have developed a fully integrated authorize.net module, yet I'm still curious why there is not more support of integrated payment -- perhaps the APIs for European gateways are largely unable to support this?

Thanks,
Jiro

[Guest]

I see the following problem: In my case, I added support for Visa and AmEx-payments. They need some security stuff as you may not keep the creditcards numbers on an insecure system. And to handle the connection, you need some more knowledge than a usual shop carrier can afford. To get a solution for these both systems is really easy: My module shows an iframe that is provided by an external company. This company is specialized onto payment services and collects the money for the shop carrier. How would you solve cc-payments?

[Jiropole]

An iframe is a good solution for ensuring that the actual sensitive details of the transaction are not stored at any point on the store. NOT storing this stuff in the store is always the best solution. The solutions I'm talking about offer the same benefit as the iframe solution, except they do it through a semantic, server-server connection, allowing you to provide your own UI on top, skinned and fully integrated with your store. I'm not familiar with a wide variety of such APIs but I know they exist. We have implemented this for authorize.net, and it would also be possible to offer the same level of integration with the Paypal gateway, even though the default prestashop implementation for Paypal has not taken advantage of this.

[Guest]

But how do you assure that the sensible data of the credit card never reaches the shop server? I don't have any sources to cite directly from, but as I remember, this is only allowed with special SSL-certificates.

Appendix: Wikipedia knows about PCI

[Jiropole]

The credit card data should only be accepted by the shop on an SSL connection, any system that transmits CC info in plaintext is wrong from the start. In the case I'm talking about, the shop accepts the CC info form POSTed over SSL, and may store those values in a transient form like hidden form variables. The shop should not store these variables in a database unless they are guaranteed to be safely encrypted and quickly deleted. These values are then POSTed, again via SSL, to the gateway server, according to that gateway's simple API. The response is returned over the same SSL connection, ensuring that the sensitive data is never transmitted in plaintext and never stored on the server. Hopefully I'm tracking with you and not explaining things you already know! --Jiro

[Guest]

Sounds good - but, as you already said, having it not on the shop server is even better. But we don't need to argue to much - for the payment service I'm writing the module for, it is needless because they don't have an API for cc-payments. Thank you for being that detailed anyway!