Vendor Payments (M-Pesa & Bank) — Assessment

It leaves the tenant's own M-Pesa shortcode directly to the vendor; vendor payments are non-custodial and unrelated to AWRA subscription billing It leaves AWRA's platform M-Pesa account, the same one used to collect subscriptions It leaves an AWRA pooled float and is reconciled against the tenant weekly It is deducted from the tenant's next AWRA subscription invoice as a credit

M-Pesa B2B, with the PO number embedded as the account reference so the vendor can reconcile A Paystack transfer, because paybills can only be paid from a Paystack wallet A manual record, because paybills cannot be paid programmatically M-Pesa B2C, with the vendor's phone number as the reference

Nothing — transfers always succeed because they use the same key as card collection The tenant's Paystack wallet balance, blocking the transfer if funds are short rather than letting it fail silently The PO's approval date, because transfers expire 24 hours after approval The vendor's phone number, because transfers are sent over M-Pesa under the hood

Mark it successful, since a timeout usually means the vendor was paid Delete the transaction so it does not clutter the dashboard, then start over Mark it failed and immediately re-send, since a timeout always means the money did not move Treat it as still pending (not failed) and check the dashboard for the final status before re-sending

The M-Pesa security credential is stored once at setup and reused unchanged on every payout A draft or cancelled PO cannot be paid because the approved-PO guard is enforced server-side A repeated provider callback cannot double-post, because each transaction is idempotent on a unique provider + external id Paystack vendor webhooks are HMAC-verified against the raw body using the tenant's own secret key