Skip to content

v3.18.46 — PesaPal reconciliation safety net

Choose a tag to compare

@frisoftltd frisoftltd released this 05 Oct 14:15
· 1 commit to main since this release

Confirmed live on nyarutarama: DD-00231/DD-00232 were paid at PesaPal and the IPN reached /wc-api/wc_pesapal_gateway/ (200, four hits for DD-00232 over 17 minutes), but the orders stayed pending_payment/unpaid — a transient failure at payment time, with no retry.

Reconciliation cron — new 5-minute WP-Cron sweep (dd_pesapal_reconcile_sweep, via a new dd_five_minutes cron_schedules interval) re-checks up to 20 unpaid PesaPal orders (tracking id present, created ≤48h ago) per run against PesaPal's get_transaction_status(). COMPLETED routes through the existing promote_pesapal_order(); FAILED/REVERSED mark the row failed via the same conditional-UPDATE pattern the IPN handler already uses. Every check logs DD_DIAG:.

Atomic promotion — audited, already correct (pre-existing conditional UPDATE ... WHERE payment_status='unpaid', notifications only fire on an actual row flip). No change needed.

Admin recheck button — confirmed already shipped (v3.16.1's "🔄 Recheck Payment"). No change needed.

List badge — PesaPal orders now get the same green "Paid" badge MoMo orders get, once payment_status='paid'.

Customer redirect — root-caused: the callback_url and the registered IPN URL are the identical /wc-api/wc_pesapal_gateway/, so the customer's browser (redirected there inside the in-drawer payment iframe after paying) was hitting the same handler as PesaPal's server-to-server IPN and getting the raw IPN JSON echoed back. Fixed: a browser landing there now gets a small "Payment received" HTML message instead of JSON, detected via a User-Agent heuristic (logged as DD_DIAG: IPN request UA= so a real test payment can confirm it). Reservations module has the same shared-URL structure for deposit payments and was not touched — flagged for a follow-up.

Credential logging — searched the full plugin source for anything printing PesaPal's consumer/secret key into the debug log; found nothing in this repo. The leak reported previously must originate in the separate WooCommerce PesaPal gateway plugin (not part of this codebase) or WooCommerce core's own gateway debug logging — flagged, not fixed here.