To add Flutterwave to WooCommerce, install the official plugin, connect the appropriate account environment, configure its payment notifications and test the resulting order workflow. Before releasing an order, establish that the transaction reference, payment status, currency and paid total match what the order expects. A checkout success screen alone is insufficient payment evidence.
Flutterwave’s WooCommerce setup guide documents the plugin route. Its separate transaction verification guide explains the checks before giving a customer value. These describe software behaviour and account setup; they do not confirm that a particular Zambian merchant is eligible for every Flutterwave product or payment method.
What should you confirm before installing the plugin?
Identify the business account that will receive the payments and the person authorised to complete onboarding. Flutterwave says the live account must have completed onboarding and submitted the required documents. A plugin installation does not complete those commercial checks.
Keep the test store and account environment explicit in the implementation brief. Record the plugin name, source and version, current checkout type and any other extension that can affect order status. Use a private testing arrangement that cannot send real fulfilment requests or customer messages by mistake.
The official setup guide directs the operator to install and activate the Flutterwave WooCommerce plugin, then enable it under WooCommerce settings and payments. Follow the current interface rather than copying screenshots blindly. If the installed version differs from the guide, resolve that discrepancy before entering live credentials or advertising a working payment option.
How should the account and notification settings connect?
Flutterwave documents obtaining API keys from the merchant dashboard and adding the plugin-generated webhook URL to the provider dashboard. These settings connect the storefront to the account and allow payment events to reach the store. Treat secret values as credentials, not debugging content to paste into public tickets.
Record which environment each setting belongs to. A test order should be traceable to the expected test account and should not unexpectedly create a live collection. If the account, keys or endpoint environment is unclear, pause that test case rather than trying successive combinations on the public checkout.
The help article uses loose language about a webhook hash and encryption. This draft does not repeat an assurance that a shared secret encrypts the entire communication. Establish the verification mechanism applicable to the installed plugin and current webhook documentation. Configuration presence alone does not establish that incoming events are authenticated correctly.
Which payment checks matter before fulfilment?
Flutterwave’s verification guide calls for matching the generated transaction reference, confirming successful transaction status, checking the expected currency and comparing the paid total against the expected total. It also distinguishes the overall response from fields inside the transaction data.
That distinction matters when investigating an apparent success. An API request that successfully retrieved a transaction is not the same proposition as a transaction that successfully paid the order. The implementation needs to read the relevant transaction fields and match the result to the right local order. A familiar customer name is not an adequate substitute for matching the reference.
The guide identifies the transaction ID as the value used for verification. Keep it alongside the order reference and verification outcome. Avoid copying the full returned customer record into a general-purpose log when the operator only needs a transaction identifier and a reason for the decision. Verification requirements.
What should the test matrix contain?
Use this original acceptance matrix to turn “payment works” into observable cases. The outcomes below are proposed controls, not claims that a Spout deployment has passed them.
| Case | Evidence to compare | Acceptable operational result |
|---|---|---|
| Expected successful payment | Order reference and verified transaction fields | Order follows the intended paid workflow |
| Different reference | Local expected reference against provider reference | No unrelated order is released |
| Unexpected currency | Order currency against transaction currency | Mismatch stays visible for investigation |
| Insufficient payment | Expected total against verified paid total | Fulfilment is held pending resolution |
| Unsuccessful transaction | Transaction status and customer-facing wording | No paid receipt is implied |
| Repeated notification | Same transaction linked to the order | No duplicate fulfilment action |
| Customer abandons payment | Order and provider state | Customer sees an honest incomplete outcome |
A completed test record should include the environment, input, observed state, evidence reference and defect if the result differs. Do not replace the observed result with the expected result to close a checklist.
How do you investigate a mismatch without charging again?
Start from the existing order and provider transaction. Ask whether the notification arrived, whether verification retrieved the expected transaction and which comparison failed. Separate “notification missing” from “payment unsuccessful”: they require different investigation paths.
Do not instruct the customer to pay again simply because WooCommerce still shows an unpaid state. First establish whether an existing payment succeeded. A second attempt can make reconciliation harder if the first collection later appears. This is an editorial risk scenario, not a claim about Flutterwave’s incident frequency.
Keep the original evidence intact while investigating. If someone manually changes the order state, record who changed it, why and which payment evidence supported the action. Manual editing should not conceal a broken notification route that could affect the next order as well.
A useful mismatch investigation ticket
Use the following ticket structure when escalating a problem:
Order: local reference and environment.
Provider transaction: transaction ID and merchant reference.
Expected state: currency, payment outcome and fulfilment action, without exposing credentials.
Observed state: dashboard status, verification result and WooCommerce order state.
Mismatch: the specific field or missing event, not simply “payment broken”.
Customer impact: whether goods were released, another attempt was made or a refund needs investigation.
Resolution evidence: final verified record, operator action and remaining defect.
Keep sensitive data in restricted systems and share only the minimum required through the provider’s authorised support route. Never include API secrets in the ticket.
When moving to live processing, reconfirm the account, environment and active payment methods. Preserve the test record and define who monitors unmatched payments. A successful rehearsal is evidence for that tested configuration, not a promise of uninterrupted checkout.
Discuss the requirements through Spout’s online payments service or get started with your existing account status and checkout details.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.