Remove conjecture

[longwave]

The document is almost all factual, except for "Drupal Commerce is clearly going to win out in the long run" which is purely opinion. At the time of writing, Ubercart still has more users than Commerce, and moving into Drupal 8 I believe there is still place for both players in the Drupal e-commerce space.

Similarly I am not sure of the relevance of "Authors Note: payment processors like Authorize.Net have the ability to use third-party iframes to integrate with their CIM service. However, the Ubercart community is unlikely to add that feature into its code base" - just because it is unlikely to be added to Ubercart core, does not mean a contributed module will not provide this - I believe https://www.drupal.org/project/uc_authnet is moving towards achieving this.

[greggles]

Thanks for the feedback, Longwave!

"Drupal Commerce is clearly going to win out in the long run"

Ubercart does have more users by about 10% when you include the Drupal 5 and 6 installations, but I'm not sure how relevant those old installations are when talking about the current state of the projects. If we compare only 7.x installations then Commerce is used on about 30% more sites.

The goal of that section is to help provide guidance on which solution to choose and the paper should definitely remain factual there. Here's a new attempt at the paragraph that avoids the use of the word "win" (win by what measure?) and "clearly" (since its hardly a foregone conclusion) and tries to focus on the facts.

"There are considerations with respect to which shopping cart method one will use (or is using) on top of Drupal. Drupal Commerce is much more popular for Drupal 7 and popularity brings more people to fix bugs and contribut emodules. However, there is still a significant user base using Ubercart and Ubercart has far fewer shared-management options. The additional costs of becoming compliant with Ubercart should be a consideration when evaluating the two solutions."

The CIM service section

Does uc_authnet provide those kinds of CIM features now? The project page makes me think it does, but your comment sounds like they don't. How would you restate that section? If there's a better place to link to in the citation section with more up to date information that seems great to add.

[rickmanelius]

Hi @longwave thank you very much for taking the time to get back to us on this. My day is pretty booked today, but I do want to take the time to respond to each of your points and provide some suggestions on how we can adapt the language. I hope to respond by the end of tonight.

[longwave]

Regarding uc_authnet, I don't know whether it supports CIM or not; I don't use Authorize.Net and haven't looked into it.

[rickmanelius]

Hi @longwave. Again, thank you for your feedback.

Regarding the statement "Drupal Commerce is clearly going to win out in the long run", I can definitely see how that was a bit much in terms of an editorialization. However, there were several indicators (quantitative and anecdotal) that indicate that there is more time, attention, and energy being spent here. One major driving factors was the percentage of Ubercart developers that turned their focus to Commerce in a similar way that Ubercart devs transitioned from the ecommerce project. Honestly, I was initially surprised when Ubercart made the jump to D7 and I was absolutely stunned when I saw the D8 port happen. Clearly, Ubercart will still be around and be an option for those wanting a more turnkey solution.

That all said, as Greg stated above, from a PCI compliance and security perspective, I feel an obligation to provide a recommendation to steer people to a solution that addresses those two areas more thoroughly. And I think the language he suggested would change the tone of the recommendation to be more fact driven than opinion.

With respect to Authorize.net Hosted CIM, it's extremely relevant from a PCI scoping issue. As stated in the new version of the paper, the 3.0 standard has made it nearly impossible for small to medium sized businesses to select a merchant managed solution and achieve compliance. Even shared management solutions like direct post and hosted payment pages will still be difficult. For whatever reason, iframes appear to be given a pass into SAQ A, which is exactly what Authorize.net Hosted CIM (http://www.authorize.net/solutions/merchantsolutions/merchantservices/cim/) could provide. This would be a huge win for the Ubercart community because it would allow them to have at least one known iframe solution.

Here's why it matters. The 1800 reported sites using the UC recurring contrib module must be using some form of card on file (which is what authorize.net CIM provides) in order to achieve this type of functionality. Out of the box, CIM is merchant managed (i.e. the credit card data is sent back to the Drupal site before sent to the payment processor).

It's important to note these types of subtleties and it's why I posted a request for the Hosted CIM solution in the first place. The contrib module (uc_authnet) doesn't have an active request for this, although I'd be happy to add it in. And you're right that a contrib could provide this, but anyone looking for a solution right now would have to build it first. Additionally, IMHO Ubercart needs more shared management solutions. And the ones that are available (such as https://www.drupal.org/project/uc_stripe), are still storing the card temporarily instead of using Stripe's tokenization!

Summarizing. It looks like if we alter the "clearly going to win" passage and potentially add some clarification as to the reference of authorize.net CIM, that we'd address the major issues raised by the Ubercart community. If that's the case, let me get those edits in place and then if there is still any remaining issue, we can go from there.

Thanks!

-Rick

[longwave]

Those two sections are indeed the only major issues I have with the document in its present state.

I suggest opening an issue in the uc_authnet queue. I would also be open to adding the iframe feature to Ubercart core, but this is dependent on someone providing code and/or funding to do so - I originally closed the issue in question because I felt this was unlikely to be forthcoming.

[rickmanelius]

Hi @longwave,
Excellent. Then those are the two items we'll focus on updating. With respect to the part about Ubercart versus Drupal Commerce trends, we'll take what @greggles suggested above and make any additional modifications to focus more on data/facts and tone down the interpretation with the caveat that there will still be a recommendation from the PCI-DSS compliance perspective.

Regarding the Hosted Authorize.Net CIM discussion, the point of that section is merely to highlight that there is nothing precluding Ubercart from getting more shared management solutions, but it's up to the community to create them... with Hosted Authorize.net CIM being a great place to start. However, from a pure data standpoint, we will still note that there are more shared management options in the Drupal Commerce space at this time.

Realistically, we'll get these adjustments in by early next week. We'll then followup for feedback on the changes.

Thanks again for your time and for helping us make this paper more accurate and therefore more valuable to the Drupal community.

[rickmanelius]

Proposed change 1.

This is a modified copy of Greg's initial draft:

"There are considerations with respect to which shopping cart method to use (or continue to use) on top of Drupal. Drupal Commerce is much more popular for Drupal 7 and popularity brings more people to fix bugs and contribute modules. However, there is still a significant user base using Ubercart, and while Ubercart has far fewer shared-management payment gateway modules that are publically available, there is nothing preculding the community from creating them in order to address the newer and more stringent PCI-DSS requirements. The additional costs of becoming compliant with Ubercart should be a consideration when evaluating the two solutions."

Proposed change 2:

This broadens the focus beyond Authorize.net and it focuses on the fact that it can be added to Ubercart, but it hasn't been added to a timeline.

"Authors Note: payment processors like Authorize.Net have the ability to use third-party iframes to integrate with their CIM service and adding this new functionality into the existing Ubercart modules (core or contrib) would make it significantly easier for merchants to achieve compliance. However, requests to add this functionality for Authorize.Net and other payment gateways have been made with no indication that they will be added to a development roadmap¹⁴."

[greggles]

👍

[rickmanelius]

I've pushed the changes that were recommended in #26 (comment).

@longwave Please review those two changes. The paragraphs remove opinions and focus on facts. We can't ignore the fact that achieving compliance with merchant managed solutions are significantly more difficult, hence we still needed to note that for the readership at large.

[rickmanelius]

@longwave I know it's the weekend, but I'm just sending this to land in your inbox. If you could review the proposed changes by the end of the week, it'll give me enough time to address any additional back and forth discussion before publishing the next version of the paper (target July 15th).

And of course, thanks again for your time and attention.

[rickmanelius]

Hi @longwave. I apologize for pestering you (particularly since I know you recently became a father!), but I just wanted to followup and get feedback on the 2 suggested changes so we can close this out for good. And if you'd like to discuss on IRC, I'll be online.

[rickmanelius]

Hey Everyone. I'm happy with the change as is. Since the goal is to get this out the door next week (which will take some formatting time), I'd like to resolve this today... either leaving it as is, or addressing any feedback that might require some additional tweaking.

[longwave]

I am mostly happy with these changes, except for "The additional costs of becoming compliant with Ubercart" - this implies it is a fact there are additional costs, when I don't believe that's definitively the case - it depends on the payment gateway that is chosen, surely?

[longwave]

"The potential additional costs" or "The possibility of additional costs" feel like they describe the situation more fairly.

[rickmanelius]

@longwave That sounds like a reasonable change. I'll get that committed and close this out. Thanks again!

[rickmanelius]

This was fixed here 07f1f6f. Thanks everyone! Closing this one out...