This phase focuses on the detailed technical work of connecting Do Not Pay Connect to your application architecture and business logic.
Integration Architecture
Review our comprehensive integration guide and SDK documentation to understand the complete integration architecture. Focus on authentication flows, request formation, response parsing, error handling, and performance optimization. Our SDKs encapsulate many complex integration details, but understanding the underlying architecture helps you troubleshoot issues and optimize performance.
Complete Integration Guide & SDK Documentation (Coming soon)
Data Input Mapping
Identify how Do Not Pay Connect input requirements map to data elements in your source systems. You'll need to extract required fields like name, date of birth, Tax Identification Number (TIN), and address from your relevant system (e.g., payment or grants management system). Document your data mapping to support future maintenance and audit requirements.
Some source systems store data in formats that require transformation before submission. Plan for data normalization, validation, and cleansing to ensure high-quality input that produces reliable match results.
Response Ingestion
Design your response ingestion process to capture and store Do Not Pay Connect results in your system. Consider how response data will be persisted, how it will be associated with payment or award records, and how long it will be retained. Your ingestion process should handle both match and non-match results, partial data scenarios, and system errors gracefully.
Many agencies create a dedicated integration database table to store raw responses before business logic processing. This approach supports audit requirements and enables response reprocessing if business rules change.
Display Configuration
Determine how Do Not Pay Connect results will be displayed to end users within your application interface. Your display should present match results clearly, highlight critical information requiring attention, and provide context for decision-making.
Consider how different user roles will interact with results. Caseworkers may need summary information with drill-down capability, while audit staff require complete detail views. Supervisor dashboards might show aggregate statistics across multiple cases.
Business Rules & Outcomes
Define the business rules that determine how your system responds to different Do Not Pay Connect results. Will certain matches automatically block the next action? Do specific conditions trigger secondary or supervisory review? How will your system handle many concurrent matches from different data sources? Do you want to use Connect’s default composite risk level (e.g., 1001) or create your own using Connect’s domain-level codes?
Document these decision rules clearly because they represent critical program policy implementation. Your outcome logic should be configurable rather than hard-coded, allowing policy adjustments without code changes.
Plan how you'll report outcome data back to Do Not Pay Connect for program measurement and evaluation. This feedback loop helps improve the service and demonstrates your program's payment integrity impact and compliance with mandates.
Outcomes Reporting Guide (Coming soon)
Build Priority Use Case
Using staged test data provided by Do Not Pay Connect, develop a complete working implementation of your highest-priority use case in your non-production environment. This end-to-end integration should include data input, API call or file generation, response processing, user display, and outcome determination.
Building one complete use case provides a validated pattern for remaining integrations and uncovers integration challenges while they're still easy to address. This iterative approach reduces risk and demonstrates value to stakeholders early in the project.
Soft Launch Testing
If your agency has completed necessary privacy and security agreements, and you're developing in an environment rated for PII data, you may request production soft-launch access. Soft launch allows you to test your highest-priority use case with real production data while limiting scope to a controlled user group or subset of transactions.
Soft launch testing validates that your integration performs correctly with real-world data complexity, volumes, and timing. This phase often reveals edge cases or data quality issues not apparent in synthetic QA testing. Plan for an iterative refinement period based on soft launch findings before full production deployment.
Build Additional Use Cases
After successfully completing your priority use case, repeat the build and test process for remaining priority workflows. Many technical components can be reused across use cases, so subsequent implementations typically proceed faster than the initial development.
Consider dependencies between use cases. Some agencies implement use cases sequentially while others develop multiple use cases in parallel. Choose an approach that matches your development capacity and program timelines.
Go-Live Decision
Before requesting full production access, validate that all necessary components are in place: technical integration is complete and tested, business rules are documented and approved, users are trained, security reviews are passed, and agency agreements are executed.
Conduct a formal go-live readiness review with key stakeholders to confirm deployment readiness. Document any open issues and mitigation plans. Most agencies plan a phased production rollout rather than enabling all use cases simultaneously, reducing risk and allowing refinement based on initial production experience.