OCFO Team Meeting Notes on DOCC Integration

OCFO Team Meeting Notes

Object ID and Access

The meeting starts with a discussion about object IDs, specifically for the OCFO team.
Access for Bob and Dan regarding the DOCC (presumably a system or application) is being checked.

DOCC and TLA Consolidation Proposal

Pam is asked about updates on the DOCC ticket and any movement.
The primary focus is on consolidating TLAs (Three Letter Acronyms, likely referring to different systems or applications) and awaiting a proposal from Pam and Dale's team.
Pam's team has concluded that because the DOB (Department of Buildings) is not fully live and all TLAs are not in production, they can merge into the DOCC, which is currently in production.
Pam will distribute a high-level document outlining the steps involved.
The document needs DOB review to confirm feasibility, followed by a formal agreement and signature.

Payment Types and Front-End Considerations

A spreadsheet will be provided to detail payment types for each front-end (Acela, Wall Check, Certify, OB in-house).
A suggestion is made to use more descriptive names for payment types on the agent dashboard (e.g., "Permit Acela" instead of "Permit 1") to improve user recognition.

Scope of the Proposal

Clarification is sought on whether the proposal covers work items for DOB review and analysis, the consolidation of TLAs, or just payment-related activities.
Pam clarifies that it involves both sides; the input from each front-end and the output to the back-end will be in identical formats.
No email notifications will be sent to end customers; real-time notifications will be sent to the initiating applications, which will then notify customers.
It is technically feasible.

Regression Testing and System Impacts

Full regression testing is recommended when new sources are added to DOCC to ensure no impact on existing systems.
Real-time payment notifications and SSO (Single Sign-On) parameters should remain consistent.
Clarify permit descriptions for the agent dashboard to be specific to the source (e.g., "Acela permit description").

Notifications and User Groups

Notifications are sent differently based on the source (e.g., CERT vs. Wall Check).
User groups will need to be combined into DOCC, with a limitation of one person per user group.
It's noted that combining all agencies into one agent dashboard could solve the problem of users like Colonel, who supports multiple agencies, being limited to one login.
A list of additional user groups and object ID mappings is needed for each new source.

SSH Keys and Credentials

SSH keys and credentials will need to be applied to DOCC.
DOBA and DOBC will continue to be supported independently until the agreement is signed.

Integration and Timing

The goal is to integrate all TLAs into one.
The documentation provided by Pam will be reviewed to understand confirmation requirements.
DOCC is ready to go, but the consolidation of TLAs is causing a delay.

ACH Holds and Communication

ACH hold issues have been resolved.
External communication needs to be planned before DOCC is released to the public.

Adapter Issue and Dependencies

An issue regarding the adapter and integrating VelociMo is discussed.
It's clarified that DOBC can move forward independently, even before Acela is finished, as long as the final product is one TLA.
Initial understanding was that DOBC couldn't go live until DOBA (Acela) was live, but this is no longer the case if they can all be integrated into one TLA (DOCC).

Agency's Requirements and Approach

The agency wants one TLA for a cleaner program, especially with the addition of digital wallets.
The payments can go live independently as different pieces as long as at the end of the day, there is one TLA that works together.
The recommendation is to stick with DOCC (as live payments have already been made) and add DOBC and DOBA into it.

Convenience Fees and Communication Strategy

To avoid multiple communications with a phased approach, it's suggested to launch DOBA with a larger stake of payments (50-60%) instead of DOCC initially, but the team is okay if they want to utilize the already tested payments.

Dashboard Renaming

Since DOCC will be the primary agent dashboard, renaming it to the DOB dashboard is suggested and the DOB logo stays as central reference.

Required Documents and Excel Sheet

Hugo will distribute a Word document and an Excel spreadsheet for review.
The spreadsheet requires information on payment types by front end.

Drop Dead Date

The target completion date is September 30th, with the hope of finishing sooner.
The aim is to have one TLA (DOCC) accepting ACH, credit card, and debit payments.
There are four front ends: Acela, Certified, Wall Check, and the DOB custom.
Payment types will pass into one IFrame.

IFrame Clarification

It is clarified that the "IFrame" refers to the middle piece within the frame, not the outer frame itself.
The payment types should be made more descriptive on the agent dashboard for easier identification.
The description and payment type codes would make SSO stream be simpler.

Account Number Validation

Double entry validation for account numbers for ACH payments is confirmed to be included in the IFrame and stays consistent.

Unique Payment Type Identification

If the same payment type is sent across multiple front-end applications, it needs to be uniquely annotated.

SSO Parameters and Data Fields

Data fields passed in the SSO from the front ends need to be identical (with the exception of the payment type code and the post-back URL).
Each source will need to send a redirect back to the application in the SSO stream.
Customer name and the parent number are two different example to take acount for the same parameter.

Real-Time Notifications and Endpoints

The endpoints of listeners for post-back notifications can be different for each front end (Accela, Certify, Wall Check webhooks), to manage their processes.
The postbacks will go to the endpoints of listeners.
The request format for all front ends will be identical.

Payment Receipt Page and Meds

The payment receipt page will redirect to the front end's applications.
Initially two meds were being combined, now there are two med accounts, one for DOB and one for DLCP.
Those processes come into action using payment type recognition.

IP Whitelisting and User Groups

IPs and domains from each of the front-ends need to be white-listed.
The additional user groups that need to be actioned also comes into place.
There's a question of whether to segregate user groups to only give them certain treatment types.
Since one person can only belong to one group, there may need to be more groups than originally expected.

SSO SAML and SSH Keys

SSO SAML needs to work to access DOCC.
SSH keys from the different sources need to be added.
DOCC has multiple posting processes in place, in order to have a central platform, teams will need to adapt reporting procedures to DOCC processes.

Email Notifications and Regression Testing

All DOB front ends will be sending email notifications to customers; Paymentus will not be sending any emails.
The District of Columbia will be required to do full regression testing for each front end when each front end is added to the TLA DOCC.
The agent and the agent dashboard will be labeled DC, DOB, or whatever is needed.

Early Warning Services (GIAK)

The team requests documentation relating to early waring services and its uses.
This process is initiated for ACH transactions.
There will also be added a real time check to see if bank account qualifies. The consumer will also receive notification if a new bank is needed.
It remains to have any testing cases that the team responsible to test the implementation can try in a safe environment.