SOURCES SOUGHT
70 -- SSA E-Commerce Total Solution
- Notice Date
- 1/17/2013
- Notice Type
- Sources Sought
- NAICS
- 511210
— Software Publishers
- Contracting Office
- Social Security Administration, Office of Budget, Finance, and Management, Office of Acquisition and Grants, 1st Floor, Rear Entrance, 7111 Security Blvd., Baltimore, Maryland, 21244
- ZIP Code
- 21244
- Solicitation Number
- SSA-13-SERS
- Archive Date
- 2/8/2013
- Point of Contact
- Monica M. Yankle, Phone: 4105942032, Kathy C Fain, Phone: 410-965-4853
- E-Mail Address
-
monica.yankle@ssa.gov, kathryn.fain@ssa.gov
(monica.yankle@ssa.gov, kathryn.fain@ssa.gov)
- Small Business Set-Aside
- N/A
- Description
- The purpose of this Request for Information (RFI) from the Social Security Administration (SSA) is to identify responsible vendors who can provide a streamlined remittance process and an automated system solution to collect fees from SSA's field offices for non-programmatic services. The total system solution, Social Security Remittance System, (SERS) will provide 1300 field offices with an automated solution to collect, track, record, and report on fees collected for providing various non-programmatic services to individuals and third parties. A key part of SERS is an E-Commerce software solution. This software will be integrated with SSA's accounting system, SSOARS, which is based on Oracle's E-Business Suite Software. The mandatory requirements are listed below. Additionally, the services of a Gateway Software vendor are required for plastic card authorization/verification purposes. The plastic card Gateway vendor will access the Department of the Treasury's designated payment processor, Vantiv LLC (Vantiv), for immediate authorization processing and will send approval information back to SERS to complete the order. Offerors will be provided with a list of authorized Treasury authorized Gateway vendors to solicit. Pin pads will be acquired as part of the whole SERS solution. Although, the check scanners will not be acquired by SERS, implementation and integration into the total SERS solution is required. Technical support services from the vendor for implementation and integration of the entire E-Commerce solution will be required. Full functionality is expected within six months from award, and full implementation across all SSA Field Offices is anticipated to take one year. SSA seeks information in the form of clear and definitive written documentation describing a vendor's capabilities to provide the ENTIRE solution including the mandatory requirements listed below. Responses must address each of the eCommerce software product requirements listed below in sufficient detail to enable SSA to determine current market capabilities. Additionally, responses must address the capability to acquire an authorized Gateway software vendor, pin pads, and provide technical support services for full SERS implementation. Mandatory Requirements: Your response must address the following E-Commerce Software requirements: The contractor's solution shall: Accept customer transactions entered on a PCI-approved plastic card reader ("pin pad") device and from a check scanner. Accept plastic card information by entering it directly into the system and by swiping a credit card on a pin pad device. Be capable of communicating with third-party payment processors for real-time authorization and end of day settlement processing. Be capable of operating on a standard SSA PC/workstation. The current minimum specifications for an SSA Win7 workstation are: Intel Dual Core processor @ 3.00 GHz, 4.0 GB RAM; 160 GB hard drive; Nvidia Quadro NVS 290 PCI video card, max res 2048x1536@75 Hz;256 MB memory; 22-inch wide screen monitor; and a 32-bit Win7 operating system. Provide a single logical database within SOARS, and avoid duplication of data and the additional costs of maintaining multiple databases. Have an infrastructure that works with SSA's existing infrastructure and information technology (currently Unix based and Oracle Database). Utilize COTS software with no customization required. It may be configured or extended, but these configurations and extensions must not interfere with ease of maintenance or upgrade to both the E-Commerce application and the SSA SSOARS applications. Be capable of embedding rules in the application without the need for additional programming. Manage orders, create transactional documents, process payments, and pass accounting transactions in real-time to SSOARS. Have the capability to warehouse or inventory orders to be filed at a later date. Have the capability to handle third-party requests originating from the Internet. Be capable of annotating on the order that payment has been accepted, that it has been posted to the accounting system, and in the case of NSF checks, that payment has been rejected. Be capable of generating alerts or contain workflow processes to notify the field office employee that an order must be filled. Have the capability to generate an invoice for mail-in requests. Have the capability to generate receipts that contain a unique alpha/numeric field that can be used to trace the order to the invoice, payment, and applicable programmatic system (i.e., the system that contains the source information that is being requested). Have the capability to "remember" the requestor's name, address, telephone number, and email address, and include this information in a local drop-down or search list so that it can be readily recalled and not have to be re-entered for the same requestor. Have the capability to enter the name and last four digits of the SSN of the person whose information is being requested. Have the capability to identify the user's component (e.g., region, area, field office) without the user entering this information. Have the capability to process customer transactions initiated by the public and third parties for walk-in, mailed, or faxed requests. SERS will eventually support web-based and telephone customer transactions. Automatically update the Accounts Receivable (AR) module in SSOARS in real-time. Support secure transactions that will include card encryption or tokenization capabilities that comply with existing PCI Data Security Standard (PCI DSS) and Payment Application Data Security Standards (PA-DSS). Be in compliance with all binding federal information security guidance and standards including FIPS 140-2, applicable National Institute of Standards and Technology guidance, and SSA's Information Security Standards and Policy guidance. Support the use of Point-to-Point Encryption (P2PE) as defined by the PCI Security Standards Council. Have the capability to encrypt the credit card information in accordance with the PCI DSS P2PE standards (i.e., in the same way that the card swipe encrypts the information). Not store any customer branded plastic card data or other Personally Identifiable Information. Be able to process cancellations, modifications, and re-invoicing in instances where the customer wishes to cancel or modify a transaction. Also, must be able to process reversals for transactions that are timed out or are unsuccessful due to network issues, power failures, etc. The reversals must be performed in real-time with no manual intervention required. Support real-time integration between SERS and SSOARS. This shall be a technology or technologies that work with SSOARS' existing server and database technology stack (currently Unix based and Oracle Database). These internal interfaces must be implementable out of the box, without customization required for SERS to communicate with SSOARS. It would, however, be acceptable to include the installation of an out of the box adapter for our SSOARS technology stack to implement these internal interfaces between SERS and SSOARS. Internal interfaces must be based on non-proprietary protocols. Support real time communications with other SSA applications and databases. The interfaces to other SSA systems must support, at a minimum, Mainframe-based systems (for example but not limited to, CICS applications, Cold Fusion applications, WebSphere Applications), Linux/Unix based systems, and Windows based systems. External interfaces must be based on non-proprietary protocols. Be Unix-based and supportable within the current SSOARS technology environment. SSA will not support an additional hardware platform for the implementation of SERS. Any required infrastructure must be supportable within the current SSOARS Unix based environment. Feature software and interfaces that are acceptable to and supported by the SSA technology environment and SSA review boards (SSA review boards include but are not limited to the architecture review board, infrastructure review boards, and security reviews). Please note that, as a general rule, freeware software is not acceptable in the SSA environment except in cases where support for the freeware is included with the solution. Be scalable to configure additional SSA workloads and collection types. Be capable of ensuring that the scanned check amount matches what is entered by users in SERS and alerting the user if it does not match. Be capable of flagging duplicate entries in the check scanning process. Be capable of receiving a file from Treasury to perform reconciliations of data that is transmitted from SERS to Treasury. Be capable of being configured to work with check scanning devices from RDM Corporation. The E-Commerce vendor will ensure that the check scanners are installed and are operable with their solution. Be capable of transmitting check information (both data and image) to Treasury's OTCNet Application. Have the capability to create two separate image files: one for administrative fees to be retained centrally and sent to Treasury, and a second file for program debt that contains the check image and the payment stub scan line to be forwarded to SSA's Mid-Atlantic Program Service Center. Have the capability to index check image files and to perform searches based on key data on the check image. Have the capability to verify scanned check information against a Treasury Negative Check Database maintained on SSA's network. Have the capability to produce Management Information (MI) Reports that provide number of fees by type, office location, and process (walk-in versus mail-in) that were invoiced, receipted, abandoned, (i.e., requestor withdrew request during transaction), collected, and not collected (due to NSF check) Have the capability to produce MI reports or dashboards that provide the total amount billed, total amount receipted, total amount collected, total amount due, and total number of services performed by type, area, office, and customer. Have the capability to produce MI Reports that are only available to authorized users, e.g., a regional office may access any office's information within their region but not in any other region. An Area Director may access only those field office reports and data that come under their jurisdiction. A field office can only access its own data and reports. Authorized Headquarters components may access all data. Your response must address the following Gateway Services requirements: The contractor's solution shall: Provide a secure plastic card transaction processing solution. Secure transactions must include card encryption or tokenization capabilities that comply with PCI Data Security Standard (PCI DSS), Payment Application Data Security Standards (PA-DSS), P2PE, and SSA standards. The solution must also be PIN Entry Device (PED) compliant. Not expose any existing systems to exposure to PCI audits and network scans. Provide the necessary functionality for the E-Commerce application to connect securely to the banking system, serving as the middleware communications module for payment card authorizations and settlement files. Feature a card swipe device (pin pad) that has the capability to accept any type of branded plastic card (credit, debit, and pre-paid). Feature a card swipe device (pin pad) that has the capability for a customer to enter manually the card number if the plastic card fails to be read by the device. Feature a card swipe device (pin pad) capable of accepting a signature. Feature a card swipe device (pin pad) that is "plug and play" (i.e., when installing or replacing these devices, no configuration or installation of software other than self-installing drivers should be required). Include the plastic card-swiping device (pin pad) as part of the total Gateway solution. Integrate the E-Commerce software to Vantiv for real-time authorization/funds capture at the point of sale. Provide the communication between the E-Commerce application and the pin pad device to initiate payment processing and to receive authorization. Utilize COTS software. It may be configured or extended, but these configurations and extensions must not interfere with ease of maintenance or upgrade of the Gateway Services or the E-Commerce and SSOARS applications. Not require that any software other than JAVA-based (JRE) applets/software be installed on SSA workstations. Automatically build a list of transactions that have been authorized and delivered, and create a settlement file. Transmit the settlement file to the processor and track the processor's acceptance. Have the capability to automatically settle credit card transactions periodically (minimum of daily) with Vantiv. Be able to process reversals, e.g., instances where the customer wishes to cancel the transaction, and for transactions that are timed out or are unsuccessful due to network issues, power failures, etc. The reversals must be performed in real-time with no manual intervention required. Store no plastic card account numbers anywhere on the SSA workstations or network. Handle recurring payments without storing any credit card information on the SSA side. Require no additional servers for the proposed solution. Be offered by a vendor who is an active Vantiv Certified Partner. Must be able to accept a 3DES key from Vantiv. Be willing to execute a Key Confidentiality Agreement with Vantiv. Summary: This is a sources sought announcement, and is a market survey for written documentation only. This is not a solicitation announcement for proposals and no contract will be awarded resulting directly from this announcement. No reimbursement will be made for any costs associated with providing information in response to this announcement or any follow-up information requests. No telephone calls will be accepted requesting a bid package or solicitation. There is no bid package or solicitation. This synopsis is for planning purposes only and is NOT to be construed as a commitment by the Government. Responses to this sources sought/market research notice will be used by the Government to make appropriate acquisition decisions. All interested sources must respond to future solicitation announcements separately from responses to this market survey. Interested sources that believe they have the ability to provide the items and perform the services listed above should submit a detailed statement of their capabilities in writing to Monica M. Yankle, Contract Specialist. INCLUDE IN YOUR RESPONSE your Company's Business Size Standard, i.e. Large, Small Business, or any of the sub-categories, e.g. 8(a), HUBZone, SDB, SDVOSB, Women-Owned, Other (Specify). Responses must be sent electronically via email to Monica.yankle@ssa.gov. Include "SSA-RFI-13-SERS in the e-mail subject line. No telephone responses will be accepted. Responses must be received by 12:00 p.m. EDT on 1/24/13.
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/spg/SSA/DCFIAM/OAG/SSA-13-SERS/listing.html)
- Place of Performance
- Address: Social Security Administration, East Low Rise Bldg., 6401 Security Blvd., Baltimore, Maryland, 21235, United States
- Zip Code: 21235
- Zip Code: 21235
- Record
- SN02968325-W 20130119/130117235149-438ffa07e926a2195f8679b4648b9092 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |