SANParks Tender: 5-Year Unified CP/CNP Payment Gateway Solution

Returnable Documents:

Payment Gateway Services Note: Physical payment terminals (PEDs) for Card Present transactions are provided by the acquiring bank, not the gateway service provider. The Service Provider is responsible for gateway software integration with these devices. ● Provision of a unified payment gateway platform that supports: o Card Present transactions (point-of-sale, front office, ticketing, kiosk, and mobile terminals). o Card Not Present transactions (website, mobile app, e-commerce, Wild Card programme, fundraising). ● Real-time transaction authorisation, settlement, refund, reversal, and reconciliation capabilities. ● Support for multi-acquirer connectivity. ● Compatibility with major card schemes (Visa, Mastercard, American Express, Diners Club and China Union Pay) and modern payment methods including but not limited to contactless/NFC (tap to pay), digital wallets (Apple Pay, Google Pay, Samsung Pay, etc.), QR-based payments (Zapper, SnapsСan, generic QR codes), instant EFT solutions (Ozow, PayFast, etc.), and USSD mobile payments where applicable. ● Service to service integrations – such as webhooks and callbacks supporting integrity of data and availability of services using integration server to server (payment gateway to SANParks or SANParks partner server and services, or SANParks and SANParks partner servers and services to the payment gateway/s) ● payment gateway services must be hosted on high availability servers, load balanced and scalable/redundant links with fixed IP ranges (to allow whitelisting of IP addresses required for the SANParks firewalls (Cloudflare/forti-waf) and any other SANParks WAF Systems Integration ● Integration with SANParks’ core tourism systems, including: o Reservation and Property Management System (for accommodation and activities). o Access Control and Ticketing Systems (for gate entry and park access). o SANParks’ public website and e-commerce portals. o The Wild Card Programme system and membership platform. o Travel Trade and External offices (Satellite) Reservations sales o Quick Pay (SANParks web portal for client payments) ● Provision of API-based integration (RESTful or equivalent), SDKs, and sandbox environments for development and testing. ● Support and Provision test payment cards for development and demonstration and testing (UAT/SIT) supporting payment of any amount and available at any time of the day. ● Implementation of real-time reporting and transaction data synchronisation between SANParks systems and the payment platform. Technical Performance Requirements The Service Provider must ensure that the payment gateway platform meets the following minimum technical performance standards to support SANParks' operations across all channels and locations. Transaction Processing Performance Measurement Methodology: All response times are measured from the moment the gateway receives the authorization request to the moment the response is returned to SANParks' merchant system. Authorization Response Times The gateway must process and return authorization responses within the following timeframes: Transaction Type Target Response Time Maximum Acceptable Card Present (POS/Terminal) ≤ 2 seconds (95th ≤ 5 seconds (99th percentile) percentile) Card Not Present ≤ 3 seconds (95th ≤ 7 seconds (99th percentile) (Web/Mobile) percentile) Contactless/NFC Payments ≤ 1 second (95th ≤ 3 seconds (99th percentile) percentile) Settlement Processing Batch Settlement Window: Daily settlements must be completed between 23:00 and 06:00 SAST Settlement Confirmation: Confirmation information must be available 1 hour after settlement Settlement Reconciliation: CSV (comma-delimited) reconciliation files generated at close of business day Failed Transaction Retry: Automatic retry mechanism for failed settlements with 3 attempts over 30- minute intervals (SUPPORTED BY WEBHOOKS OR CALLBACKS – SERVER TO SERVER INTEGRATION SUPPORT) Card Not Present Refund Processing Refunds on processed amounts Settled on the payment gateway Option only available to Finance Admin user accounts. Card Present Reversal Processing Same-Day Reversals: Processed within the same day before banking of requested submission System Throughput and Capacity Requirements Transaction Volume Capacity Estimated required minimum transaction volumes without performance degradation: Metric Minimum Requirement Peak Capacity (Holiday/Season) Transactions Per Second 50 TPS sustained 150 TPS burst capacity (TPS) Concurrent Transactions 500 simultaneous 1,500 simultaneous transactions transactions Daily Transaction Volume 100,000 transactions/day 300,000 transactions/day Monthly Transaction Volume 2,500,000 7,500,000 transactions/month transactions/month Scalability: The system must be able to scale to 200% of peak capacity within 48 hours notice to accommodate unexpected demand spikes. Concurrent User Capacity Concurrent POS/Terminal Devices: Minimum 250 devices processing simultaneously Concurrent API Calls: Minimum 100 API requests per second Administrative Users: Minimum 50 concurrent users accessing reporting dashboards Transaction Reporting Capacity to pull transaction reporting from 1 day to 12 months of reporting data, with filtering for: Merchant Account Payment Status Card Present or Not Present First 6 and Last 4 digits of Card Number Transaction Amount Transaction Date Reference Number Card Holder – on Name and/or Surname API Performance Requirements The payment gateway APIs must meet the following performance standards: API Function Response Time Timeout Rate Limit (5th %ile) Threshold Payment ≤ 2 seconds 10 seconds 100 req/sec Authorization Payment Capture ≤ 3 seconds 15 seconds 50 req/sec Refund Request ≤ 3 seconds 15 seconds 25 req/sec Transaction Status ≤ 500 milliseconds 5 seconds 200 req/sec Query Tokenization Request ≤ 1 second 5 seconds 100 req/sec Report Generation ≤ 5 seconds 30 seconds 10 req/min API Reliability and Error Handling API Availability: 99.9% uptime (measured monthly) Error Rate: < 0.5% of all API requests Retry Logic: Automatic retry with exponential backoff for transient failures Error Response Time: Error responses must be returned within 2 seconds API Documentation: Complete OpenAPI/Swagger documentation provided Webhook Delivery: Webhook notifications delivered within 30 seconds of event Reporting API: Support and cater for transaction reporting and transaction state poling and transaction checks (single or bulk) with support for transaction reporting from 1 day to 12 months of reporting data, with filtering for: Merchant Account Payment Status Card Present or Not Present Network and Infrastructure Performance (Refer Annexure for additional information) Network Latency Requirements Gateway-to-Acquirer Latency: ≤ 100 milliseconds average Gateway-to-SANParks Systems: ≤ 50 milliseconds average (within South Africa) Cross-Region Latency: ≤ 200 milliseconds (between SA data centers) Network Jitter: ≤ 10 milliseconds variation Bandwidth Requirements Minimum Internet Bandwidth: 100 Mbps dedicated (per data center) Peak Bandwidth Capacity: 500 Mbps burst capacity Network Redundancy: Dual ISP connections with automatic failover QoS Configuration: Payment traffic prioritized over other network traffic Database Performance Query Response Time: ≤ 100 milliseconds for transaction lookups Write Operations: ≤ 50 milliseconds for transaction commits Report Generation: Historical reports (1 year) generated within 30 seconds Database Replication Lag: ≤ 5 seconds between primary and replica databases Index Optimization: Automatic index optimization for transaction tables Reporting and Dashboard Performance Report Type Data Refresh Frequency Load Time Real-Time Transaction Every 30 seconds ≤ 10 seconds Dashboard Daily Reconciliation Daily at 08:00 SAST ≤ 35 seconds Report Custom Date Range On-demand ≤ 30 seconds Report Monthly Performance Monthly ≤ 15 seconds Report Transaction Search Real-time ≤ 7 seconds (any criteria) Dashboard Concurrency: Reporting dashboards must support minimum 50 concurrent users without performance degradation. Performance Monitoring and Reporting The Service Provider must implement comprehensive performance monitoring: Real-Time Monitoring: 24/7 automated monitoring of all performance metrics Performance Dashboards: Real-time performance dashboards accessible to SANParks Threshold Alerts: Automatic alerts when performance degrades below 80% of target Monthly Performance Reports: Detailed monthly reports showing performance against all SLAs Performance Trending: Historical trend analysis showing performance over time Proactive Optimization: Quarterly performance optimization reviews and recommendations Load Testing: Annual load testing demonstrating capacity to handle 200% of peak volumes Performance Baseline: Establish performance baseline within 30 days of go-live Performance Remediation: - If system performance falls below specified targets for 3 consecutive days, Service Provider must: Submit root cause analysis within 24 hours Provide remediation plan within 48 hours Implement fixes within 5 business days Demonstrate restored performance through testing Performance Testing Requirements The Service Provider must conduct comprehensive performance testing at the following intervals: 1. Before go-live: Complete performance testing and validation before production deployment 2. Annually thereafter: Annual performance testing to verify continued compliance with all performance standards 3. Major releases: As part of the change control process for major releases (see Section on Change Management) Performance testing must include:  Load testing at 100%, 150%, and 200% of expected peak transaction volumes  Stress testing to identify system breaking points  Endurance testing over 24-hour periods  API response time validation across all endpoints  Database performance and query optimization verification  Network latency and throughput testing Test Documentation: All performance test results must be documented and submitted to SANParks within 5 business days of test completion. Security and Compliance • Full and valid compliance with EMV, PCI DSS Level 1, and PCI P2PE latest standards. • Tokenisation of sensitive payment data and end-to-end encryption across all channels. • Support for 3D Secure 2.0 authentication for Card-Not-Present transactions.  Implementation of fraud monitoring tools (e.g., blacklisting, velocity checks, transaction screening). POPIA COMPLIANCE REQUIRMENTS In accordance with the Protection of Personal Information Act, 2013 (Act No. ), the Service Provider must demonstrate full compliance with all provisions relating to the processing of personal information. Payment transactions inherently involve the collection, storage, processing, and transmission of personal information, including sensitive financial data. Specific Compliance Requirements Lawful Processing and Data Minimisation The Service Provider must:  Process personal information only for the specific, explicitly defined, and lawful purpose of facilitating payment transactions for SANParks  Collect only the minimum personal information necessary to process payments  Not process personal information for secondary purposes without explicit consent  Provide a Data Processing Impact Assessment (DPIA) specific to the payment gateway solution Consent and Privacy Notices The Service Provider must:  Provide clear, plain-language privacy notices at all payment touchpoints (POS terminals, web checkout, mobile apps)  Make privacy notices available in English and at least one other official South African language  Clearly identify SANParks as the responsible party and the Service Provider as the operator  Specify data retention periods and include contact details for POPIA-related queries  Implement a consent management system that records what, when, and how consent was obtained Data Subject Rights The Service Provider must facilitate the following rights:  Right of Access: Provide customer information within 30 days in a structured, commonly used format  Right to Correction: Enable customers to correct inaccurate information within 7 days  Right to Deletion: Delete personal information upon request, subject to legal retention requirements  Right to Object: Provide opt-out mechanisms for direct marketing or automated decision-making  Maintain a data subject rights request log with response time tracking Data Security Measures Technical Safeguards:  End-to-end encryption (AES-256 or equivalent) for all payment data in transit and at rest  Tokenisation of Primary Account Numbers (PAN) immediately upon capture  Multi-factor authentication for all administrative access  Hardware security modules (HSM) for key management  Quarterly vulnerability scanning and penetration testing  Intrusion detection and prevention systems (IDS/IPS)  Encrypted backup and recovery procedures Organisational Safeguards:  Background checks for all personnel with access to payment systems  Annual POPIA and PCI DSS training for all relevant staff  Role-based access controls and segregation of duties  ISO 27001 certification (preferred)  Documented information security policies and procedures Data Breach Management The Service Provider must:  Implement 24/7 security monitoring to detect potential breaches  Conduct root cause analysis within 5 business days  Provide detailed breach reports including nature, extent, affected persons, and remediation measures  Maintain documented incident response procedures with annual breach simulation exercises Data Breach Notification Timeline In the event of a suspected or confirmed data breach, the Service Provider must adhere to the following notification timeline: Timeframe Action Recipient Requirement T+4 hours Initial notification SANParks Immediate notification upon of suspected becoming aware breach T+72 hours Formal breach Information Regulator As required by Section 22(1) notification of POPIA T+reasonable Data subject Affected individuals "As soon as reasonably period notification possible" where breach poses risk of harm Note: The "reasonable period" for notifying data subjects depends on the severity and nature of the breach, but must occur as soon as reasonably possible after the breach is confirmed and the extent of affected data subjects is determined. Data Residency and Cross-Border Transfers The Service Provider must:  Process and store all SANParks payment data within the Republic of South Africa, unless explicitly authorised  Where cross-border transfer is necessary (e.g., card scheme authorisation), ensure recipient is subject to adequate protection per Section 72(1) of POPIA  Notify SANParks in advance of any cross-border data flows  Implement appropriate safeguards (encryption, contractual protections)  Provide data residency confirmation, data flow diagrams, and cross-border transfer agreements (if applicable) Prohibited: Hosting or backing up SANParks payment data outside South Africa without prior written consent Third-Party and Sub-Processor Management The Service Provider must:  Maintain a comprehensive register of all sub-processors (acquiring banks, card schemes, infrastructure providers)  Ensure all sub-processors comply with POPIA and sign data processing agreements  Notify SANParks of sub-processor changes with 30 days' notice  Remain fully liable for any POPIA violations by sub-processors  Provide current sub-processor register, template agreements, and compliance certificates. Data Retention and Destruction Retention Periods:  Transaction data: Minimum 5 years (Companies Act and Tax Administration Act requirement)  CVV: Must never be stored post-authorisation  PAN: Must be tokenised immediately  Audit logs: Minimum 12 months (24 months for forensic investigations) Destruction Requirements:  Irreversible destruction or anonymisation at end of retention period  Secure deletion methods (cryptographic erasure, physical destruction, overwriting)  Certificate of destruction provided to SANParks upon contract termination  Destruction of all personal information within 30 days of contract end (except where legal retention applies) Accountability and Governance The Service Provider must:  Designate an Information Officer responsible for POPIA compliance  Provide contact details of the Information Officer and deputy  Conduct annual POPIA compliance audits by independent third party  Submit quarterly compliance reports to SANParks including: o Data processing activities summary o Security incidents and breaches (if any) o Data subject rights requests and resolution o Sub-processor changes o Training completion rates o Audit findings and remediation status Hardware and Devices (Card Present) Responsibility: Physical payment terminals (Payment Entry Devices - PEDs) are provided and maintained by the acquiring bank, not the gateway service provider. Service Provider Responsibilities: Physical Payment Entry Devices (PEDs) are owned, supplied, maintained, and supported exclusively by the acquiring bank. This includes all aspects of hardware provisioning, physical deployment, repair, replacement, Return Merchandise Authorization (RMA), firmware updates initiated by the bank, and end- of-life management. The Service Provider is not responsible for the physical PEDs or any hardware-related logistics. However, the Service Provider must ensure seamless software-level integration with the PEDs provided by the acquiring bank. This includes: 1. Supporting remote device management and configuration control from the gateway side (e.g., terminal status monitoring, transaction routing, and parameter settings via acquirer APIs); 2. Coordinating with the acquiring bank on key injection and encryption key lifecycle management, as facilitated through the bank’s secure systems; 3. Ensuring compatibility with NFC/contactless, mobile wallet, and EMV chip transactions as supported by the bank-provided devices; 4. Providing technical troubleshooting support limited to gateway-to-device communication issues, and escalating hardware faults to the acquiring bank; 5. Collaborating with the acquiring bank during device rollout, replacement, or RMA processes to validate end-to-end transaction flows and system interoperability. Clarification: Any activity requiring physical access to the PED, hardware diagnostics, logistics (including shipping, repairs, or replacements), or firmware updates pushed directly by the bank remains the sole responsibility of the acquiring bank. The Service Provider shall not be held liable for delays, failures, or costs arising from PED hardware issues outside its control. Reporting, Analytics, and Reconciliation ● Provision of a unified reporting dashboard accessible to authorised SANParks staff. ● Ability to generate real-time and scheduled reports segmented by park, channel, device, or transaction type in single transaction to 12 months of transactions or more if required. ● Automated reconciliation with SANParks’ financial systems using unique transaction IDs. ● Audit logs and data retention aligned with SANParks’ governance and PFMA requirements. Service Management and Support ● 24/7 helpdesk and technical support. ● Defined Service Level Agreements (SLAs) covering uptime, incident response, and resolution times. ● Comprehensive training and knowledge transfer for up to 50 SANParks staff across Finance, Reservations, and Wild Card departments, including hands-on sessions on gateway administration, transaction reporting, reconciliation, and issue escalation. Regular system updates, compliance maintenance, and advisory on new payment technologies and regulatory changes Change Management Process All changes to the payment gateway system, including system updates, feature enhancements, configuration modifications, security patches, and integration changes, must follow the formal SANParks change control process to ensure minimal disruption to operations and maintain system integrity. Change Request Procedures Change Initiation:  All change requests must be submitted in writing through the designated change management system or via email to the nominated technical contact  Change requests must include: detailed description of the change, business justification, affected systems/components, affected and informed stakeholders and clients, estimated impact on operations, and proposed implementation timeline, roll-back procedures and responsible and affected departments and stakeholders/clients Change Classification:  Emergency Changes: Critical security patches or fixes for system-down scenarios requiring immediate implementation (within 24 hours)  Standard Changes: Routine updates, minor enhancements, or non-critical fixes (5-10 business days notice)  Major Changes: Significant system upgrades, new feature implementations, or architectural changes (minimum 30 business days notice) Change Approval and Assessment Impact Assessment:  The service provider must conduct and document a comprehensive impact assessment for all proposed changes  Assessment must include: technical impact, security implications, integration dependencies, user experience effects, rollback procedures, and required testing scope Approval Requirements:  Emergency changes require approval from SANParks ICT and notification to Finance and Tourism departments  Standard changes require approval from SANParks Project Manager or Technical Lead  Major Changes - Approval Process: o CAB review and approval required o Performance testing completion o Backup and Rollback plan o SANParks sign-off o Scheduled implementation window Testing and Implementation Testing Requirements:  All changes must be tested in a non-production environment before deployment to production  Test plans must include: functional testing, integration testing, security testing, performance testing, and user acceptance testing (UAT) where applicable  SANParks reserves the right to participate in UAT for major changes Implementation Windows:  Standard and major changes must be implemented during agreed maintenance windows (typically outside business hours: 10 PM - 6 AM SAST, Monday to Thursday (SANPARKS CAB is scheduled for every TUESDAY of the week). No changes to be implemented (unless emergency) over weekends – FRIDAY TO SUNDAY))  Emergency changes may be implemented immediately with appropriate communication  The service provider must provide a detailed implementation plan including: step-by-step procedures, rollback plan, estimated downtime, and success criteria Communication and Documentation Pre-Implementation Communication:  The service provider must notify SANParks of all planned changes at least as per the notice periods specified in Change Classification  Notifications must include: change description, implementation date and time, expected duration, potential impact on services, and contact information for support Post-Implementation Documentation:  Following each change, the service provider must provide: change completion report, any deviations from the plan, issues encountered and resolutions, post-implementation validation results, and updated system documentation Version Control:  All system versions must be clearly documented and tracked  Release notes must be provided for each version update, detailing all changes, enhancements, and fixes Rollback Procedures  The service provider must have documented rollback procedures for all changes  Rollback must be possible within 2 hours for standard changes and 4 hours for major changes  In the event of failed implementation, the system must be restored to its previous stable state  The service provider must document the reason for rollback and provide a revised implementation plan Change Restrictions Blackout Periods:  No changes are permitted during SANParks peak operational periods without explicit written approval from SANParks  Peak periods include: public holidays, school holidays, and any periods designated by SANParks as high-traffic periods Unauthorized Changes:  The service provider must not implement any changes to the production environment without prior approval from SANParks  Unauthorized changes may result in penalties as outlined in the Service Level Agreement Change Tracking and Reporting  The service provider must maintain a comprehensive change log accessible to SANParks  Monthly change reports must be submitted including: all changes implemented, success/failure rates, incidents related to changes, and outstanding change requests  Quarterly reviews of the change management process must be conducted with SANParks stakeholders Service Level Agreements (SLAs) The Service Provider must commit to the following minimum service levels: System Availability and Uptime Gateway Platform Availability: 99.9% uptime per calendar month (excluding scheduled maintenance) Maximum Scheduled Downtime: 4 hours per month, communicated 7 days in advance Maximum Unscheduled Downtime: 30 minutes per month Measurement: Calculated from gateway availability logs, measured 24/7/365 Active monitoring and proactive risk and service management systems and support. Transaction Processing Performance Card Present Authorization Response Time: ≤ 3 seconds for 95% of transactions Card Not Present Authorization Response Time: ≤ 5 seconds for 95% of transactions Settlement Processing: Daily batch settlements completed by 06:00 SAST Transaction Success Rate: ≥ 98.5% (excluding declines from issuing bank) Incident Response and Resolution The Service Provider must classify incidents according to the following severity levels and respond accordingly: Severity Level Definition Response Time Resolution Time Critical (P1) Complete system outage; no 15 minutes 2 hours transactions processing; revenue- impacting High (P2) Major functionality degraded; 1 hour 4 hours affecting multiple sites/channels; workaround not available Medium (P3) Partial functionality impaired; 4 hours 8 hours affecting single site/channel; workaround available Low (P4) Minor issue; informational; feature 8 hours 5 business days request Support Availability Helpdesk Operating Hours: 24 hours per day, 7 days per week, 365 days per year Support Channels: Telephone (toll-free), email, web portal, Ticketing and Issue tracking systems and SMS alerts First-Line Response: Immediate acknowledgment via ticketing system Escalation Path: Clear escalation to second and third-line support within defined timeframes Reporting and Reconciliation Real-time Transaction Reporting: Available within 5 minutes of transaction completion Daily Reconciliation Reports: Available by 08:00 SAST daily Monthly Performance Reports: Delivered within 5 business days of month-end Report Accuracy: 99.9% accuracy in transaction reconciliation Reports available for export and view (via Admin dashboard) from 1 day to 12 months. Hardware Support (Card Present Devices) - Provided by the Acquiring Bank The acquiring bank must provide all hardware devices required for card present transactions. These devices must meet the technical specifications and operational requirements necessary to ensure successful transaction processing across all SANParks facilities. Security and Compliance PCI DSS Compliance: Maintain Level 1 certification throughout contract period Security Incident Notification: Within 4 hours of detection Vulnerability Patching: Critical patches applied within 48 hours, non-critical within 7 days Compliance Audit Reports: Quarterly submission to SANParks SLA Reporting and Governance Monthly SLA Reports: Detailed performance against all metrics, submitted by 10th of following month Quarterly Business Reviews: Face-to-face or virtual review with SANParks management Service Credits: For failure to meet SLAs, Service Provider will issue credits as follows: Gateway Availability < 99.99%: 5% monthly fee credit per 0.1% below target P1 Incidents exceeding resolution time: 10% monthly fee credit per incident P2 Incidents exceeding resolution time: 5% monthly fee credit per incident Exclusions from SLA Measurements Scheduled maintenance windows (with proper notification) Force majeure events Issues caused by SANParks' infrastructure, network, or systems Third-party service failures beyond Service Provider's control (e.g., card scheme outages, acquirer bank downtime). Strategic Advisory ● Ongoing guidance on payment innovation, digital transformation, and regulatory compliance (e.g., PCI, EMVCo, PASA). ● Recommendations for process improvement, cost optimisation, and emerging payment solutions relevant to SANParks. ROLES AND RESPONSIBILITIES The following table outlines the division of responsibilities between SANParks and the appointed Service Provider throughout the contract lifecycle: Service Provider’s Activity/Deliverable SANParks’ Responsibility Responsibility Develop, propose, and System Design and Solution Review, provide input, and document a detailed system Architecture approve design documentation. design and integration plan. Develop, configure, and test Provide access to SANParks’ Integration Scoping and integrations with SANParks’ development teams, APIs, and Development tourism, POS, and e-commerce test environments. systems. Configure payment gateway, Approve configuration System Setup and Configuration merchant profiles, and parameters and test data setup. transaction routing. Facilitate and support system Testing and User Acceptance Conduct UAT and provide and integration testing; resolve (UAT) written sign-off for acceptance. defects. Implement production Approve deployment plan and Deployment and Go-Live environment and support go-live schedule go-live activities. activities.