1        Introduction

This project involves the modification of the web site and underlying Avante code and data to accomodate the storing of sensitive credit card information off premises (at PayTrace). Doing so will involve modifications to the checkout process, as well as to the various places in Avante where credit card transactions are actually performed.  In general, the PCI compliance rules dictate that credit card information (full CC number and verification code) can not be saved in Laddawn's database in any retrievable form. Further, to be fully compliant, no packets containing credit card numbers can be transmitted on our network if the network is also used for other traffic.  The changes described in this document are designed to bring Laddawn's systems into compliance with these directives.

Goals

• Bring Laddawn into PCI compliance

Background and strategic fit

This work must be done in order to:

1. Comply with regulations and minimize risk involved with hosting ecommerce transactions
2. Create goodwill and confidence with Laddawn's customers.
3. Eliminate processor fees associated with being out of compliance.

Solution and scope

2        Definitions

PCI: Payment Card Industry

3        Assumptions

Most if not all credit card customers are satisfied with our current level of service. Our goal is not to provide new bells and whistles like the ability to store a card number for later use or add new functionality to the My Account area.

4        User Interaction and Design

1. Checkout

The current checkout process allows a customer to enter the required credit card information (name, cc #, expiration date, security code) and this data is transmitted over the Laddawn network and ultimately saved in Avante for later processing. the new process will make use of AJAX calls so that all sensitive information is transmitted to PayTrace directly from the user's PC without touching Laddawn's network.

User Experience

The user experience will be almost identical to what it is currently. The only difference in the user's visual experience is that the CC number field moves to the top of the credit card entry screen on the Payment tab of the checkout process. This will prompt the user to enter the CC number first. 

(Above) The current credit card entry screen

(Above) The revised screen with the credit card number at the top of the stack of fields.

Back-End 

From the development perspective, the process will follow the flow depicted below. (See the use case for a detailed description). When any transmission of the full credit card information takes place, it is done directly to the PayTrace site via AJAX calls to the PayTrace API, so that no packets containing credit card information are ever transmitted or received on the Laddawn network.

Notes from 4/20/17 meeting (Judy):

1. The token of Billto_CCLast4 is being written to SHOPPINGCART.USR.  It will write nulls to all other credit card fields in SHOPPINGCART.USR except for the security code.
2. Create Order will stake the Credit Card Last 4 digits only and write to the credit card# field in SOHDR.USR.  No other changes will be required.  If the UI isn't storing the other credit card info in the shoppingcart, then we will continue to move those null fields forward to SOHDR.USR.
3. SOP400 (order changes) - When the credit card screen is displayed, do a call to Paytrace API to verify and convert the cc# from 4 digits to *************4444.  If CE changes the credit card#, they must enter the 16 characters.  Possibly do a Luhn check on post process for the CC# field. We will do a verify/create API call to Paytrace at F2 and verify that they have entered a complete credit card and that it passes (and the token is created).  If an error occurs, fail the F2-Save.  We will store last 4 digits only in SOHDR.USR.
4. API call (from create pickslikps and workbench) - remove the pass of Credit Card#, Expiration Date, Names.  Keep the pass of security code and receipt email address.  Send Token (Billto_last4) instead - CUSTID field?
5. Workbench - When running a charge: Call API before screen to show in format **********4444.  If they change the credit card# (must enter complete 16 digits): At F2-Call API to create token, then do regular API call to run the charge.
6. When accounting dept is directly on Paytrace to pay old invoices: have them use the token when adding to a customer or creating a customer.
7. Conversion for SOHDR.USR to remove all credit card info except for last 4 digits of cc# 

2. Customer Experience

CE Enters Order on Behalf of Customer

Document process for CE entering the order with an existing credit card

CE Must Create New Credit Card for Customer

CE Must add/change credit card information on an Existing Order:

The Credit Card Information screen in Avante Sales Order Entry will change slightly.  The new screen layout is below.  The most notable change is that the fields now being stored on Paytrace for credit cards that have been tokenized will now be optional - they have been put into a box on the screen.

Examples:

• CE is changing a credit card# for this order to a card that doesn't exist on Paytrace.  Required entry:
  • Entire Credit Card#
  • Security Code
  • Expiration Date
  • Company Name
  • Card First/Last Name
• CE is changing the credit card# on this order to an existing credit card in Paytrace.  Required entry:
  • Token OR last 4 digits of CC#
  • Security Code
• CE is changing the Expiration Date, Company Name and/or Credit Card Name on an existing card in Paytrace.  Required entry:
  
  • Token or last 4 digits of CC#
  • Security Code
  • Exp Date, company name, and/or card name (only the data that is to be changed)

Sales Order Display of Credit Card Info will now show only the Token, security code and receipt email address:

3. Billing

This document only deals with the CE portion of the problem solution.

Need more information here on the billing process.

Credit Card Workbench Changes

The credit card workbench screen, which is used to run charges, refunds and void transactions by the Accounting Dept will be reformatted to have the required information at the top, and the optional information below.  Going forward, only the last 4 digits of the credit card# OR the Token (Billto#_LastFour) may be entered if this card has been used before.  This information along with the security code will be the only required info other than the amount that will need to be entered.  If the token isn't found, the user will be required to enter the entire credit card number, along with the information in the box (Expiration Date, Company Name, Credit Card First/Last Name).  Once this information is provided, a token will be assigned and the user will not have to enter the entire credit card number going forward.  In the case where a token already exists, but the expiration date, company name, and/or credit card name has changed, the new information may be entered in the box, and will be updated to Paytrace when this transaction is processed.

Examples:

• Accounting needs to rerun the same card that was already on the order:
  • The token and security code should appear on the screen - nothing further needs to be entered
• Accounting is charging a credit card# for this order to a card that doesn't exist on Paytrace.  Required entry:
  • Entire Credit Card#
  • Security Code
  • Expiration Date
  • Company Name
  • Card First/Last Name
• Accounting is changing the credit card# on this order to an existing credit card in Paytrace.  Required entry:
  • Token OR last 4 digits of CC#
  • Security Code
• Accounting is changing the Expiration Date, Company Name and/or Credit Card Name on an existing card in Paytrace.  Required entry:
  
  • Token or last 4 digits of CC#
  • Security Code
  • Exp Date, company name, and/or card name (only the data that is to be changed)

4. Retrofit

For the existing valid credit cards in Avante now, we need to generate tokens for each (billto +  last 4) and submit to PayTrace. This should be done only for CC's with valid expiration dates.  Once the conversion to PayTrace is complete, the original cc numbers should be replaced with the tokens. For invalid credit cards in Avante, we should simply clear the CC info from Avante.

Not Doing

Since adding PCI Compliance to the site will not result in any additional revenue or cost savings, there will be no additional features added as part of this enhancement.  Features to consider at a later time include:

• Showing a list of available cards to the user at checkout. The user would be able to select a card that had been used in the past as the current payment method.
• Showing a list of defined cards in the "My account" area so that the user could maintain their on-file cards without having to go through a checkout process.

5        Use Cases

User Checks Out with Credit Card

The user has put item(s) in his cart and wishes to check out. He has started the checkout process as usual.

1. User fills out the checkout tabs as usual
2. On the 'Payment' tab, the user selects 'Pay by credit card'
3. The credit card section opens and the user sees the credit card number field as the first field in the section
4. The user enters the full 16-digit credit card number. 
5. The site performs a client-side Luhn check to validate the number, as well as a check on the expiration date to determine if the date is current.
6. If the number is invalid, the user sees an error message and is positioned back on the cc number field.
   
7. If the number is valid, the token is created from the user's billto number plus the last four digits of the CC
8. The token is looked up in Avante
9. If the token exists then this CC has already been entered. The data (name, exp date, etc.) for this card is retrieved and displayed.
10. If the token does not exist, nothing is displayed.
11. The user either enters new CC info, including CVV, or verifies and possibly edits the existing CC info (most likely exp. date), including CVV
12. The user clicks 'Save and Continue'
13. The site performs an AJAX call to the PayTrace api to store the CC. It is added/updated on the PayTrace site.
14. If PayTrace's operation is successful, the token and non-sensitive card information is saved in Avante to all the places it is needed.
15. If PayTrace's operation is unsuccessful, the user sees an error message and is positioned back on the cc number field to try again.
    << Need an error mockup here >>

6        Testing

New Card

1. Fill a card and proceed to the checkout tabs as usual
2. On the 'Payment' tab, select 'Pay by credit card'
3. Ensure that the credit card section opens and the credit card number field is the first field in the section
4. Enter the full 16-digit credit card number. Try intentionally bad numbers to ensure the error message.
5. If the number is invalid, verify error message and get positioned back on the cc number field.
   
6. Try a valid number (that has not been defined for the account).  In other words, for the selected customer, use a new CC that has never been used for the customer before.
7. Since it is a new CC#, there should be no existing information displayed. Enter the rest of the cc information, including CVV.
8. Click 'Save and Continue'
9. Check in Avante that the token has been created, and it has been saved in the appropriate places. 
10. Check in PayTrace to see that the card has been defined and has the correct meta data (token, name, number, exp date, etc.)

Existing Card (Non-Expired)

1. Fill a card and proceed to the checkout tabs as usual
2. On the 'Payment' tab, select 'Pay by credit card'
3. Try a valid number that has been used by the billto before (one that already has a token in the database).
4. The token exists so the data (name, exp date, etc.) for this card should be retrieved and displayed.
5. Enter CVV
6. Click 'Save and Continue'
7. Check in Avante that the token has been saved in the appropriate places. 
8. Check in PayTrace to see that the card has been defined and has the correct meta data (token, name, number, exp date, etc.)

 Existing Card (Expired)

1. Fill a card and proceed to the checkout tabs as usual
2. On the 'Payment' tab, select 'Pay by credit card'
3. Try a valid number that has been used by the billto before (one that already has a token in the database) but that has an expired date.
4. The token exists so the data (name, exp date, etc.) for this card should be retrieved and displayed, including the old expiration date.
5. Enter CVV
6. Click 'Save and Continue'
7. Ensure that you get an 'Invalid payment method' error message.
8. Ensure that you are placed at the credit card number, ready to edit.
9. Change the expiration date to a future date.
10. Click 'Save and Continue'
11. Check in Avante that the token has been saved in the appropriate places. 
12. Check in PayTrace to see that the card has been defined and has the updated meta data (token, name, number, exp date, etc.)

7        Change management and rollout planning

<< Which departments are affected by these changes? What are the possible negative perceptions of these changes, and how do we manage them? Articulate "what's in it for me?" for all internal and external stakeholders. Are call scripts necessary? Is advance customer outreach/communication necessary? What lead time is needed for training and other advance preparations? >>