Commerce Collect.js

From the original maintainer: My online business has closed and I no longer have the resources to test or develop this module. I will not be providing any further updates. Source code remains posted here for anyone who may want to take it over in the future or port it to Drupal 8. Use this code at your own risk.

This module provides for processing payments in Drupal Commerce version 1.x (for D7) by using a payment gateway tokenization function known as "Collect.js" with a Direct Post API, greatly enhancing security with minimal impact on the end-user experience. This API was developed by Network Merchants, LLC and is used by other processors because NMI repackages the API for various other ISOs. If your payment gateway uses Collect.js, this module will work for you. (Tip: If your gateway's Help/Integration section looks the same as this manual, then it is compatible with your gateway.)

Collect.js is a tokenization script. When the end-user clicks a button on the payment form, the payment processor generates and presents a payment form in a lightbox to the user, which only collects their CC number/expiration/security code. When submitted, Collect.js returns a payment token(a "nonce") to the payment form. This nonce is only valid for one-time use and expires in 24 hours if not used at all. Once the token is received, the payment is processed via the existing Direct Post API provided by the gateway. So what's the benefit? PCI-DSS standards consider a lightbox to be an entirely separate page, and since it is generated and served entirely by the gateway, this will result in SAQ-A compliance, with minimal impact on the user experience.

Installation

Install, enable, and activate the payment method just as you would any other. You will need to adjust the payment method settings in your store configuration. Since this module uses an external JS library, this must be available on page load. If your store presents shoppers with multiple payment methods as options, this module must be set as the default/first payment method available(selecting it after page load causes the JS to fail to load). This can be done by adjusting the "weight" value for the enabled payment methods.

In the settings page of your gateway, you will need to do the following:

1. Generate a new user, and grant access to the API functions.
2. Generate an API key for that user.
3. Generate a separate tokenization key for that same user.

It's important that these are two separate keys and both are provisioned to the same user. If not, the gateway will reject the transactions.

Copy and paste these these keys into the appropriate field. Also, set the URLs for the Direct Post API endpoint and the Collect.js external library. Save. The payment method will now be available on the checkout "payment" pane like others.

Important Limitations

• Since the tokenization and API keys must be provisioned to the same username, testing this module presents unique challenges. See readme.txt and the payment method settings page for further information.
• Since we never actually see or touch the any payment card data beyond the payment token, there is no data validation by Drupal before submission of the payment(other than to check that Collect.js returned a token of some kind). Merchants will need to review and verify their AVS and CVV rejection rules on their gateway's settings page.
• New!Can now select Sale or Auth txn types, but these are only available via the customer-facing checkout flow. Merchants can now perform Capture, Void, and Refund txns via the Admin interface. However, no support for adding new Sale or Auth txns from the Admin interface.
• No support for Recurring or Customer Vault operations. Since I do not use these
  operations I have little interest in adding this functionality myself - patches
  are welcome.

Alternatives

• The Commerce Three Step Redirect module provides an integration with the same gateway using the Three Step Redirect API. This is technically an offsite redirect payment method, so it has ah a similar set of limitations, but allows you to use your own payment form on your own site without a lightbox and gives you greater control over form styling. The sacrifice? This will reduce your PCI compliance standard to SAQ A-EP.
• The Commerce Authorize.net module can be used by overriding a couple of variables because the NMI gateway provides AIM emulation capabilities. This gives you the ability to access the full array of card transaction functionalities through Drupal Commerce administration interfaces, including Card On File integration. Despite this method currently being the "recommended" integration method by NMI for Drupal Commerce stores, bear in mind that AIM emulation is just a modification of the Direct Post API without tokenizing the sensitive cardholder data. Using that module means you are actively collecting and manipulating this data within Drupal, and results in PCI compliance standard SAQ-D.

Help Wanted

Ideas, tips, pointers, recommendations, patches, or offers of co-maintainership are welcome!