How to Accept Flutterwave Payments with Automated Order Tracking
How to Accept Flutterwave Payments with Automated Order Tracking
Flutterwave can collect cards, Mobile Money, bank transfers, and USSD across Nigeria, Ghana, and 30+ other African countries from a single integration. The part most guides skip is what happens after the payment — how you know about it, how you verify it’s real, and how your order records update without you checking the dashboard manually.
This is the Flutterwave equivalent of the Paystack → Make.com guide earlier in this series — the same pattern of “payment gateway fires a webhook → Make.com catches it → your systems update automatically,” applied to Flutterwave. If you’re already using that guide’s setup, the approach here is familiar. If Flutterwave is your first payment integration, this guide covers everything from account setup to automated tracking.
Three Paths to Accepting Flutterwave Payments
Before any webhook or automation, you need to be collecting payments. Flutterwave offers three distinct ways depending on your technical setup:
Account Setup: What You Need Before Going Live
Settings → API → Public Key (frontend, safe to expose)
Flutterwave Payment Methods: Ghana & Nigeria
| Payment Method | 🇬🇭 Ghana | 🇳🇬 Nigeria | Notes |
|---|---|---|---|
| Cards (Visa/Mastercard) | ✓ | ✓ | Local and international. Standard fee 2.6–4.8% depending on country/card type |
| Ghana Mobile Money | ✓ | — | MTN MoMo, Telecel Cash, AirtelTigo Money. Core method for Ghana customers |
| Bank Transfer (PWBT) | ✓ | ✓ | Nigeria and Ghana — virtual account number generated per transaction. Async — relies on webhooks for confirmation |
| USSD | Limited | ✓ | Nigeria USSD strong (GTB, Access, First Bank etc.). Ghana availability is limited — verify current status |
| Apple Pay / Google Pay | ✓ | ✓ | Available via card processing — subject to device/browser support |
| Verve cards | Partial | ✓ | Strong in Nigeria; Verve is less prevalent in Ghana |
Setting Up Webhooks for Automated Order Tracking
A webhook is how Flutterwave tells your system “this payment just succeeded” — automatically, the moment it happens, without you checking the dashboard. Without this, you find out about payments only when you log in.
Before vs After: What Order Tracking Looks Like
Step-by-Step: Webhook Setup
URL: (paste your Make.com webhook URL)
Secret hash: (create a strong unique string — save it)
charge.completed with data.status = "successful".verif-hash header containing the Secret Hash you set in Step 2. Add a filter in Make.com that checks the incoming verif-hash header against your stored secret. If they don’t match, stop the scenario — the request didn’t come from Flutterwave.Value must equal: (your Secret Hash from Step 2)
GET https://api.flutterwave.com/v3/transactions/{id}/verify with your Secret Key in the Authorization header, and check that the response status is “successful” and the amount matches what you were expecting. Only then give value.Authorization: Bearer (your Secret Key)
Check: data.status = “successful” AND data.amount = expected amount
What’s in the Flutterwave Webhook Payload
{
"event": "charge.completed",
"data": {
"id": 1234567, // Use this for verification API call
"tx_ref": "your-order-ref-001", // Your own reference — set when creating payment
"flw_ref": "FLW-MOCK-abc123", // Flutterwave's reference
"amount": 250, // In the currency below — verify this matches
"currency": "GHS",
"status": "successful",
"payment_type": "mobilemoney", // or "card", "banktransfer", "ussd"
"customer": {
"name": "Ama Owusu",
"email": "ama@example.com",
"phone_number": "0241234567"
}
}
}
The tx_ref field is one you control — set it when creating a payment link or initiating a checkout, and include your order reference there. This is how you match the Flutterwave notification back to the specific order in your system. The data.id is Flutterwave’s transaction ID — use this in the verification API call (Step 6 above).
3 Automation Recipes for Order Tracking
Every verified Flutterwave payment becomes a row in your order log — customer name, email, phone, amount, currency, payment method, transaction reference, and timestamp. Combined with the WooCommerce order log (if applicable), this gives you a complete picture of all revenue across all payment gateways in one place.
Map: data.customer.name, data.customer.email, data.customer.phone_number, data.amount, data.currency, data.payment_type, data.tx_ref, data.id
The moment a payment verifies successfully, the customer gets a WhatsApp confirmation message — “We’ve received your payment of GHS 250 for Order #001. We’ll update you when it ships.” Uses the same WhatsApp template approach from the order confirmations guide. The data.customer.phone_number from the payload is the phone field — apply the same international-format reformatting (local 0XX → international +233/+234) before passing to the WhatsApp API.
Bank transfer (PWBT) payments are asynchronous — the webhook may fire minutes or hours after the customer initiates payment. Add a filter on data.payment_type = "banktransfer" and send yourself a Telegram or WhatsApp alert with the order details so you know to prepare the order for dispatch. Combine with Recipe 1 so the order is logged regardless, and this alert is purely “action needed” for you.
Common Mistakes to Avoid
charge.completed event to your webhook URL without having actually paid. Fulfilling orders based on the webhook alone is a real fraud vector.tx_ref (the reference you set when creating the payment) is left as a generic or auto-generated value, the Flutterwave notification can’t be matched back to a specific order in your system without a manual lookup — defeating much of the automation’s purpose.tx_ref to your order number or a reference that connects directly to the order in your sheet/CRM. This is the bridge between the Flutterwave event and your order data.status = "successful" is necessary but not sufficient. A manipulated payment could succeed for a smaller amount than the product costs. Checking that data.amount equals the expected order value is the second half of the verification step.status = "successful" AND amount >= expected_amount. If either fails, stop the scenario and log the discrepancy rather than fulfilling the order.tx_ref / WooCommerce order ID) as a deduplication key — check whether a row with that reference already exists in the sheet before adding a new one. The Sheet’s lookup function or a Make.com search step can handle this.Frequently Asked Questions
What’s the difference between Flutterwave and Paystack for Ghana-based businesses?
Both support Ghana Mobile Money (MTN, Telecel, AirtelTigo), cards, and bank transfers. The practical differences are in breadth of African coverage (Flutterwave operates in more countries, relevant if you have customers outside Ghana and Nigeria), the WooCommerce plugin experience (some sellers report Paystack’s official plugin as slightly easier to configure, while Flutterwave’s offers features like split payments for marketplace setups), and secondary matters like dashboard UX and support experience. For a Ghana-only business, both are viable — many sellers run both simultaneously to maximise the payment methods available to their customers.
Do I need a developer to set this up?
For Payment Links — no, no code required. For the Make.com webhook automation — no, Make.com is visual and no-code. For Standard Checkout embedded on a custom website — yes, a developer is needed for the JavaScript integration and the server-side verification step. The WooCommerce plugin falls between: plugin installation is no-code, but some edge cases in webhook configuration benefit from developer involvement.
How long does Flutterwave take to settle funds?
Settlement timing varies by country, payment method, and your account’s settlement schedule (configurable in the dashboard). For Nigerian merchants, card payments typically settle within 24 hours; bank transfers and MoMo can vary. For Ghanaian merchants, MoMo settlement is generally faster than bank transfers. Check your specific account’s settlement settings in the Flutterwave dashboard under “Settlements” — this is separate from when the webhook fires (which is immediate on payment completion).
Can I use the same Make.com scenario for both Paystack and Flutterwave webhooks?
Technically yes — each can point to a different Make.com webhook URL, with both scenarios feeding into the same Google Sheet and notifications. In practice, keeping them as separate scenarios is easier to debug: when a payment isn’t tracked, you know immediately whether to check the Paystack scenario or the Flutterwave one, rather than tracing a shared scenario that handles both event formats. The deduplication note in the mistakes section above still applies regardless of whether you use separate or shared scenarios.
Payments In, Orders Tracked, No Manual Checks
The webhook setup and verify-before-giving-value pattern are the same discipline this series has applied to Paystack and WooCommerce — a webhook tells you something happened, the verification API call confirms it really did, and Make.com handles the downstream logging and notifications. The Flutterwave-specific details (the verif-hash header, the separate Test/Live webhook config, the tx_ref reference field) are the points this guide adds to the established pattern.
For stores running both Paystack and Flutterwave — which maximises payment method coverage across Ghana and Nigeria — both can feed the same order tracking system with separate webhook scenarios, giving you a single source of truth for all revenue regardless of which gateway processed each transaction.
More at OurInternetBusiness.com
Practical guides on automation, online business systems, and growing income from Ghana and across Africa. Visit OurInternetBusiness.com and bookmark it.
