5

To give a context for my question, we are actually migrating to Magento from Interspire Shopping Cart. In Interspire, the payment form would be displayed after everything else, especially the Order Review/Summary. At this last step of the checkout, we just display an iframe, which displays a payment form hosted on our payment gateway's server (since we're not PCI compliant). In Magento, however, the last part isn't the payment form, but the Order Review.

So my question is, would it be possible at all to create a payment method that uses an iframe (instead of redirecting to a payment page after "Place Order" is clicked)? This iframe would display the payment form hosted on our payment gateway's server.

I ask this because based on what I've read, and after playing with my code, it seems that it is not possible in Magento. Displaying this iframe, for example, on Step 4 (Payment Information) would mean that when the form is filled out and submitted by the user, the page would redirect to a success page, thereby bypassing Step 5 (Order Review). And even this won't work because it is actually in Step 5 (after Place Order is clicked) where the success page is even defined. So after submitting the payment form (in an iframe) in Step 4, it wouldn't know what to do next.

I also tried to research how to put this iframe in Step 5 instead of Step 4, having it appear after "Place Order" is clicked, but couldn't find anything.

So, is it possible to create an iframe-based payment method in Magento? If so could you point me to some resources, because I've googled a lot and haven't found anything useful.

Improve this question
7
  • You can add the iframe to the review page. Did you check for a magento extension for Interspire?
    – Fabian Blechschmidt
    Commented Aug 29, 2013 at 16:41
  • Don't know where you or your client is based but in addition to the others already mentioned there's Sagepay server-server method which is included in the free ebizmarts Sagepay Suite and runs through an iframe.
    – McNab
    Commented Aug 29, 2013 at 21:54
  • @FabianBlechschmidt okay will try to research more on how to put the iframe in the Review page.
    – Obay
    Commented Aug 30, 2013 at 2:51
  • @McNab okay will look at Sagepay. Thank you!
    – Obay
    Commented Aug 30, 2013 at 2:51
  • @Obay, if that's useful I'll add it as a proper answer then, help the site Q/A ratio statistics.
    – McNab
    Commented Aug 30, 2013 at 8:20

4 Answers 4

Reset to default
4

Good news:

This is actually already available. It's called Magento Payment Bridge which integrates an iFrame into the payment process so that the payment doesn't take place on your own server.

Here is some more information about Payment Bridge:

http://www.magentocommerce.com/company/pci-compliance

http://www.magentocommerce.com/images/uploads/Magento_Secure_Payment_Bridge.pdf

Bad news:

It's not available standalone. It used to be available via Magento Professional, which was a smaller version of Magento Enterprise (limited features, less cost, no online support). Now it seems it is exclusively an Enterprise feature.

If you're not in the market for EE, you're probably left to roll your own. Some payment providers do this already:

  • Paypal Payments Advanced
  • Authorize Server Integrated Payments (hosted payments)

Other options

Look into some of the newer companies that are doing payments like Stripe. Stripe has an amazing payments API that is dead-simple and will not require iframing. They even have a javascript include API.

Other competitors of Stripe include Authorize.net (who have a Javacript API now) and Braintree.

Improve this answer
2
  • We're actually using EE, but I think we can't use (or can we?) the Payment Bridge because we are not (and will not be) PCI-compliant.
    – Obay
    Commented Aug 30, 2013 at 1:50
  • Unfortunately we're stuck with our current provider. Our provider has a javascript include API, but we don't know which part of the code to stick it in. We are able to put it in Step 4 of checkout (Payment Information), but that wouldn't be right since it's before the Step 5 (Order Review), would it?
    – Obay
    Commented Aug 30, 2013 at 1:50
3

Magento CE 1.7 has this out of the box. It's the payment method labeled "Authorize.net Direct Post" in the admin, and is an alternate form of integrating with Authorize.net which I believe was introduced in 1.7.

Essentially, the way it works is as you describe, and the payment information is posted directly to the gateway server, in this case the Authorize.net gateway. Authorize.net provides a little diagram showing how this integration method works…

Direct Post Method - How It Works

The AIM integration with Authorize.net, and the one you are likely looking at, actually still does not store the card information on your server, even though it is accepted prior to the review step. Given a stock installation, i.e. it is unmodified, the card info is submitted to the server over HTTPS (I'm assuming an SSL has been configured) in order to be validated, but it is not stored there. When the customer clicks the final place order button, that same card info in the payment form is submitted all over again so that Magento has it to process the payment transaction. So essentially, it does get sent to the server (over an SSL secured connection, again, assuming it's been setup with SSL) but is not held or stored beyond the time it takes to authorize the transaction with the payment gateway. It can be confusing since it's not immediately obvious that it is done this way, and it didn't do it this way in older versions of Magento.

As @philwinkle points out, Magento EE has the Payment Bridge, but that still requires that you run on a fully compliant environment since the bridge is merely taking the responsibility of payments off of the application nodes and putting it on an isolated server, using code which has been PCI-DSS certified. It also enables certain additional payment methods such as authorize.net stored credit cards.

In addition to on-site payment methods, there are also options such as PayPal which can take the customer off-site to process the card via the Payments Standard payment method.

Improve this answer
4
  • This is awesome because pictures
    – philwinkle
    Commented Aug 29, 2013 at 19:02
  • @davidalger: Oh, even if we're not PCI compliant, as long as we don't store the credit card information (and just POST it directly to the payment gateway server), we're good? Because we were actually able to integrate our payment method without using iframe, by extending Mage_Payment_Model_Method_Cc.
    – Obay
    Commented Aug 30, 2013 at 10:56
  • Pci is much more complex than whether or not you store information. There are also rigorous definitions of methodologies to prevent unverified users and developers access to systems where cardholder data is processed whereby a system could be modified for the sake of compromising your customers' security.
    – philwinkle
    Commented Sep 9, 2013 at 12:33
  • Also what might be pointed out is that all online merchants are required to be PCI compliant. It's been stated that you are not, and this is why you are looking at using iframe methods. PCI compliance is a must. The difference is in what requirements are imposed in relation to where and how the data is transferred and stored. You won't find a card processor that doesn't have mandatory PCI compliance in their processor agreements.
    – davidalger
    Commented Sep 10, 2013 at 0:51
1

If you or your client is in a country which support it, SagePay offer an iframe based payment method – the server-server method. There is the free approved Sagepay Suite by ebizmarts which really is excellent, well supported and kept up to date.

http://www.magentocommerce.com/magento-connect/ebizmarts-sage-pay-suite-ce-sage-pay-approved.html

You can upgrade to the premium edition for £150. The benefits of that are additional payment methods, in addition to standard 'Authorise and Capture' you also have Defer and Authenticate And you can also refund directly out of the Magento backend.

Pros

  • Very secure (arguably more secure than the direct method) as of course it's essentially an off-site payment method taking place on your site. As such you don't technically need an SSL for this as there is no transport on the credentials, although good practice would dictate that you apply one anyway given users expect it and have been trained to look for it. Well some of them have anyway.

Cons

  • jQuery in the checkout. As we all know jQuery doesn't play too well with Prototype at the best of times, this module's js is all written using Prototype and really doesn't play well with jQuery in server-server mode. Ebizmarts recommend having no jQuery at all in the checkout, and I know from experience that in server-server mode if there is a conflict it will result in the payment form not being displayed (everything else seems fine). This happens whether the form is set in the config to appear under the order review or as a modal window.

    This is a problem as often you'd want to retain things like jQuery based masthead mini carts in the checkout.

  • Styling the form. The form itself is hosted on the Sagepay server and for obvious security reasons they don't allow you to serve up your own CSS by linking it to external files. When you are styling the form you need to use XLST and run it through Saxon/Kernow (http://kernowforsaxon.sourceforge.net/ ) to process/render it. So more time consuming to style.

    There are guidelines you need to follow, when you are happy with it you submit a whole zip file of css, images and templates back to Sagepay who review it and then apply it to your checkout. Pros here are that the documentation they provide is very good and they are very fast at reviewing and approving checkouts which have followed the guidelines.

Improve this answer
3
  • Is Sagepay a payment gateway on its own, and does it mean we need to register for an account at Sagepay, much like one does for Authorize.net, or our current payment gateway? Or can this Sagepay create an iframe implementation for any payment gateway, such as the one we're using?
    – Obay
    Commented Aug 30, 2013 at 9:24
  • 1
    It's a payment gateway and you'd need to register for an account - so looks like you are going to have to write your own. That is going to be a pretty big task I would say and considerably more costly than changing payment gateway to someone who supports an iframe method. You could always download the ebizmarts module I've linked to and look at how they have implemented it though.
    – McNab
    Commented Aug 30, 2013 at 9:33
  • Will definitely look at how the ebizmarts module is implemented. Thank you!
    – Obay
    Commented Aug 30, 2013 at 10:55
1

Time has passed and technology has advanced.

Braintree Payments have gone leaps and bounds in the last few months, both commercially and technologically. They now offer two solutions that offer out-of-the-box PCI compliance. Both are based on iframes.

The first one, their "v.zero drop-in", is the easiest to implement, looks very slick and has great UX, but is less customisable. The second one, "Hosted Fields" takes a little more programming effort, but allows more control in terms of CSS styling and layout.

Luckily, for seamless integration into Magento without you having to do any coding, there are now extensions on Magento Connect to make implementation effortless, see for instance http://www.magentocommerce.com/magento-connect/developer/f+r+i+s

Here's a comparison to help you choose the best one for your store: https://fris.technology/blog/braintree-drop-in-or-hosted-fields

These extensions work in Mage core's multi-step checkout as as well as in combination with almost any one-page/one-step checkout extension on the Magento Marketplace.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.