DHCD ACH Payment Integration — Comprehensive Notes

ACH and DHCD Payment Integration — Comprehensive Notes

Summary of Goals and Scope

• Goal: achieve a smooth ACH implementation based on prior discussions and team readiness. The plan is to leverage existing knowledge within the team to move forward efficiently.
• Consideration: decide whether to create two separate documents—one for ACH and one for DHCD—to avoid confusion when sharing with DHCD versus internal ACH discussions.
• Context: ACH has a long history in this environment; the team expects a straightforward file-based workflow but recognizes that the handling and interpretation of responses will require new processes.
• Key questions: how to structure the ACH file, where to drop the file, how often to drop it, and how to interpret the downstream responses (successes vs. failures).

ACH File Handling and Operations

• File pipeline concept:
  • You provide a file to a destination; the recipient processes it and returns specifications of the expected format and drop location.
  • They will tell us the file structure, the target drop location, and the drop cadence.
• Cadence and reporting:
  • Initial assumption: drop once per overnight cycle; the next morning, a report is produced detailing what happened to the file.
  • Example: after processing, a report might indicate that $88$ items passed and $12$ had trouble.
  • The existence of a “response handling” workflow is new: building and managing responses to the ACH submissions needs to be designed.
• Practical steps:
  • Build the ACH file in-house and drop it to the agreed location.
  • Implement the workflow to parse and respond to ACH processing results (success, reject reasons, etc.).
• Significance: the file drop and result handling are core to the ACH integration; the processing logic and error handling will drive the backlog and require strong testing.

DHCD: Current State, Requirements, and Next Steps

• DHCD engagement:
  • There was a meeting with POCs from DHCD; a requirements document was created under the ACH payment module showing current transactions and future functionalities.
  • The document has been in circulation for over two months; updates may be needed if processes or requirements have changed.
  • Next steps include touching base with DHCD to confirm any changes and update the notes accordingly.
• Focus and scope:
  • The initial focus is on getting DHCD up and running with ACH; this is treated as a complete project with the aim of launching for that agency first.
  • There is an overarching goal to eventually expand to other agencies, but the DHCD focus is the current priority.
• Current workflow considerations at DHCD:
  • They currently process payments via paper checks and envelopes, potentially with manual data entry.
  • They use Emphasis (a third-party application) for monitoring fees and related processes; Emphasis is not fully understood by the on-call team, particularly how it integrates with ACH and bank entry workflows.
  • They report monitoring fees for businesses and related activities; the workflows for invoicing, payment, and posting need to be clarified.
• Questions to answer with DHCD:
  • How does the current check workflow look (who opens checks, where checks are stored, how data is captured, etc.)?
  • How do envelopes and checks feed into their back-office system (and how do we align that with ours) without reworking existing applications?
  • What exactly does Emphasis monitor or support beyond the monitoring fees—does it support ACH, or only monitoring? Does Emphasis capture bank information or process checks, or both?
  • Do DHCD staff use a separate system (e.g., Quickbase) to track agency-wide payment status? If so, how do we integrate with that? (They mentioned Quickbase.)
  • What is the end-to-end flow from a citizen initiating a payment to the ledger showing “paid”? Where do errors end up and how are they tracked?
• Potential architecture questions:
  • If Emphasis is the core workflow tool, can we leverage any ACH capabilities within Emphasis to input bank data and post payments, or will we need a light integration externally?
  • Are there plans for an electronic payment portal for DHCD (e.g., a link to pay electronically), and how would that interact with current workflows?
• Discussion points about resources and funding:
  • Dan indicated there is funding for this work, but resource allocation (developers, time) should be planned with proper governance.
  • There is concern about the cost of hours spent in extensive stakeholder meetings; the team aims to keep scope manageable and aligned to deliverables.
• Action items for DHCD discussions:
  • Identify who to include in future meetings (names and roles).
  • Confirm the latest DHCD BRD (Business Requirements Document) and share it for review.
  • Gather updates on any changes to current processes or future functionalities DHCD expects.
  • Consider a demonstration of their current DHCD screens/payments workflow to better understand their process.

Systems and Tools: What We Know and What We Need to Confirm

• Emphasis (third-party system):
  • Currently used to monitor payments (monetization of the monitoring fee) and track related workflows; details on how it stores or interacts with payments are unclear.
  • Need to determine whether Emphasis supports ACH entry/conversion or if it is purely for monitoring. Also need to assess how data from Emphasis can be surfaced or integrated with the back office.
• Quickbase (agency-wide tracking):
  • They use Quickbase to track payments and the broader workflow; integration points with ACH and DHCD processes need to be clarified.
• DC Web Forms (self-service payments):
  • A lightweight payment page used historically for simple payments (e.g., DPW dumpsters) where users can enter payment info and trigger a payment process.
  • Features:
  • Simple user-facing forms (credit card and ACH options via a single portal).
  • Backend workflow behind the scenes to manage the payment and send emails: confirmation to payer and notification to staff.
  • Build options:
  • We can reuse or adapt DC Web Forms as a minimal, independent solution (a stopgap before deeper integration).
• Paymentus (the newer gateway):
  • Paymentus is moving into the space and has its own version to collect payments; there is a desire to maintain an independent path that can operate outside of Paymentus.
  • The plan is to consider a simple external link path (like DC Web Forms) that can either point to Paymentus or operate independently depending on the agency’s needs.
• DC Web Forms vs Paymentus integration idea:
  • The team is weighing whether to rebuild DC Web Forms to route through Paymentus or maintain a separate flow that can also accommodate ACH in addition to credit cards.
  • The aim is to ensure no single vendor is a lock-in and to provide flexible paths for agencies to pay via CC or ACH.
• Future concepts and samples:
  • A “portal” that aggregates and loads various fees, with a link sent to users to pay electronically (credit card or ACH).
  • The DC web forms approach provides a simple mechanism that can be deployed quickly while a more robust, integrated solution is developed.
• Example sources and references:
  • DC web forms implementation used by DPW for recycling bin payments (one-page form, simple credit card flow).
  • A hosted example of a simple pay link that offers CC or ACH options.
  • A Pay.gov-like concept exists in federal contexts and can inform design questions about what to capture and how to present to users.

Payment Flows, User Experience, and Technical Options

• Credit card flow (via DC Web Forms or similar):
  • User clicks a payment link, enters amount and card details, and the payment is authorized in real time.
  • Immediate feedback is provided to the user (Yes/No approval) and a receipt is generated.
• ACH flow (via DC Web Forms or similar):
  • User can select ACH; the system collects bank routing and account numbers and initiates ACH; involves backend logic for validation and settlement.
  • ACH may require overnight processing with a later reconciliation receipt; there may be basic checks on bank account validity, with final settlement after a day or two.
  • The flow is more complex due to bank validation and possible returns; the system should provide status updates and error handling for failed/invalid entries.
• The native difference between CC and ACH:
  • CC: real-time, immediate authorization response; user gets instant confirmation.
  • ACH: asynchronous processing; status and potential issues resolved after processing window; requires robust follow-up messaging.
• Simple, independent option: DC Web Forms prototype
  • A straightforward page where users can choose CC or ACH and complete the transaction with minimal back-end friction.
  • After payment, emails are sent to the payer and the staff, confirming the action.
• Possible Roadmap (short term vs. long term):
  • Short term: deploy DC Web Forms-based portal for DHCD with both CC and ACH options; learn from real usage to shape a more integrated solution.
  • Medium term: align with Paymentus in a way that preserves agency independence (e.g., a simple “pay link” that can route to either agent or vendor depending on the agency choice).
  • Long term: build a fully integrated, agency-wide payments hub with unified fee naming conventions, program mappings, and standardized data exchange formats.

Fees, Programs, and Revenue Tracking

• Fee variety and reporting:
  • DHCD and other agencies may charge multiple fees (e.g., monitoring fees, program fees, utility review fees).
  • There may be dozens of programs; each program could have its own fee structure, requiring a clear naming convention and consistent taxonomy.
• Example figures discussed:
  • Typical monitoring fee amounts range from $102.50$ to $500.00$ per item or per program as reported in the discussion.
  • The volume for the monitoring workflow is around $300$ to $400$ transactions per year.
  • There are a few related numbers for context, such as individual item values and the number of transactions processed annually.
• Fee naming and coding:
  • A standardized naming convention is needed so fees are unambiguous across agencies (e.g., a common code per program, with sub-codes for specific fees).
  • The goal is to align fee categorization with the CFO/Treasury policy and ensure accurate revenue recognition.
• Mapping to back-end systems:
  • Align with Quickbase and other agency-tracking systems so that fee payments link directly to the appropriate program and record in the back-end.
  • Avoid trying to rewrite existing back-end workflows; instead, fit into the current processes and extend them where necessary.
• What we need from stakeholders:
  • A complete list of programs and associated fees, including any special cases (utilities, loan programs, etc.).
  • The end-to-end payment workflow (who opens checks, how they are scanned/entered, where the data lands, and how it ties to invoices and receipts).
  • Policies on bad checks and retry processes, as well as how the CFO or treasury handles failed payments.

Data Governance, Policy Implications, and Practical Considerations

• Bad checks and enforcement:
  • Understanding current CFO/Treasury policies on bad checks is essential to design a compliant workflow.
  • Some agencies route checks to Treasury, then perform collection actions; others may have in-house workflows for bad checks.
• Policy alignment and cross-agency consistency:
  • If a new system introduces new data fields (e.g., fee codes, program IDs), ensure consistency across agencies to enable unified reporting and export.
• Data integrity and security:
  • Access control via Okta or similar identity providers; ensure proper authentication for staff involved in payment processing.
  • Ensure PCI compliance for card data handling if CC flows are exposed through DC Web Forms or similar portals.
• Operational risk and cost management:
  • The scheduling and governance of stakeholder meetings can incur significant hours; keep the scope tight and focused on delivering testable milestones.
  • Prioritize early demonstrations or pilots to validate flows and reduce risk before heavy investments in development.

Meeting Cadence, Roles, and Next Steps

• Immediate next steps:
  • Schedule and run DHCD-focused sessions starting next week; expand to ACH stakeholders as needed.
  • Prepare a questions list for the meetings to systematically capture current state, desired outcomes, and constraints.
  • Identify who to invite to ACH and DHCD meetings; collect names and roles for invited participants.
  • Revisit the DHCD BRD to confirm current state and any new requirements since the last discussion.
• Meeting logistics:
  • Plan for two sessions per week: one to include DHCD stakeholders and one to address ACH-team questions; aim for one-hour sessions to manage scope.
  • Consider a live demo with the DHCD team to show their current screens and workflows, to better tailor the integration design.
• Deliverables:
  • Two parallel BRDs: one for ACH integration (file format, drop location, cadence, validation, and response handling) and one for DHCD (current state, future functionalities, and path to deployment).
  • A consolidated list of questions to drive follow-up meetings and ensure all stakeholders are aligned.
  • A plan for a pilot or test drop in the ACH environment to verify the end-to-end flow before broader roll-out.
• Resource planning and funding:
  • Confirm availability and cost of developers, whether funded via Octo, OCFO, or DHCD allocations.
  • Align resource planning with the scope of work and the pace of meetings to avoid excessive cycles.

Key Concepts, Terms, and References

• Key terms:
  • ACH: Automated Clearing House, electronic funds transfer between banks.
  • DHCD: Department of Housing and Community Development.
  • Emphasis: third-party application used for monitoring and possibly some workflow components.
  • Quickbase: agency-wide tracking system used to monitor payments.
  • DC Web Forms: simple, independent payment page that can direct users to CC or ACH payment flows.
  • Paymentus: newer payment gateway/platform that some agencies are moving toward.
  • Okta: identity provider used for securing access (mentioned in context of forms).
  • BRD: Business Requirements Document, used to capture requirements for projects.
• Financial and processing references (LaTeX-formatted where applicable):
  • ACH processing costs per transaction: $0.25 \le \text{cost per ACH} \le 0.75$ dollars.
  • Example DHCD fee and transaction figures: $102.50$ to $500.00$ per item; $300$ to $400$ transactions per year.
  • Reporting and error examples: 88 successes, 12 failures (represented as $88$ and $12$).
• Real-world scenarios and analogies:
  • DC Web Forms is like a lightweight storefront where a payer clicks a link, selects CC or ACH, and completes payment with email receipts to payer and staff.
  • Paymentus and DC Web Forms can be designed to provide a similar user experience but with different back-end integration footprints.

Final Thoughts and Real-World Relevance

• This work sits at the intersection of software integration, government workflow, and citizen experience. The aim is to reduce reliance on paper processes and enable reliable, auditable electronic payments with clear, documented workflows.
• The conversations highlight the importance of:
  • Clear governance around where data flows, who owns which part of the process, and how failures are handled.
  • A pragmatic approach: start with simple, independent solutions (like DC Web Forms) to validate flows before committing to heavier, more complex integrations.
  • Consistent terminology and fee categorization across agencies to enable scalable deployment and reporting.

References for Follow-Up (to Share in Next Docs)

• DC Web Forms examples and the pay.dc.gov concept for CC and ACH flows.
• Paymentus documentation and examples illustrating a “payments app” integration pattern and the data you need to capture.
• A sample DC Wallet/portal example or a simple pay link to illustrate how a payer experiences a payment flow.

Action Items (Immediate)

• Compile and share the latest DHCD BRD; confirm any changes since the last meeting.
• Prepare a two-document approach: ACH-focused BRD and DHCD-focused BRD to avoid confusion between audiences.
• Gather DHCD stakeholder names and ACH team contacts to invite to the next round of meetings.
• Create a draft ACH file spec (fields, formats, and drop locations) and a test drop workflow for internal validation.
• Arrange a DHCD demo session to show their current workflow and identify where our integration can plug in.
• Collect a list of all DHCD programs and their fees, plus the policy on bad checks and treasury routing, to inform naming conventions and policy alignment.
• Share a couple of DC Web Forms samples (including the simple pay.dc.gov link) to illustrate potential implementation paths to stakeholders.