Qoin (Gateway) Release 4.3.9 — Transaction Reliability & API Log Optimization
Release 4.3.9 is a stability and observability hardening release. It eliminates the risk of missing transactions caused by Redis timeout failures during settlement, and dramatically reduces Customers API log output (from ~1GB/day to under 50MB) — improving system performance, storage efficiency, and PCI-DSS compliance.
⚡ Improvements
Transaction Reliability — Timeout-Safe Persistence & Settlement Monitoring QOIN-1051
What this addresses: When a Redis timeout occurred during transaction processing, related records were not always saved correctly — causing transactions to go “missing” from the system even though they were authorized at the processor level. This was the root cause behind missing deposit incidents where merchant funds were not settled despite a successful authorization.
What’s been done:
- Atomic writes with timeout-safe retries — related transaction records are now committed together or rolled back safely. A single Redis timeout can no longer cause a partial or orphaned record to be left in the system.
- Real-time monitoring & alerting — alerts are now emitted when a timeout threshold is crossed so the operations team is notified before a settlement batch closes, allowing proactive reconciliation before merchants are impacted.
- Settlement verification — post-transaction checks now confirm that merchant-facing totals align with the amounts queued for settlement before the batch runs, catching any anomalies prior to batch close.
This is a long-term systemic fix — no manual intervention will be required for future timeout-induced record gaps. The platform will self-detect and alert on any timeout event during transaction processing going forward.
Replay Audit Report Notification Example

Customers API — Log Optimization, PCI-DSS Compliance & 31-Day Retention QOIN-1087
What was wrong: The Customers API was generating approximately ~1GB of log data per day, causing disk storage issues and posing an imminent risk in production environments. More critically, full customer request and response payloads — including raw card numbers (card_number) and expiration dates (expiration_mmyy) — were being written to log files in plain text, representing a direct PCI-DSS compliance risk.
What’s been fixed:
- Sensitive data fully removed from logs — raw card numbers and expiration dates no longer appear in any log file at any log level. This directly addresses the PCI-DSS compliance concern and aligns logging behavior with industry standards.
- Request/response payload logging demoted — full serialized request and response objects are no longer logged at Information level on every API call. Verbose payload inspection is available only at Debug level in controlled environments when explicitly needed.
- Slow request warnings retained — requests taking longer than 500ms still produce a Warning log with elapsed time, preserving performance monitoring capability without dumping the full payload.
- Error logging corrected — all command handlers now log
ExceptionTypeandExceptionMessageonly, eliminating duplicate stack trace logging that was inflating log file size and breaking structured log querying. - Header logging consolidated — multiple redundant per-request header log lines have been collapsed to a single Debug entry, removing approximately 5 log lines per API call.
- 31-day rolling log retention — log files are now automatically purged after 31 days. The previous configuration had no practical retention limit, resulting in effectively unlimited file accumulation over time.
Measured outcome in UAT:
- Log files reduced from ~1GB/day → ~179KB per session
- 80–90%+ sustained daily log size reduction
- All actionable Error and Warning signals are preserved — no diagnostic value is lost
- No card numbers or expiration dates in any log output — PCI-DSS compliant
Need Help?
If you have any questions about this update, our support team is here to help.