Qoin (Gateway) Release 4.3.10 — MID Display Accuracy Across Billing & Reports + Replay Scheduler & API Stability

🐛 Bug Fixes

Full MID Now Displayed Correctly Across All Billing & Reports Pages QOIN-1027

What was wrong: For merchants on BINs 478929 and 424832, the Merchant ID (MID) was being displayed without its leading 9271 prefix across six Billing and Reports pages. This meant the MID shown on those pages did not match the MID in Admin → Merchants — causing confusion during reconciliation and billing review.

This fix completes the MID correction work that began in Release 4.3.8 (QOIN-826), which previously corrected the Failed Batches page. All remaining affected pages have now been corrected in this release.

Pages fixed in this release:

• Reports → Global Settlement Report — QOIN-1028
• Billing → ACH Returns — QOIN-1029
• Billing → Billing Reconciliation — QOIN-1030
• Billing → Refund Billing — QOIN-1031
• Billing → Refund Report — QOIN-1032
• International → International Settlement Report — QOIN-1033

What’s fixed: All six pages now display the full, correct MID including the 9271 prefix — consistent with Admin → Merchants. No other BINs or MIDs are affected.

Before

After

⚡ Improvements

Customers API Redeployment — Latest DLL & Optimized Logging QOIN-1101

What this does: The Customers API has been redeployed with the latest build to eliminate a version drift issue where an outdated DLL was still running in production — causing potential inconsistencies between what was developed in 4.3.9 and what was actually active.

What’s included in this redeployment:

• Latest DLL applied — all 4.3.9 logging optimizations and PCI-DSS compliance fixes are now fully active across all environments (Dev, UAT, Production).
• Verbose request/response payload logging removed from production logs.
• Sensitive card data (card_number, expiration_mmyy) confirmed absent from all log outputs.
• Log file size reduction (~80–90%) now fully realized in production.

Replay Scheduler — Race Condition Fix for In-Flight Transactions QOIN-1103

What was wrong: The Replay Scheduler runs every 60 minutes to detect and replay any missing transactions. However, the stored procedure it uses (creditcard_rpt_GetMissingTransactions) had a replay window buffer of only 5 minutes — meaning transactions still being processed when the scheduler ran could be incorrectly identified as “missing” and queued for replay. This caused race conditions and repeated duplicate-key violation errors in the transactions table.

What’s fixed: The replay buffer has been increased from 5 minutes → 60 minutes, aligning the window with the scheduler’s actual hourly run interval. Each scheduler run now covers exactly the previous hour with no overlap into in-flight transactions:

• Before: Run at 11:00 AM → scanned back 24 hours, included transactions from 10:55 AM still in flight.
• After: Run at 11:00 AM → covers 9:00 AM → 10:00 AM exactly. Run at 12:00 PM → covers 10:00 AM → 11:00 AM. Clean, non-overlapping windows with no race condition.

Input validation has also been added — if @LastMinutes is zero or negative, the procedure now raises an error instead of silently returning empty results. This is a database stored procedure change only — no schema migration, no UI changes.