[
Continued from pevious post]
Realisation 4 - X-Payments Will Not Support My Gateway on Release
My gateway provider (
www.paydollar.com) is not on the X-Payments supported gateway list. I asked XCart if I could get them added but received a "maybe later" styled answer. (XCart built the custom mod in my current XCart to connect with PayDollar...).
So now my XCart 4.1.x options are:
- Change over to an X-Payments supported gateway (but I feel that you really need to be with AsiaPay if you're serious about HK/China - a topic for a different thread); OR
- Accept a Payment Gateway provider that diverts customers to it's own Payment Form.
Realisation 5 - Upgrading to XCart 4.3 Is a Big Deal
There are posts all through the forums on how hard it is to move to XCart 4.2/3 from 4.1.x. I won't repeat all of that here but the key takeaways for me were:
- At the very least, all of my Smarty templates need to be changed due to the eradication of tables for positioning
- My many, many custom mods will need a lot of refactoring/reintegration
- Many feel that the 4.2 and (to a lesser extent) 4.3 releases are still buggy
- There may, or may not, be another 4.4 release that I would need to upgrade to in order to avoid any outstanding issues with 4.3. Or am I exagerating here - has 4.3 been declared a Stable release by XCart and does the forum agree?
Given these risks, the competing demands on business resources, and just-around-the-corner-super-version-5.0 release, it is hard to justify an effort to upgrade to version 4.2/3/4 (/5/6/7?).
Realisation 6 - Other Carts Are Already Compliant
I didn't know this until I read the post referenced above. So there is Choice and we have 6 months to get it working.
But for many of us, this would be very painful given the degree to which we have integrated XCart into our business processes and technology stack.
Realisation 7 - Phone Orders etc - Am I screwed anyway?
7.1 Phone Orders
This is probably not an X-Payments issue so much as an issue of how to interpret the Compliance rules.
What if I want to take an order by Phone/Mail/Fax/Email? I'm thinking that with all of these, the moment I have a record of the customer's details in my posession (on paper or email) then I'm screwed, right?
In terms of processing the Payment I actually have a choice. I can either:
- Use my gateway provider's already Compliant web site to enter the Credit Card details and process payment (XCart & X-Payments are not in the loop); or
- Place the order in XCart on behalf of my customer (XCart & X-Payment are in the loop).
But is the method of processing above even the issue? Or is it the fact that I have that paper/email record that defines my Compliance requirements?
7.2 Subscriptions & "Remembered" Credit Card Details
My customers have been complaining that they don't want to enter their credit card details every time they buy from me. I explain the security advantages of me not storing their credit card details and they simply respond that they are confident the bank will sort them out if they are subject to credit card fraud.
Now, whether that's correct or not, they want maximum convenience at checkout.
But this means storing credit card details
somewhere. So how do I simultaneously:
- Avoid forcing them to login to a 3rd party gateway (that stores their credit card details instead of me) at checkout; and
- Store their credit card details for convenience at checkout; and
- The clincher, avoid a Compliance Audit and all the hassle that goes with it?
Any ideas gang?
I guess the related question is, does/can X-Payments store credit card details in a compliant manner? Or (as I suspect) is X-Payments a pure gateway with no persistence?
Realisation 8 - A Possible Solution?
In the above referenced post, Vyacheslav Petrov from XCart gave me hope when he wrote:
Quote:
|
Note: there are payment gateways that allow you to host the payment form on your web server in such a way that the cardholder data is directly submitted from the form to the gateway. Since the data never touches your server, the server may be moved out of the assessment scope (please consult with your acquirer to clarify whether it is true for your payment gateway).
|
Does this mean I can:
- Change to a Payment Gateway with a service as above; and
- Embed the Form into my own Checkout Page (as <div>gateway form here</div> rather than as a whole different look-and-feel page); and
- Side-step the X-Payments etc requirement altogether?
Yes, I'd rather not change gateways, but it's worth a look right?
So, which gateways offer this? Anyone got experience in this? Or is there a forum rule that stops us discussing gateway providers' offerings?
F) Open Questions
So all of the above leaves me with the following open questions that I hope XCart plus this fantastic user base can help me with.
I suspect/hope that the answers to these questions will help many in the forum!
F.1) Questions for the XCart Team- What is the actual hard delivery date schedule for v5.0?
- Will 4.4 be released or not? If so, what is it's hard delivery date?
- Will version 4.2 definitely work with X-Payments after modification?
- Will version 4.1.x definitely work with X-Payments after modification?
- Can we get additional Payment Gateways added to X-Payments prior to July? Does the answer change if we're willing to pay?
- Does/can X-Payments store credit card details in a compliant manner? Or (as I suspect) is X-Payments a pure gateway with no persistence?
F.2) Questions for XCart & the Forum- Has version 4.3 been declared a Stable release by XCart? If so, does the forum/user base agree that it is Stable?
- If using X-Payments, do we really need to install X-Payments on a separate/2nd server to be Compliant?
- Which gateways allow hosting of the payment form on your own web server in such a way that the cardholder data is directly submitted from the form to the gateway? And can this form be embedded within your existing checkout page?
- With the processing of Payments for orders received by Phone/Fax/Email/Post, is the method of processing relevant? Or is it the fact that I have that paper/email record that defines my Compliance requirements? If so, what are my obligations?
- For customers who wish to avoid entering therir credit card details on every transaction: I doubt it but I'll ask: Is it possible to simultaneously:
- Avoid login to a 3rd party gateway (that stores the customer's credit card details instead of me) at checkout; and
- Store the customer's credit card details for convenience at checkout; and
- The clincher, avoid a Compliance Audit and all the hassle that goes with it?
----
OK - thx to all who have read this tome. Greatly looking forward to the responses.
thx,
js