thinkshout/commerce_iats

iATS Payments Drupal Commerce integration.

ThinkShout.com

The ThinkShout.com website, built with Jekyll, Foundation 5, SASS, and lots of love.

Installation & Building

See the Wiki

Branches

1. Dev: New feature development.
2. Stage: New content. Features from Dev merged into stage. Pushed to stage.
3. Live: Mapped to production. No commits, only merges from stage.

Development workflow

Something along the lines of the following should be used by developers working on this site.

1. Clone the repository if you don't have it.
2. Checkout the dev branch, git checkout dev.
3. Make sure you're current, git pull origin dev.
4. Optionally grab the latest content by rebasing stage from the dev branch, git rebase stage.'
5. Create a feature branch off of dev, git checkout -b myfeature.
6. Make magic happen
7. Merge your feature into dev, git checkout dev && git merge myfeature. Clean up and delete your feature branch.
8. Run rake serve and make sure all is well.
9. Push your exciting new feature, git push origin dev.
10. If it's ready for staging, merge into stage, git checkout stage && git merge dev && git push origin stage.
11. Optionally deploy to staging, rake stage.
12. To launch the new feature, git checkout live && git merge stage.

Content editing

Blog posts should be managed via prose.io. Visit the website and, when prompted, authorize via GitHub. Select the thinkshout/thinkshout project. Prose will only make the blog post folder accessible. You can create new posts by clicking the large green "new file" button at the top of the page (see below "New Posts section"). Existing posts can be edited by clicking on the file in the list. When editing or creating a post, the metadata button on the right side will load with the available variables that can be filled in, including teaser, author name, and tags.

New Posts

It is important that the file name of the post uses the following format: blog/_posts/[date]*.md

Where "*" is the title of your post (with no spaces - use dashes instead).

For example the default blog/_posts/2014-03-14-your-filename.md file name could be changed to blog/_posts/2014-03-14-my-new-blog-post.md.

This is necessary because Jekyll uses this field value to generate the Markdown file that will be complied into your blog post, which must be in the blog/_posts directory and be named with a leading date.

To specify a post title

Head to the metadata tab using the button on the right and specify your title in the "Raw Metadata" field as follows:

title: "My New Blog Post"

If you do not specify a title, Jekyll will generate one for you based on the name of your file by replacing dashes with spaces and capitalizing the first letter of each word.

Other metadata options (and what they do)

• Short teaser - text that will display below the linked title in post teaser (used, for example, on the /blog page)
• Author short name - makes your picture, name, and job title show up in the post teaser.
• Featured - check to get a post to show on the home page.
• Tags - ??? can't figure out how to add existing tags to new posts that don't have any - old posts have select list options, but that's because there are tags already defined in their front matter ////Alex
• Raw Metadata - any other YAML front matter you'd like to include (case sensitive).

Home Page Posts

To get a post to show on the home page, add featured: true to the post's YAML front matter. This will also add a class of featured-post across the site for styling convenience.

Preview your post

Click on the preview (eye) button on the right hand side. If you don't see images, etc. that you're referencing in your Markdown it's because they're not pushed to the repo (stage branch).

Testing, CI, and Deployment

The site is hosted on Netlify. Netlify will build previews of all commits in any branch. Preview environments are available in the Pull Request status checks. Commits to stage are published to https://stage.thinkshout.com and commits to live are published to https://thinkshout.com.

Sites you might be interested in looking at:

• local: http://localhost:4000/
• stage: https://stage.thinkshout.com/
• live: https://thinkshout.com/

Wonderlab sub-site

The /wonderlab sub-site is generated using the following components:

• A wonderlab.html landing page that lists wonderlab blogs
• A wonderlab collection defined in config.yml
• Blog posts nested under _wonderlab/*
• Metadata for categories in _data/wonderlab.yml

Most of the post fields are standard for Jekyll, with the exception of the "index" field, which is used for manually ordering posts within a Wonderlab category.

The code is set up to work for multiple categories, so hypothetically if you wanted to launch a new topic, you would just add a new entry to _data/wonderlab.yml (at the top of the array).

commerce_iats's Issues

iATS Webinar Checklist

Introduction:

• Introduction to Drupal Commerce and Commerce iATS
• Payment method configuration, agent code / password

Demo:

• Demo credit card payment
• Demo ACH payment
• Demo credit card card on file payment (create then process another transaction using the stored card)
• Demo ACH with multiple currencies to show bank account form fields
• Demo recurring credit card transaction
• Explain Drupal cron for scheduled tasks and the integration with the ReportLink service
• Demo Direct Post credit card transaction
• Demo USB card reader transaction
• Demo Direct Debit (UK only)

Code:

• Explain structure of Commerce iATS module, payment methods, etc
• Explain single point of contact with the iATS API and response handling

Update README

• Payment Methods documentation
• Test information (isn't this in the wrapper doc?)

Indicate 10 character limitation on invoice field

Add to the field description and change the default invoice prefix to something shorter.

TLS Version

Recurring payment enhancements

• Allow admin users to modify the schedule of recurring payments
• Allow admin users to cancel recurring payments
• Allow users to create recurring payments using stored card or new card

4 hour limit.

commerce_iats_cardonfile_process_queued_transaction() should use EntityFieldQuery

Current using a db select and having to append to a db_prefix. Maybe there's a reason for this? Would look something like:

  $query = new EntityFieldQuery();
  $result = $query
    ->entityCondition('entity_type', 'commerce_payment_transaction')
    ->propertyCondition('remote_id', $remote_id)
    ->execute();

Extraneous elseif

Not clear what purpose the elseif serves below from commerce_iats_direct_post_relay():

  if (isset($_POST['IATS_Comment'])) {
    $comment = $_POST['IATS_Comment'];
  }
  elseif (isset($_POST['IATS_comment'])) {
    $comment = $_POST['IATS_comment'];
  }

Form action fails to update when changing payment methods

If you have a payment method with direct post and one without, the form action remains the direct post URL when changing methods.

Message on stored card removal is too scary

http://cgit.drupalcode.org/commerce_iats/tree/modules/commerce_iats_cardonfile/includes/commerce_iats_cardonfile.credit_card.inc#n348

Change error to a message so it's less scary.

Implement USB card reader functionality

• Create USB reader submodule
• Add optional USB reader support to payment method settings
• Implement USB reader for ProcessCreditCardV1
• Implement USB reader for CreateCustomerCodeAndProcessCreditCardV1
• Implement USB reader for CreateCreditCardCustomerCodeV1
• Use JavaScript to focus card reader input form element
• Provide JavaScript to restore focus to USB reader input field if lost

Make CVV code optional to admin only

d.o: https://www.drupal.org/node/2316021

Implement new GetACHEFTPaymentBoxJournalCSVV2 method in wrapper

GetACHEFTPaymentBoxJournalCSVV2 / UK

• Add to PHP wrapper
• Add unit tests

Issue with accessing ACH/EFT approvals

User reports:

"I've run into what looks like an issue with accessing the ACH/EFT approvals from iATS using SOAP/PHP. Specifically, they seem to have had a problem with
GetACHEFTPaymentBoxJournalCSV
related to this bug:
https://bugs.php.net/bug.php?id=49169

Since they have no way of testing the ACH/EFT approvals, I wonder if maybe this error just went unnoticed in your api? In any case, I can't see any fancy work arounds in your code."

Refactor into two modules based on commerce_cardonfile dependency

The module is currently missing a required dependency for commerce_cardonfile. But I don't think we want to require that module if for the straight up credit card use case. It might make sense to create a submodule, commerce_iats_cardonfile, dependent on commerce_iats, and move all the customer code there. There might be some related architectural changes. @ruscoe, lets discuss before writing any code ...

/cc @bleeDev

"Result message" under Orders / Payments should be more user-friendly

Currently just displays status code from iATS.

For ACH – need to check status when submit

Implement Direct Post functionality

Estimate: https://docs.google.com/a/thinkshout.com/spreadsheet/ccc?key=0Ak2omtyEgaUCdDFkSmxpMW1nOS15Z3ljRG1TTVFPamc

Documentation: https://docs.google.com/a/thinkshout.com/file/d/0B02omtyEgaUCbWQwY1E1MWpxSGM/

• Add Process Key to appropriate payment method settings

  Standard

  • iats_credit_card
  • iats_credit_card_customer_code
  • iats_ach_eft
  • iats_ach_eft_customer_code
    • Test

  Card on File

  • iats_credit_card
  • iats_credit_card_customer_code
  • iats_ach_eft
  • iats_ach_eft_customer_code
    • Test

• Add "Use DPM" option to appropriate payment method settings (see above)

  • Test

• Add DPM form to credit card checkout pane

  • Test

• Add DPM form to ACH/EFT checkout pane

  • Test USD
  • Test CAD
  • Test GBP

• Add DPM form to credit card customer code checkout pane

  • Test

• Add DPM form to ACH/EFT customer code checkout pane

  • Test

• Create and expose public-facing URL for relay response from iATS API

• Modify checkout process to respond to iATS transaction updates received via the relay URL

• Credit card card on file customer code

  • Test recurring
  • Test non-recurring

• ACH/EFT card on file customer code

  • Test recurring
  • Test non-recurring

• UI

  • ACH/EFT form should respond to currency
  • Credit card expiration month / year should be select boxes

• Messages

  • iATS error message needs to persist past first page reload from relay URL

• Investigate missing transation ID in remote ID for ACH/EFT DPM payments

  • Not provided for ACH/EFT payments

• Test alternate payment method for card on file

Prevent Commerce attempting to process payments using CustomerLink

Currently Card on File records created using CustomerLink payment methods will cause Commerce to attempt to process future payments using CustomerLink, instead of ProcessLink.

• Automatically convert commerce_cardonfile table field payment_method value to iats_credit_card or iats_ach_eft instead of iats_credit_card_customer_code and iats_ach_eft_customer_code.
• Add a payment method setting to contain the instance ID of the payment method to process card on file payments with. i.e. iats_credit_card|commerce_payment_iats_credit_card

Leave off d.o. for now.

Prepare install profile for webinar

• Configure payment methods
• Create demo products
  • USD
  • CAD
  • GBP
• Create product display content type
• Create demo product content
  • USD
  • CAD
  • GBP
• Add checkout pane config module to installation
• Add test payment data
  • Credit card
  • Bank
    • USA
    • CAD
    • GBP
• Configure Direct Debit checkout panes
• Configure Direct Debit donations
• Theme
  • Login link
  • Cart link

Why do we need function commerce_iats_default_settings()?

Just want to explore if/why we need this. At first glance, it appears all the defaults except invoice_prefix are already defined in the base form commerce_iats_credit_card_settings_form_base(). Why not just set them as default values there?

If there's another use case for the function that I'm missing, do we need to provide the ability to alter it?

Refactor for best practices

Estimate: 5 hours

• Remove / reduce duplicate code
  • iATS wrapper instantiation
  • Transaction processing
• Clean up form usage
• General code tidy

Should commerce_iats_direct_post_relay() be secured?

Currently is wide open. Seems we should add some measure of security, E.g., having iATS post back the process key and ensure it matches to grant access. Or maybe they already are and can just use it in the access check?

Add explanatory comments to commerce_iats_cardonfile_menu_alter()

Error in test run

Fatal error: Call to undefined method iATS\ReportLinkTest::getCreditCardReject()

Enabling recurring without the correct checkout pane needs to fail gracefully

http://cgit.drupalcode.org/commerce_iats/tree/modules/commerce_iats_cardonfile/includes/commerce_iats_cardonfile.ach_eft_customer_code.inc#n130

Right now it's possible to enable recurring payments but neglect to enable the recurring checkout pane. This causes a bunch of warnings and then sends empty data to iATS.

Probably should not do those things.

Fix USA/CAD/GBP fields for ACH – sort code, routing etc.

Remove IPv6 IP addresses at the wrapper level

iATS does not support IPv6 IP addresses and the API will not behave in a friendly manner towards them.

Allow customer codes to be linked to new or existing Drupal users when using the card reader

RB: https://redbooth.com/a/#!/projects/897029/tasks/14747878

Investigate storing card type information locally after a payment

Check iATS response is an array before using array operations

Could use an is_array check before this line: http://cgit.drupalcode.org/commerce_iats/tree/commerce_iats.module?id=fb90ae2#n777

Why is commerce_iats_cardonfile altering its own form?

commerce_iats_cardonfile_form_commerce_cardonfile_card_form_alter(). If it stays, needs an explanation.

Make Card on File functionality optional

Card on File functionality should be enabled on a payment method basis. Add a checkbox to the payment method settings.

Leave off d.o. for now.

Update library requirement version check to use composer.json attribute

And remove version reference in other files.

Flush out missing methods defined in commerce_iats_commerce_payment_method_info()

Allow for both payment and recurring payment transactions during a single checkout workflow

D.O: https://www.drupal.org/node/2280649
RB: https://redbooth.com/a/#!/projects/897029/tasks/12986375
GH: #27

Update documentation with new ACH/EFT checkout panes

Need to add USD, CAD, and GBP checkout panes to documentation here and here.

Direct Debit panes need string overrides on buttons

Button text doesn't match iATS example forms for Direct Debit. Should override the text for consistency.

Obfuscate iATS password in payment method configuration

"******"

Editing stored card on LAC results in "O" error from iATS

RB: https://redbooth.com/a/#!/projects/897029/tasks/14231095

Issue with creating recurring payment from existing stored card

RB: https://redbooth.com/a/#!/projects/897029/tasks/14810194

Fix card on file operations compatibility with commerce_cardonfile beta5

Edit / delete operations do not appear when using commerce_cardonfile beta5. Only beta2.

https://www.drupal.org/node/2313559

Change server names

• NA (For USD and CAD currencies)
• UK (For all other currencies)

Explore validating payment methods

Currently, you can enable the iats payment methods without any verification of whether or not they're configured with even basic info like credentials. These methods then show on the checkout screen and lead to creative errors.

Also, direct debit throws a WSOD when a proper checkout pane is not added. Messaging and/or validation?