Description
Summary # EPD Dual-MID Payment Integration — Finalization, Testing & Operational Controls ## Project Overview The EPD payment gateway integration has now progressed to the point where EPD has added and configured the second MID (ZEN/Maverick) directly within the EPD payment gateway. EPD has also successfully tested the additional MID and configured the gateway for dual-MID processing/routing. Because EPD is now handling the underlying gateway-level MID integration and routing, this project is **not intended to recreate a custom dual-gateway architecture or duplicate functionality that EPD already provides**. Instead, the purpose of this project is to review the existing integration, verify that the two-MID configuration is functioning correctly, and implement the operational safeguards, transaction visibility, reporting, testing, and administrative controls necessary to safely operate two MIDs through the EPD gateway. --- # Milestone 1 — Existing Integration Review & Full End-to-End Testing ### Approximately 20% of total project Before making significant changes to the existing integration, the developer should first review the current implementation and EPD's current dual-MID configuration. Perform a full end-to-end test of **both MIDs through the EPD payment gateway**, including: * Authorization * Capture * Refund * Void, where applicable * Failed/declined transaction * Confirmation that each transaction is correctly associated with the MID that originated the transaction * Confirmation that transaction IDs/gateway references are correctly recorded * Confirmation that the website/order system correctly receives and records the resulting transaction status Testing should verify the complete flow from the website/order system through EPD and back to the website/order records. The developer should document: 1. What is already functioning correctly. 2. What functionality EPD is providing natively. 3. What functionality is already present in the existing application. 4. What additional development is actually required. 5. Any limitations imposed by the EPD API or gateway. **Important:** Do not rebuild functionality that is already being properly handled by EPD or the existing application. --- # Milestone 2 — Required Operational Controls & Integration Improvements ### Approximately 60% of total project Based on the results of Milestone 1, implement only the functionality that is actually required to make the system production-ready. ## 1. Transaction & MID Tracking Every transaction should have sufficient information recorded to determine: * Order/customer reference * Transaction amount * Date/time * Transaction ID * Gateway/reference ID where available * MID used for the transaction * Authorization status * Capture status * Refund/void status * Relevant gateway response or error information The primary objective is that we can look at any transaction later and clearly determine **which MID processed it and what happened to the transaction**. ## 2. Refund & Void Safeguards Refund and void functionality should ensure that transactions remain associated with their originating MID. Requirements: * A refund should be submitted through the appropriate MID associated with the original transaction. * A void should similarly be associated with the originating transaction/MID where supported. * The system should prevent a refund greater than the original transaction amount. * Refunds and voids should be logged. * The system should prevent accidental duplicate or excessive refunds where reasonably possible. * Administrative refund functionality should be appropriately restricted. The goal is to ensure that a transaction processed through MID A cannot inadvertently be refunded through MID B. ## 3. MID-Specific Processing Volume Tracking Implement basic tracking of processing volume by MID. The system should be capable of showing: * Current monthly volume for each MID * Number of transactions processed by each MID * Remaining amount relative to a configured monthly threshold * Percentage of the configured limit currently being utilized Thresholds should be configurable rather than hard-coded so they can be changed later if processor limits change. ## 4. Processing Threshold Alerts Implement alerts when a MID approaches its configured monthly processing threshold. Ideally, the system should support configurable warning levels, such as: * Warning threshold * Higher-risk/near-limit threshold * Maximum configured threshold For example, a MID could generate alerts at 80%, 90%, and 100% of its configured monthly volume. The exact thresholds should be configurable. The purpose is to give us advance warning before approaching a processor's monthly volume limit. ## 5. Administrative MID Controls Where technically feasible, provide basic administrative controls for the two MIDs. At minimum, the administrator should be able to see whether each MID is currently: * Enabled * Disabled * Available/operational * Experiencing errors If technically possible, provide an administrative ability to disable a MID from being used for new transactions without affecting historical transaction records. This should **not** duplicate or interfere with EPD's own gateway routing controls. ## 6. Emergency MID Disable Capability Provide a simple administrative mechanism to prevent new transactions from being directed to a particular MID if there is an urgent processor/gateway issue. For example: * EPD MID: Enabled * ZEN/Maverick MID: Enabled If one processor instructs us to stop processing through its MID, the administrator should be able to disable that MID at the application level where technically possible. Historical transactions must remain intact, and refunds/transaction management should continue to reference the originating MID. ## 7. Transaction Audit Log Provide a reliable transaction audit trail showing important payment activity. The audit information should ideally include: * Transaction date/time * Order/reference number * Amount * MID * Transaction ID * Transaction status * Refund/void activity * Relevant gateway response * Administrative action, where applicable This does not need to be an elaborate analytics platform. The priority is having a reliable record that can be used for troubleshooting, processor inquiries, reconciliation, and internal auditing. ## 8. Error & Failure Monitoring Where practical, identify and log important gateway/payment failures, including: * Declined transactions * Gateway errors * Communication/API errors * Failed refunds * Failed voids * Unexpected MID/routing errors If practical, provide basic administrative visibility or alerts for unusual failures or significant increases in failed transactions. The objective is early detection rather than building an unnecessarily complicated monitoring system. --- # Important Scope Limitation The developer should **not** build a separate dual-gateway architecture, custom processor-routing system, or other functionality that duplicates what EPD is now providing. EPD is responsible for the underlying gateway and MID configuration/routing. The application should integrate cleanly with EPD and provide the necessary business-level controls and visibility around that integration. Similarly, **automatic retry/failover between MIDs should not be independently developed at this time** if EPD is implementing this functionality within its upcoming platform. If EPD later provides native automatic failover/retry functionality, the application should be designed so that it does not conflict with that functionality. --- # Milestone 3 — Final Production Testing, Documentation & Handoff ### Approximately 20% of total project After implementation is complete, perform a final production-readiness review. Confirm that: * Both MIDs can successfully process transactions through EPD. * Transactions are correctly recorded. * MID identification is accurate. * Refunds are correctly associated with originating transactions/MIDs. * Voids work correctly where applicable. * Failed transactions are handled appropriately. * Processing volume is tracked correctly. * Thresholds and alerts function correctly. * Administrative controls function correctly. * Audit records are being generated. * No functionality conflicts with EPD's gateway-level routing. ## Documentation Provide documentation covering: * How the two MIDs are configured within the application * How transactions are associated with their originating MID * How refunds and voids are handled * How processing volume is calculated * Where volume thresholds can be changed * How MID controls work * How transaction logs can be reviewed * How to troubleshoot common payment failures * Any limitations imposed by the EPD gateway/API Please also identify any functionality that could not be implemented because EPD's API/gateway does not expose the necessary capability. --- # Overall Project Objective The goal is to leave the payment system in a **stable, production-ready state for operating two MIDs through the EPD payment gateway**, without unnecessarily duplicating functionality that EPD already provides. The priority is: **1. Reliability** **2. Transaction traceability** **3. Correct refund/void handling** **4. MID visibility** **5. Processing-volume awareness** **6. Administrative control** **7. Error monitoring** **8. Thorough testing and documentation** Any additional features previously proposed should be evaluated against these objectives. Features that materially improve reliability, monitoring, security, reconciliation, or operational control are welcome. Features that simply duplicate EPD gateway functionality should be omitted. ## Milestone Structure * **Milestone 1: Existing Integration Review & End-to-End Testing — 20%** * **Milestone 2: Required Operational Controls & Integration Improvements — 60%** * **Milestone 3: Final Testing, Documentation & Handoff — 20%** The developer should provide a brief assessment after Milestone 1 confirming exactly what needs to be developed before proceeding with the majority of the implementation work.