RFP No. Doc2269316678 Addendum 1.pdf

Procurement Services City Operations City of Portland, Oregon

@PortlandGov portlandgov

PortlandORGov

July 31, 2026

ADDENDUM NO. 1

RFP No. Doc2269316678

FOR

Merchant Services and Payment Gateway Services

Bids or Proposals Due: August 17, 2026, 4:00 p.m. Pacific Time

This Addendum provides changes to the specifications for the above-entitled project to be considered by each respondent. This Addendum shall be included within the proposal. Any changes made by this Addendum to said specifications offset only the portion of the words or paragraphs specifically mentioned herein, and the balance of the specifications remain in full force. It is the responsibility of all respondents to conform to this addendum.

This Addendum shall respond to inquiries received.

The following Inquiries were received regarding RFP Doc2246180914 Project Information Packet, section Merchant Services and Payment Gateway Overview and 3.2 Channels of Payment Acceptance:

1. What languages do you need for your IVR; anything other than English and Spanish?

Response: We currently need only English and Spanish. We want the ability to add Russian, simple Chinese and Vietnamese in the future.

2. How many monthly transactions do you expect to process via the IVR channel (a high-level estimate is acceptable)?

Response: Highest in 2025 was 8,000 transactions in a month.

3. What payment types do you want to accept via IVR (e.g., ACH/eCHeck, debit card, credit card)?

Response: ACH, Debit and Credit Card.

4. Do you plan to ask your payers to cover the cost of transactions by enforcing a service fee?

Does the City plan to manage the service fee or will it be managed by the proposer/vendor or a combination of both (depending on the division)?

Sylvester Donelson, Jr. Tracy Warren Raymond C. Lee III Chief Procurement Officer Deputy City Administrator Chief Administrative Officer https://twitter.com/PortlandGov https://www.instagram.com/PortlandGov/ https://www.facebook.com/PortlandORGov

Response: The use of service fees varies by division and payment application. The City of Portland generally uses a vendor managed model. For example, Water Bureau customers who use a credit or debit card to pay their utility charges online, by phone, or through autopay pay a processing fee. These fees are managed by the vendor.

However, any cost that will be passed on to the payor must be reviewed and approved by the City of Portland to ensure compliance with our policies.

5. Would you send us an account master file transmission to validate and process payments within the IVR system?

Response: Further clarification of this question may be needed. Currently, our payment processing vendor has real-time API integration with our Customer Information System to provide account validation, account balance and payment posting.

6. Do you use a standard IVR script or do you require customized scripting?

Response: Standard scripting is acceptable if it allows a representative to transfer a customer to the IVR to make a PCI compliant payment and once completed, the customer to be transferred back to the originating representative.

7. Question: The RFP requires that the proposer confirm it is an acquiring bank that is a Qualified Depository for Public Funds under ORS 295, or a processor partnered with such an acquiring bank.

Proposer seeks clarification on the intended scope of this requirement as applied to a payment processing arrangement.

ORS 295 governs the collateralization of public funds on deposit at a depository institution.

That is, funds held at rest at a bank or credit union. In a payment processing model, funds collected on behalf of the City are in transit through the processing network and are never held as a deposit with the processor or its banking partners. The processor does not take possession of or custody over the funds in a manner that constitutes a "deposit" as defined under ORS 295.001(10), which requires a bank or credit union with an Oregon presence as the holder of funds at rest.

Under this reading, ORS 295's qualified depository requirements would be satisfied not by the payment processor's banking relationships, but by the City's own receiving/payout bank, the institution where settled funds are deposited within a City defined period and ultimately held, being a qualified depository under ORS 295 and listed with the Oregon State Treasurer's Public Funds Collateralization Program.

Please confirm: Is the City's intent that the ORS 295 qualified depository requirement applies to (a) the payment processor or its acquiring bank relationships, or (b) the City's own bank account where settled funds are actually deposited and held at rest??

Response: The City of Portland has historically received same-day ledger credit and next-day collected funds settlement on Merchant Services transactions that are transmitted by a certain deadline (batch settlement) each day. It is our expectation that these settlements will occur in a bank account with a financial institution that is an Oregon Qualified Public Depository.

From the City of Portland’s perspective, we need to ensure that Public Funds are protected against loss at all times throughout the Merchant Services processing cycle.

Therefore, funds need to be clearly held in the name and under the Tax ID number for the City of Portland. This is generally accomplished by having the City of Portland as the “Merchant of Record” on the transaction. If a respondent is proposing an alternative arrangement, then the City would clearly need to understand what would likely occur in the event of bankruptcy or another adverse financial event. The funds would need to be clearly earmarked, partitioned or segregated in a manner which makes clear that the public funds in transit through the payment processing system belong to the City of Portland and not the processor, acquiring bank, Independent Sales Organization or other third-party.

Payments Integration

8. To accurately scope project management and stakeholder alignment, how many distinct City bureaus manage the in-scope systems? We could identify about eight distinct bureaus from the RFP documents. Is there a centralized steering committee (e.g., within Treasury or BTS) that holds ultimate authority to provide unified sign-off on requirements and UAT, or will sign-off be required individually by each bureau?

Response: 16 bureaus are presently within the defined scope. A centralized authority is in place for overall governance; Treasury will provide the unified sign-off on requirements and User Acceptance Testing. During implementation, we will coordinate directly with each individual bureau and their respective technical staff to ensure successful execution.

9. For Online Portals: Do they redirect users to a Hosted Payment Page (HPP), use an embedded iframe, or make direct server-to-server API calls?

Response: Mostly Hosted Payment Page (HPP) with the exception of parking mobile app and the Revenue Division’s online taxpayer payment portal.

10. Point-of-Sale (POS): Are the physical terminals semi-integrated (where terminals communicate directly with the gateway via cloud/network and post a status message back to the register) or fully integrated (where the City's POS software must ingest the transaction payload from the terminal and transmit it to the gateway)?

Response: The City uses fully integrated terminals provided by our current vendor.

11. How many physical POS terminals are currently deployed, and across how many distinct physical locations? For the rollout, is the vendor expected to perform on-site physical installation, unboxing, and network configuration, or will City IT staff handle the physical deployment of the shipped hardware?

Response: Approximately 228 POS terminals are deployed across roughly 220 locations. The vendor is not expected to perform any onsite physical installation activities.

12. Given the City's use of Point-to-Point Encryption (P2PE), do the fully integrated POS applications pass the encrypted payloads directly to the gateway via standard APIs, or do they rely on localized middleware/device drivers to route the data?

Response: Fully integrated POS P2PE within the terminals directly to our payment processor.

13. IVR/Phone Payments: Is the IVR logic managed by a third-party telecom vendor that makes

API calls to the payment gateway, or is the IVR system natively hosted and provided by the incumbent gateway (NIC Services)?

Response: The IVR is part of the services provided by our current payment processing provider, a hosted solution with API integration.

14. For Mobile Applications: Given that mobile payments are currently managed via a Hosted

Mobile Parking Payment System, does the City own the application codebase to swap in new SDKs, or is the City reliant on the third-party vendors? Will these vendors embed the new gateway's native mobile SDKs, or rely on backend APIs to pass mobile wallet payloads? Are they contractually committed to completing this by Q1 2027?

Response: Yes, we use the following third-party partners. (Please see Page 5, Project Information Packet).

a) Passport Inc (Parking Kitty) - Parking Meter App

b) Flowbird (Recently acquired by Arrive) - presently using the following solutions:

i) Cale America Inc. – Parking Pay Stations

ii) Passport Labs, Inc. - Hosted Mobile Parking Payment System

The City of Portland is currently using a backend API and we are expecting to continue using this method.

15. Recurring Billing: Where does the recurring schedule logic live? Do the source systems manage the schedule and trigger individual tokenized transactions, or is the recurring schedule managed entirely within the gateway itself?

Response: The recurring schedule logic generally resides in the source system.

Customers enroll in the service, and the invoices are then paid on their due date which is provided by the source system. Reoccurring payments are posted daily via API integration. Some invoice amounts can vary each month, so the source system would need to instruct the payment system when and how much to charge each time.

16. Is there existing centralized middleware? Does the City currently use an Enterprise Service

Bus (ESB) or API Gateway (e.g., MuleSoft, Boomi, Apigee) that connects these in-scope systems to the current gateway, or are these point-to-point connections?

Response: Point-to-point connections.

17. API Readiness: Of the in-scope systems listed, how many currently have modern, accessible APIs (REST/SOAP) for payment integration? Are there any legacy systems that require flat-file SFTP drops or custom middleware?

Response: We may be misunderstanding the question. The City expects the payment gateway to provide the API. The in-scope systems will use the provided API for payment integration. SFTP drops are currently only used by the City’s system of record (SAP) to ingest data about completed payment transactions for some payment services.

18. Do all in-scope systems mentioned have stable, accessible Sandbox/QA environments that

Slalom can use to conduct End-to-End (E2E) integration testing with Stripe’s test environment?

Response: We may be misunderstanding the question. Generally, most of the systems have a Sandbox/QA environment for testing purposes. However, we would need to confirm details about these test environments with each Bureau at the time of implementation.

19. Will the City facilitate introductions and access to sandbox environments for these third-party vendors, or is the proposer expected to manage those vendor relationships directly?

Response: The City will facilitate introductions and access.

20. Who owns the code/configuration for the in-scope systems? For systems that require configuration changes to point to Stripe, will City of Portland IT/BTS staff make those changes, will the 3rd-party vendor do it, or is the proposer expected to have access to configure those systems?

Response: This will vary by payment application. The configuration changes will either be made by City staff or the 3rd party vendor who is providing the system. However, the provider(s) who are selected through this RFP will be expected to collaborate and support the implementation of services in accordance with a mutually agreed upon schedule.

21. Are the third-party vendors contractually aligned? If third-party vendors need to do development work to integrate with the new gateway, are they currently contracted and available to complete this work before Q1 2027?

Response: Yes, the contracts generally require vendors to comply with City Policy which mandates that all payment methods and banking services are approved by the City Treasurer. We are hopeful that development work will be limited as most of the existing systems use a backend API integration to connect to a gateway provider. The implementation schedule will be prioritized based upon various priorities and contract expirations etc.

22. The RFP states a preference for Single Sign-On (SSO) via Microsoft Entra. Are all the in-scope systems currently integrated with Entra, or will user provisioning need to be handled system-by-system?

Response: The preference for MS Entra SSO is regarding access to any back-end administrative system provided by the payment gateway. For example, a system used to view transactional data, view/run reports, and/or manage refunds, etc.

23. Are any of these in-scope systems hosted on-premises behind City firewalls requiring secure VPNs, IP allow listing, or specific network configurations to communicate with Stripe?

Response: Yes, some of our systems will fall into this category.

Process Flows & Reconciliation

24. How does the current end-of-day reconciliation process work? How much manual effort is currently required by the Treasury team to reconcile funds against the SAP ERP 6.0 system?

Response: The payment gateway provider automatically sends both the daily batch total report and the detailed transaction report to each bureau or office’s merchant services administrator via email. These administrators reconcile the funds received per the daily batch report against the day’s deposit totals loaded to bank reconciliation accounts in SAP daily.

25. What is the exact format required for the SAP flat file extract? Is it a standard format (e.g., BAI2, standard CSV), or does the City use a heavily customized SAP ingest process?

Response: It depends on applications, the city uses CSV, XLSX, TXT and PDF files. We are open to BAI or other types of files if beneficial for the City of Portland.

26. Real-time vs. Batch: Do the existing system integrations currently require real-time transaction postbacks, or do they rely on end-of-day batch file extracts to update customer accounts?

Response: While financial reconciliation uses daily batch files, most systems receive a real-time postback with payment data so that they can record that information internally.

27. How are chargebacks and downgrades handled today? Does the City have a centralized team for dispute resolution, or is this decentralized across the different bureaus?

Response: Chargebacks and disputes are handled by each Bureau. Treasury is monitoring Downgrades.

28. How are refunds and voids processed today? Do City staff log directly into the source systems to issue refunds, or do they log into the payment gateway portal directly to issue refunds?

Response: For internal control purposes, Bureau staff log into the payment gateway portal directly to issue refunds.

Data Migration, Transition & Reporting

29. Token/Card Migration: Does the City currently vault/store recurring payment data (tokens or cards-on-file) with the incumbent gateway or processor? If so, will they support a secure token migration to Stripe, or will citizens be required to re-enter their payment methods?

Response: The City’s current payment gateway provider does not store payment data for recurring payments. However, some Bureaus use third party software (source systems) with recurring schedule logic. Customers enroll in the service, and the invoices are then paid on their due date which is provided by the source system. These systems generally using a backend API to access the payment processor or they send payment files directly to the processor on behalf of the City of Portland.

30. Phased Rollout vs. Big Bang: Given the Q1 2027 hard deadline for the Payment Gateway migration, is the City open to a phased rollout (bureau by bureau) or is a big bang cutover required for all systems simultaneously?

Response: Our preference is a Phased Rollout; the city will prioritize the order in which each Bureau application will migrate to a new solution.

31. The RFP requests Custom reporting and dashboard functionality. Does the City expect these to be configured solely within the payment gateway’s native UI, or is the vendor expected to build custom Business Intelligence dashboards (e.g., PowerBI, Tableau) requiring integration with a City data warehouse?

Response: No. The city is open to exploring all available options.

Transaction Volume & Financial Data

32. What are the average and peak transaction volumes? Are there specific seasonality spikes

(e.g., property tax deadlines, utility billing cycles, parking peaks) that the integration must handle without throttling?

Response: Please see attachment 1. It was provided for the participants who attended the mandatory pre-bid meeting on 06/17/2026. If you attended, please contact Mark Ariza, Procurement Analyst at mark.ariza@portlandoregon.gov to obtain a copy of this document.

33. What is the breakdown of payment types? What percentage of transactions are Credit, Debit, ACH/eCheck (if applicable in current context), or Mobile Wallet (if applicable in current context)?

Response: Please see attachment 1A.

34. The RFP states the approximate total annual transaction volume as 11 million with a total annual payment volume of $550 million. Can you provide a breakup of the transaction and volume data by bureau?

Response: Please see attachment 1A.

Training

35. To scope the onboarding and training effort, approximately how many City staff will require system training, and across how many distinct bureaus? Does the City prefer a Train-the- Trainer model, or direct training led by the vendor? Are trainings expected to be virtual or on-site?

mailto:mark.ariza@portlandoregon.gov

Response: Some form of training will be required for several hundred uses across 16 Bureaus. Our preference is a direct training model led by the vendor. Virtual training is acceptable.

The City acknowledges that more inquiries were submitted and not responded to. Due to an abundant amount submitted, any inquiries not responded to in this addendum will be responded to in the next addendum.

Please direct all questions and concerns to Mark Ariza, Procurement Analyst at 503-823- 1885 or mark.ariza@portlandoregon.gov.

End of Addendum

Sylvester Donelson Chief Procurement Officer sd:ma mailto:mark.ariza@portlandoregon.gov