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 Sheet
Change Record
Date Author Version Change Reference

Reviewers
Name Version Approved Position Date

Distribution
Name Position

Document Properties
Item Details
Document
Title
Author
Creation Date
Last Updated

2
Table of Contents

Project Vision/Scope Summary.........................................................................4

Project History....................................................................................................4
Project Justification and Design Goals..............................................................4
Business Requirements Summary.................................................................5
User Requirements Summary........................................................................5
Assumptions and Dependencies...................................................................5
Functional Specification ...……………………………………………………....6
Usage Scenarios/Use Case Studies Summary...........................................11
Feature Cuts and Unsupported Scenarios......................................................14
Solution Design................................................................................................14
Conceptual Design Summary......................................................................14
Logical Design Summary.............................................................................14
Physical Design Summary...........................................................................15
Security Strategy Summary.............................................................................15
Installation/Setup Requirements Summary.....................................................15
Un-Installation Requirements Summary..........................................................15
Integration Requirements Summary................................................................15
Supportability Summary...................................................................................16
Legal Requirements Summary........................................................................16
Risk Summary..................................................................................................16
References.......................................................................................................16
Appendix..........................................................................................................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 Goals

Authorize.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 Dependencies

1. “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 Comments

Status 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
Automated Payment
Salesforce Authorize.Net
1. Transaction Created and Status “Ready to Charge”
Start APEX Process
<<TRANSACTION>> <<CIM>>
+ TransactionID
+ Account CaptureOnlyTransaction()
+ Status 2. Get Transaction Info
+ Lead (Account, Lead, Price)
+ Price
3. Request CaptureOnlyTransaction

5. Update Transaction Status

to “Received” <<Apex>>

PaymentProcess()
UpdateSalesforceObjects()
2.1 Get Account Info
(RefID,CustProfileID,ShippingAddress 4. Receive Transaction Details
CustPmtProfileID)

2.2 Get Vendor Lead Information

<<ACCOUNT>>
+ Name
+ CustProfileID
+ CustomerID
<<VENDOR LEAD>>
+ AccountRecordType
+ GSID
+ Transaction
+ VendorLeadStatus
+ ProjectType
+ LeadRecordType

Activity Description Comments

FRS102 Get Payment

Salesforce 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 Comments
Status 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”.

7
 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)

Get Payment
Salesforce Authorize.Net

1. Transaction Status “Ready to Charge” and

Click on Get Payment Button
<<TRANSACTION>> <<CIM>>
+ TransactionID
+ Account CaptureOnlyTransaction()
+ Status 2. Get Transaction Info
+ Lead (Account, Lead, Price)
+ Price
3. Request CaptureOnlyTransaction

5. Update Transaction Status <<Apex>>

to “Received”
PaymentProcess()
UpdateSalesforceObjects()
2.1 Get Account Info UpdateBatch()
(RefID,CustProfileID,ShippingAddress
CustPmtProfileID) 4. Receive Transaction Details
7. Delete Transaction
From Batch
<<ACCOUNT>>
+ Name
2.2 Get Vendor Lead Information
+ CustProfileID
+ CustomerID <<Batch>>
+ AccountRecordType + TransactionID

<<VENDOR LEAD>>
+ GSID
+ Transaction
+ VendorLeadStatus
+ ProjectType
+ LeadRecordType

Activity Description Comments

FRS103 Batching and Multiple Charges

Batching 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].

8
 Field Name Description Comments
Status 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)

Automatic Batch Payment

Salesforce Authorize.Net

<<Apex>>
1. Transaction Created and <<CIM>>
Status “Ready to Charge”
AddToBatch()
CaptureOnlyTransaction()
2. Update Batch

<<Batch>>
<<TRANSACTION>> + TransactionID
+ TransactionID
+ Account 4. Request CaptureOnlyTransaction
+ Status 3. Get Transaction Info
+ Lead (Account, Lead, Price)
+ Price

6. Update Transaction Status

to “Received”
<<Apex>>

+Daily Execution Time

BatchPaymentProcess()
UpdateSalesforceObjects()
3.1 Get Account Info
5. Receive Transaction Details
(RefID,CustProfileID,ShippingAddress
CustPmtProfileID)

2.2 Get Vendor Lead Information

<<ACCOUNT>>
+ Name
+ CustProfileID
+ CustomerID
+ AccountRecordType
<<VENDOR LEAD>>
+ GSID
+ Transaction
+ VendorLeadStatus
+ ProjectType
+ LeadRecordType

Activity Description Comments

FRS104 Void/Credit Back

When 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.

9
 Field Name Description Comments
Status 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”.
Code Authorize.Net Transaction ID, stored in Transaction
Object Field/Related List

<Process Name>
Salesforce Authorize.Net
1. Transaction Status “Received” and
Click on Void/Credit Back Button
<<TRANSACTION>> <<CIM>>
+ TransactionID
+ Account
CaptureOnlyTransaction()
+ Status 2. Get Transaction Info
+ Lead (Account, Lead, Price)
+ Price
+ Error 3. Request CaptureOnlyTransaction

Update Transaction Status

<<Apex>>
to “Refunded”
CreditBackProcess()
2.1 Get Account Info UpdateSalesforceObjects()
(RefID,CustProfileID,ShippingAddress
CustPmtProfileID) 4. Receive Transaction Details

<<ACCOUNT>>
+ Name
+ CustProfileID
+ CustomerID
+ AccountRecordType

Activity Description Comments

Usage Scenarios/Use Case Studies Summary

Use Case: Automatic Payment

Id: UC- 101

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

Post Transaction Objects Status field is set to “Received”. Transaction related

Conditions information is stored into Transaction Object.

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 Transaction is not processed; APEX receives a response from Authorize.Net.
Flow Transaction Object’s error field is updated with error information.
Primary Actor Get Solar Salesforce user

Supporting Authorize.Net, Salesforce

Actors

Stakeholders <List Stakeholders and their interests here>

and Interests

Use Case: Get Payment

Id: UC- 102

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

Post Transaction Objects Status field is set to “Received”. Transaction related

Conditions 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

11
 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”

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 Transaction is not processed; APEX receives a response from Authorize.Net.
Flow Transaction Object’s error field is updated with error information.
Primary Actor Get Solar Salesforce user

Supporting Authorize.Net, Salesforce

Actors

Stakeholders <List Stakeholders and their interests here>

and Interests

Use Case: Batching and Multiple Charges

Id: UC- 103

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

Post Transaction Objects Status field is set to “Received”. Transaction related

Conditions 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

 PO # = GST number (on Vendor Lead record)

Example (see below): GST-1525

12
  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 for all successful Transactions.
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 Transaction is not processed; APEX receives a response from Authorize.Net.
Flow Transaction Object’s error field is updated with error information. Transaction
Object remains in the Batch for next automatic process.
Primary Actor Get Solar Salesforce user

Supporting Authorize.Net, Salesforce

Actors

Stakeholders <List Stakeholders and their interests here>

and Interests

Use Case: Void Payment or Credit Back

Id: UC- 104

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

Post Transaction Objects Status field is set to “Refunded”. Transaction related

Conditions 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.
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 Transaction is not processed; APEX receives a response from Authorize.Net.
Flow Transaction Object’s error field is updated with error information.
Primary Actor Get Solar Salesforce user

Supporting Authorize.Net, Salesforce

Actors

13
 Stakeholders <List Stakeholders and their interests here>
and Interests

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.]

14
<<Begin text here>>

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