Quote:
|
Originally Posted by geckoday
This has generated a few thoughts and requests on the X-Payments implementation.:
1. It was mentioned that X-Payments would serve up its own payment page which would mess up a good one page checkout.
|
Just a side note: there is no a trustworthy study confirming that putting all the fields on one page increases conversion. One-page checkout looks cool, but it doesn't guarantee that you will get more sales.
Quote:
|
Originally Posted by geckoday
This isn't required to properly separate out the payment module from the core. Take a look at the Transparent Redirect method Braintree talks about for their gateway (rebranded Network Merchants, Inc. gateway). X-Payments could work the same way. The payment form on the one page checkout can post to the X-Payments module which then redirects back to the core X-Cart receipt page. Simple and makes the breaking out of X-Payments transparent. I do this today with the Network Merchants gateway to completely remove my web server from PCI scope. |
Are you sure that you remove your server from PCI scope? Yes, a browser submitting the data to your gateway is out of the scope. But behavior of the payment form is determined by X-Cart, not the browser. X-Cart is the party that decides where the credit card data will be send. And I guess it will be considered as a payment application that must be verified against PCI DSS requirements: just a small change in a template file of X-Cart will result in sending all credit cards though a hacker's proxy server.