Payment Processing System

The Vendor is required to provide payment processing functions by presenting two distinct sets of requirements, one for the payment gateway, and one for the id (one card) and POS transaction processing.
- Payment gateway functional goals
1. The payment gateway must:
• Be a turnkey installation with configuration and support originating from one source;
• Be easy and fast to install without placing a demand on citadel resources;
• Integrate in real time with Ellucian banner, including mobile solutions;
• Be validated for both PCI DSS and pa-DSS (p2pe) compliance;
• Be scalable to incorporate future system expansion;
• Be flexible enough to communicate with our bank’s recommended credit card processor, currently Fiserv, and to change processors in the future;
• Payment gateway capable of processing payments on campus, including transactions made by electronic checks, credit cards, and debit cards;
• Have a proven track record with institutions of higher education;
• Service for online payments by check.
• A convenience fee model for online credit and debit card payments.
2. The citadel considers the following to be the most important requirements of this project:
• Ease of installation/implementation, with expandability to add solutions/modules in the future as needs require;
• Excellent onsite training during the initial implementation and training available for future needs (new employees, added solutions, and system upgrades/updates);
• Excellent customer service that partners with the citadel to provide the best possible electronic payment experience for our students;
- Payment gateway technical preferences
1. Payment gateway must provide an interface with banner for data entry into:
• The citadel general ledger
• Accounts receivable
2. User authentication solution shall integrate with our IDP, preferably azure ad, SAML 2.0, LDAP.
• Solution shall allow for automated account provisioning and de-provisioning for administrative and user access.
• The solution must support two-factor authentication.
3. Integration and automation with cardinal (parking management), handshake, photo shelter, campus ESP, slate
• Solution shall allow integration via APIs to facilitate third-party applications (event registration software, parking software, etc.) and citadel developed applications with the web-based payment processing service.
• APIs shall facilitate data and security integration.
4. Solution shall allow the citadel to securely integrate custom developed shopping carts and applications with a web-based payment processing service.
5. A defined process for recovering data in the event of a disaster with access to the cloud-based database that allows us to correct errors or make changes.
• The cloud-based application service shall provide 99% up time availability and fail-over support in case of service outages.
• Provide for disaster recovery via geographic diversity
6. Data security
• Data at rest, particularly personally identifiable information, must be encrypted
• Data in motion must be encrypted
• Data backups shall be encrypted
7. Access to data
• Data via API for local reporting purposes.
• Export/recover data, if any, at the end of the contract
8. Compliancy
• Entire payment acceptance and transaction should occur within the solution’s PCI compliant infrastructure via p2pe.
• Service shall be FERPA compliant
• Web application shall support vanity URLs
- Real-time preferences
• The electronic payment system must update the student’s account in real time.
• Post payment transactions in real time.
• Present students and authorized users with the current account balance.
• Ability to pull current account balances (but not necessarily all detailed account activity) for activity posted on the student account since the billing date, in real time.