Functional Specification Template

Credit Card Integration with Salesforce

Functional Specification

Author

Date

Version: 1.0

2010 Avankia LLC. All rights reserved.

The information contained in this document represents the current view of Avankia LLC on the issues discussed as of the date of

publication. Because Avankia must respond to changing market conditions, it should not be interpreted to be a commitment on

the part of Avankia, and Avankia cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. AVANKIA MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS

DOCUMENT.

Avankia and DBSync are either registered trademarks or trademarks of Avankia in the United States and/or other countries.

1

Revision & Sign-off SheetChange Record

Date Author Version Change Reference

ReviewersName Version Approved Position Date

DistributionName Position

Document PropertiesItem DetailsDocument TitleAuthorCreation DateLast Updated

2

Table of Contents

Project Vision/Scope Summary........................................................................4Project History..................................................................................................4Project Justification and Design Goals.............................................................4

Business Requirements Summary................................................................5User Requirements Summary.......................................................................5Assumptions and Dependencies..................................................................5Functional Specification ...……………………………………………………....6Usage Scenarios/Use Case Studies Summary...........................................11

Feature Cuts and Unsupported Scenarios.....................................................14Solution Design...............................................................................................14

Conceptual Design Summary.....................................................................14Logical Design Summary............................................................................14Physical Design Summary..........................................................................15

Security Strategy Summary............................................................................15Installation/Setup Requirements Summary....................................................15Un-Installation Requirements Summary.........................................................15Integration Requirements Summary...............................................................15Supportability Summary..................................................................................16Legal Requirements Summary.......................................................................16Risk Summary................................................................................................16References.....................................................................................................16Appendix.........................................................................................................17

3

Project Vision/Scope Summary

Description: The credit card integration processing is designed to link the lead activities and purchases by GetSolar partner solar companies (GetSolar Customers) in Salesforce.com system with their Authorize.Net account.

The integration should be fully automated so when a purchase transaction occurs in Salesforce.com, the credit card is charged automatically and a transaction receipt is recorded.

Project History

GetSolar requires to integration of credit card for payment process for lead activities created in Salesforce. Right now the payment process is manual where they create a payment in their Authorize.Net for each lead created in Salesforce and put the details manually back into the Salesforce.

Project Justification and Design GoalsAuthorize.Net account uses their Customer Information Manager (CIM) which securely stores the credit card information and other billing information in Authorize.Net database. The individual account profiles in the CIM are created by the customer on the GetSolar website via an API with Authorize.Net.

4

Business Requirements Summary

1. RQ101 - Automated Payment: When a lead is created in Salesforce it is sent to vendors (Account in Salesforce) for preview.

To view the lead, vendor logs into Salesforce. If vendor wants to buy the lead they change the status to “Preview Accepted”. Once vendor accepts the lead, one vendor lead is created in Salesforce and vendor lead status is set to “Preview Accepted”. It fires an APEX code that creates custom object “transaction object” in Salesforce. Transaction object consists of ‘Transaction ID’, ‘Account/Vendor Name’, ‘Price’, ‘status’ and ‘Lead Name’. Transaction is attached with vendor lead. It also populates the transaction number into transaction field of vendor lead.

a. Once a transaction object is created, either the transaction will be added to a batch or immediate call will be made to Authorize.Net CIM for the appropriate Account Name/ID and the dollar value of the transaction (variable based on rules) will be charged. Authorize CIM identifiers are available on the following Salesforce Account fields: Authorize: Customer Profile ID (Authorize_Customer_Profile_ID__c)Authorize: Customer ID (Authorize_Customer_ID__c)

b. Once Payment process is complete, and system receives a confirmation message from Authorize.Net and data will updated in the transaction object. The value of transaction status field is set to “Received”.

c. All the information related to transaction has to be recorded in transaction object (Need to create fields or related list to save transaction record).

d. If there is any error during the transaction and Authorize.Net returns with a failure message, the details for errors and failures must also be captured on transaction object.

2. RQ102 - Get Payment: Salesforce user should be able to process the payment manually from Salesforce transaction object.

3. RQ103 - Batching and Multiple Charges: Batching of payment process for multiple transaction object and multiple charges should be available. [this is an issue – Assumptions how many transactions at a time because we have governance issues]

4. RQ104 – Void/Credit Back: Ability to “void/ credit back” a transaction should be available. [Default Out of the box functionality]

Assumptions and Dependencies1. “Transaction” object is a custom object created by GetSolar.com. 2. Apex will need to interface with this custom object. 3. Maximum number of API outbound call is 250, so more than 250 automatic transactions in a

day is not functional in this release.4. Need identification of fields to be updated in Transaction Object for payment process.

5

Functional Specification

Requirement Number Functional Specification

RQ101 FRS101 - Automated Payment

RQ102 FRS102 - Get Payment

RQ103 FRS103 - Batching and Multiple Charges

RQ104 FRS104 - Void/ Credit Back

FRS101 - Automated Payment: Once a transaction object is created, the transaction will be charged immediately. Call will be made to Authorize.Net CIM for the appropriate Account Name/ID and the dollar value of the transaction (variable based on rules) will be charged. Authorize CIM identifiers are available on the following Salesforce Account fields:

Field Name Description CommentsStatus Transaction Object Status, stored in Transaction

Object with API Name “Status__c”

Amount Amount of the transaction, stored in Transaction Object with API Name “Price__c”

Customer Profile ID Authorize.Net Customer Profile ID, stored in Account Object with API Name “Authorize_Customer_Profile_ID__c”.

Customer ID Authorize.Net Profile ID, stored in Account Object with API Name “Authorize_Customer_ID__c”.

Invoice# GS ID + “-“ + last name (on Vendor Lead record)

PO# GST number (on Vendor Lead record)

Description “GetSolar” + Lead Record Type + Project Type (all fields on the Vendor Lead record)

6

Activity Description Comments

FRS102 Get PaymentSalesforce user should be able to process the payment manually from Salesforce transaction object. The Payment is processed, transaction object status is set to “Received” and transaction should be removed from batch..

Field Name Description CommentsStatus Transaction Object Status, stored in

Transaction Object with API Name “Status__c”

Amount Amount of the transaction, stored in Transaction Object with API Name “Price__c”

Customer Profile ID Authorize.Net Customer Profile ID, stored in Account Object with API Name “Authorize_Customer_Profile_ID__c”.

Customer ID Authorize.Net Profile ID, stored in Account Object with API Name

7

“Authorize_Customer_ID__c”.

Invoice# GS ID + “-“ + last name (on Vendor Lead record)

PO# GST number (on Vendor Lead record)

Description “GetSolar” + Lead Record Type + Project Type (all fields on the Vendor Lead record)


FRS103 Batching and Multiple ChargesBatching of payment process for multiple leads and multiple charges should be available. [This is an issue – Assumptions how many at a time because we have governance issues] BIG ISSUE need to educate end customer [Screen Design & Use Case required and maximum number of records].

Field Name Description CommentsStatus Transaction Object Status, stored in Transaction Object

8

with API Name “Status__c”Amount Amount of the transaction, stored in Transaction Object

with API Name “Price__c”Customer Profile ID Authorize.Net Customer Profile ID, stored in Account

Object with API Name “Authorize_Customer_Profile_ID__c”.


Invoice# GS ID + “-“ + last name (on Vendor Lead record) PO# GST number (on Vendor Lead record)Description “GetSolar” + Lead Record Type + Project Type (all

fields on the Vendor Lead record)


FRS104 Void/Credit BackWhen a transaction is complete for a Transaction Object, Salesforce user should have option to “void or Credit Back” the transaction manually. Once the Credit Back is complete and APEX receives a response from Authorize.Net Transaction status field is set to “Refunded” and Rest of the information is put on related list/fields.

Field Name Description CommentsStatus Transaction Object Status, stored in Transaction Object

9

with API Name “Status__c”Amount Amount of the transaction, stored in Transaction Object

with API Name “Price__c”Customer Profile ID Authorize.Net Customer Profile ID, stored in Account

Object with API Name “Authorize_Customer_Profile_ID__c”.


Code Authorize.Net Transaction ID, stored in Transaction Object Field/Related List


Usage Scenarios/Use Case Studies Summary

Use Case: Automatic Payment

Id: UC- 101

Pre-Conditions Customer Profile ID, Customer ID, Transaction Object Status “Ready To Charge”

Post Conditions

Transaction Objects Status field is set to “Received”. Transaction related information is stored into Transaction Object.

10

Description When a Transaction Object is created the related vendor should be charged for transaction amount automatically. Customer Profile ID and Customer ID fields are available in Account related to transaction object. Authorize.Net CIM will also be passed 3 extra information as listed below to be stored in CIM transaction:

Invoice # = GS ID (on Vendor Lead record) + “-“ + ”last name”Example (see below): GS-013798-Steffan

PO # = GST number (on Vendor Lead record)Example (see below): GST-1525

Description = “GetSolar” + Lead Record Type + Project Type (all fields on the Vendor Lead record)Example: GetSolar Residential Solar Electric (PV)

Once the payment is complete and APEX receives a response from Authorize.Net Transaction status field is set to “Received” and Rest of the information is put on related list/fields.

Normal Flow Transaction is processed; APEX receives a response from Authorize.Net. Transaction Object status is updated and rest of the information is captured on the related list/fields.

Exception Flow

Transaction is not processed; APEX receives a response from Authorize.Net. Transaction Object’s error field is updated with error information.

Primary Actor Get Solar Salesforce user

Supporting Actors

Authorize.Net, Salesforce

Stakeholders and Interests

<List Stakeholders and their interests here>

Use Case: Get Payment Id: UC- 102


Post Conditions

Transaction Objects Status field is set to “Received”. Transaction related information is stored into Transaction Object and Transaction should be removed from Batch.

Description When a Transaction Object is created and status is set to “Ready to Charge” the Salesforce user should have option to process the transaction manually using a button “Get Payment”. Once the user clicks on “Get Payment” button; APEX will fetch the transaction information from transaction object, Customer Profile ID and Customer ID fields from Account related to transaction object. Authorize.Net CIM will also be passed 3 extra information as listed below to be stored in CIM transaction:

Invoice # = GS ID (on Vendor Lead record) + “-“ + ”last name”

11

Example (see below): GS-013798-Steffan



Once the payment is complete and APEX receives a response from Authorize.Net Transaction status field is set to “Received” and Rest of the information is put on related list/fields.


Exception Flow



Supporting Actors




Use Case: Batching and Multiple Charges

Id: UC- 103


Post Conditions

Transaction Objects Status field is set to “Received”. Transaction related information is stored into Transaction Object.

Description When a Transaction Object is created it will get added in Transaction Batch that will be executed at a defined time of a day. All vendors should be charged for transaction amount automatically. Customer Profile ID and Customer ID fields are available in Account related to transaction object. Authorize.Net CIM will also be passed 3 extra information as listed below to be stored in CIM transaction:

Invoice # = GS ID (on Vendor Lead record) + “-“ + ”last name”Example (see below): GS-013798-Steffan



12

Once the payment is complete and APEX receives a response from Authorize.Net Transaction status field is set to “Received” and Rest of the information is put on related list/fields for all successful Transactions.


Exception Flow

Transaction is not processed; APEX receives a response from Authorize.Net. Transaction Object’s error field is updated with error information. Transaction Object remains in the Batch for next automatic process.


Supporting Actors




Use Case: Void Payment or Credit BackId: UC- 104

Pre-Conditions Customer Profile ID, Customer ID, Transaction Object Status “Received”

Post Conditions

Transaction Objects Status field is set to “Refunded”. Transaction related information is stored into Transaction Object and Transaction should be removed from Batch.

Description When a transaction is complete for a Transaction Object, Salesforce user should have option to “void or Credit Back” the transaction manually using a button “Void/Credit Back”. Once the user clicks on “Void/Credit Back” button; APEX will fetch the transaction information from transaction object, Customer Profile ID and Customer ID fields from Account related to transaction object. and the charge will be credited back or voided.

Once the Credit Back is complete and APEX receives a response from Authorize.Net Transaction status field is set to “Refunded” and Rest of the information is put on related list/fields.


Exception Flow



Supporting Actors




13

Feature Cuts and Unsupported Scenarios<<Begin text here>>

Solution Design[Description: The Solution Design section identifies the design documents that have been developed and summarizes the overall solution design in a succinct statement. It should also define why each of these design documents is necessary for the project.

Justification: This information provides the reader with strategic context for the follow on reading. It explains the differences between the design documents and explains how each provides a unique picture of the solution.]<<Begin text here>>

Conceptual Design Summary[Description The Conceptual Design Summary section provides a summary of the contents of the Conceptual Design document. This should include a succinct statement of the contents of each of the key sections of the document (Solution Overview and Solution Architecture, etc.).

For some projects, it may be appropriate to include the entire contents of the design document, if a choice has been made to consolidate all technical documentation into one large central document.]<<Begin text here>>

Logical Design Summary[Description: The Logical Design Summary section provides a summary of the contents of the Logical Design document. This should include a succinct statement of the contents of each of the key sections of the document (Users, Objects, Attributes, etc.)

For some projects, it may be appropriate to include the entire contents of the design document, if a choice has been made to consolidate all technical documentation into a large central document.]<<Begin text here>>

Physical Design Summary[Description The Physical Design Summary section provides a summary of the contents of the Physical Design document. This should include a succinct statement of the contents of each of the key sections of the document (Application, Infrastructure, etc.)

For some projects, it may be appropriate to include the entire contents of the design document, if a choice has been made to consolidate all technical documentation into one large central document.]<<Begin text here>>

14

Security Strategy Summary[Description: The Security Strategy Summary section describes the solution security strategy that will influence the design. The following questions will assist in developing this strategy:

What are the principal objectives to providing a secure environment? What compromises in security are necessary for user convenience, usability, and

performance? What specific security tools and technologies will be implemented within the solution?

The Physical Design document contains the specific security details in a per-feature/per-component format. This strategy section should be a brief synopsis of a uniform security strategy, along with references to the Security Plan.]<<Begin text here>>

Installation/Setup Requirements Summary[Description: The Installation/Setup Requirements Summary section is a summary of the environmental requirements for solution installation. This information may be derived from the Deployment Plan’s installation sections. The Physical Design document contains the detail on how these requirements will be satisfied.]<<Begin text here>>

Un-Installation Requirements Summary[Description: The Un-Installation Requirements Summary section describes how the solution is removed from its environment. This should include a definition of what must be considered prior to removing the solution and what must be considered in a backup/restore capacity prior to un-installing to insure safe recovery/rebuild at a later time.]<<Begin text here>>

Integration Requirements Summary[Description: The Integration Requirements Summary section is a summary of integration and interoperability requirements and the project goals related to these requirements. The Migration Plan may be referenced or summarized here, as it contains integration and interoperability specifications. The Physical Design document contains the detail on how integration will be delivered.]<<Begin text here>>

Supportability Summary[Description: The Supportability Summary section is a summary of the supportability requirements and the project goals related to these requirements. The Operations Plan and Support Plan may be referenced or summarized here, as they contain supportability specifications. The Physical Design document contains the detail on how supportability will be delivered.]<<Begin text here>>

15

Legal Requirements Summary[Description: The Legal Requirements Summary section is a summary of any legal requirements to which the project must adhere. Legal requirements may come from the customer’s corporate policies or from regulatory agencies governing the customer’s industry.]<<Begin text here>>

Risk Summary[Description: The Risk Summary section identifies and describes the risks associated with the Functional Specification. This should include all risks that may impact development and delivery of the solution where the risk source is the content of the Functional Specification. The list of risks should be accompanied by the calculated exposure for each risk. If appropriate, this section may also contain a summary of the mitigation plans for those risks.]<<Begin text here>>

References[Description: The References section identifies any internal or external resources that would provide supplementary information to the Functional Specification.]<<Begin text here>>

16

Appendix

17

Documents

Functional Specification Template