Vendor Payments (M-Pesa & Bank) — Assessment

1. A cashier pays a supplier for an approved PO by M-Pesa B2C. Whose account does the money come from, and how does this relate to the business's AWRA subscription?

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

2. A vendor is a registered company that gives you a paybill number to pay into. Which method fits, and what does AWRA put in the account reference?

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

3. Before initiating a Paystack bank transfer to a vendor, what does AWRA check and why?

The workspace's Paystack wallet balance, blocking the transfer if funds are short rather than letting it fail silently Nothing — transfers always succeed because they use the same key as card collection 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

4. A B2C payment times out — Daraja returns no definitive result. How does AWRA treat it, and what should the cashier do?

Mark it successful, since a timeout usually means the vendor was paid Mark it failed and immediately re-send, since a timeout always means the money did not move Treat the outcome as unknown and check the M-Pesa statement before re-sending, since the money may have gone Delete the transaction so it does not clutter the dashboard, then start over

5. Everything below is true about how AWRA protects vendor payments EXCEPT:

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

Your details for the certificate

This is the name that will appear on your certificate.

Full name

Email

We email your result to this address with a link to confirm it is yours. If you are signed in, or once you confirm, the administrators of an organisation this email belongs to on AWRA OpsHub can see your attempts and certificate. Your name is as you type it here; only the email is confirmed.

Send me AWRA’s monthly email: new guides, product updates and courses. Unsubscribe anytime.

Graded server-side. No peeking at answers in the page source.