Stop manually checking your Paystack dashboard to see who’s paid. This guide shows exactly how to wire a Paystack webhook into Make.com — with signature verification, the real payload structure, and four ready-to-build automations: order logging, payment confirmations, team alerts, and stock checks.
If you’re taking payments through Paystack, every successful transaction is an event your business should react to — log the order, confirm to the customer, alert your team, update stock. Without automation, that means logging into the Paystack dashboard repeatedly throughout the day and manually copying details into a spreadsheet or messaging the customer yourself.
Connecting Paystack to Make.com closes that gap. The moment a payment succeeds, Paystack sends a webhook — a small HTTP message — to a URL you control. Make.com receives that message and runs whatever automation you’ve built: adding a row to Google Sheets, sending a WhatsApp confirmation, posting to a Telegram group, or anything else Make.com can connect to (which is most things).
One webhook, unlimited downstream automations
Make.com offers two routes to Paystack data: the native Paystack app module (built-in connector) and a Custom Webhook that Paystack pushes data to directly. They solve slightly different problems, and most real automations end up using both.
| Approach | How it works | Best for | Real-time? |
|---|---|---|---|
| Custom Webhook (recommended starting point) | Paystack pushes a JSON payload to a Make.com webhook URL the instant an event happens (e.g. payment succeeds) | Reacting to events — new payments, refunds, transfers | ✅ Yes — instant |
| Native Paystack App Module | Make.com connects to your Paystack account via API key and can fetch data (list transactions, check status) or perform actions on a schedule or as part of a scenario | Looking up additional details, periodic checks, or actions like creating a transfer recipient | Depends — usually scheduled or triggered by another step |
https://hook.make.com/abc123...).charge.success, transfer.success, refund.processed, and others depending on your account activity. Add a Filter immediately after the webhook trigger: click the small filter icon on the connection line, set the condition to check the payload’s event field, and set it to equal charge.success (or whichever event your automation should react to). This stops the scenario from running for irrelevant events.x-paystack-signature — a hash computed from the request body using your Paystack secret key. To verify: add an Iterator/Tools module that computes an HMAC SHA512 hash of the raw request body using your secret key, and compare it to the value in the x-paystack-signature header. If they don’t match, add a Filter to stop the scenario.When a charge succeeds, Paystack sends a JSON payload to your webhook URL. The structure looks roughly like this (simplified — actual payloads include additional fields):
{
"event": "charge.success",
"data": {
"id": 4099797291,
"reference": "T123456789",
"amount": 500000, // amount in kobo/pesewas (÷100 for GHS/NGN)
"currency": "GHS",
"status": "success",
"paid_at": "2026-06-12T14:32:00.000Z",
"channel": "mobile_money",
"customer": {
"email": "customer@example.com",
"first_name": "Ama",
"last_name": "Owusu"
}
}
}
The fields you’ll use most often in automations: event (to filter on charge.success), data.reference (a unique transaction reference — useful as a lookup key in your order sheet), data.amount (remember to divide by 100 — Paystack amounts are in the smallest currency unit), data.channel (tells you whether the customer paid by card, bank transfer, or mobile money), and data.customer.email (or phone number, if collected, depending on your checkout setup).
x-paystack-signature header contains an HMAC SHA512 hash of the raw request body, generated using your Paystack secret key. Verifying it confirms the payload genuinely came from Paystack and hasn’t been tampered with in transit. Your Paystack secret key is found in the same Settings → API Keys & Webhooks page where you added the webhook URL — never share this key or expose it in a public Make.com scenario template.
Each of these extends the same Custom Webhook trigger from the setup above — add the filter and signature check once, then branch into whichever (or however many) of these you need.
The most common starting automation — every successful payment becomes a new row in your order tracking sheet automatically, with no manual entry.
Map: data.reference → Order ID column, data.customer.email → Customer column, data.amount ÷ 100 → Amount column, data.paid_at → Date column, data.channel → Payment Method column. Set a default “Pending” value in your Order Status column for fulfilment tracking.
The moment payment clears, the customer gets a confirmation message — improving trust and reducing “did my payment go through?” follow-up messages.
Use Make.com’s HTTP — Make a request module to call your SMS/WhatsApp provider’s API (Termii, Africa’s Talking, or a WhatsApp Business API provider). Compose the message text using data.customer.first_name and data.reference: “Hi {{name}}, we’ve received your payment of GHS {{amount}}. Your order reference is {{reference}}. Thank you!”
Useful for solo sellers and small teams — a notification appears the second money comes in, including the amount and what was purchased (if your checkout passes product info in metadata).
Create a Telegram bot (via @BotFor in Telegram, takes 2 minutes), add it to a private group, then use Make.com’s Telegram module to send a formatted message: “💰 New sale! GHS {{amount}} from {{customer.email}} — Ref: {{reference}} — via {{channel}}.” Slack works the same way using Make.com’s Slack module instead.
If your checkout passes which product was purchased in Paystack’s metadata field (custom data you attach when initiating the transaction), this recipe automatically reduces the stock count in your inventory sheet and sends an alert if stock drops below a threshold.
This recipe is more advanced because it requires your checkout flow to send product identifiers in data.metadata — if you’re using a simple payment link without custom metadata, this field may be empty and this recipe won’t have the data it needs. Sellers using Zoho Inventory or similar dedicated tools may prefer to handle stock decrements within that platform instead, using Recipe 1 purely for the order log.
One question — a suggested sequence based on your current setup
—
| Issue | Likely Cause | Fix |
|---|---|---|
| No data arrives in Make.com | Scenario wasn’t in “listening” mode when the test payment ran, or webhook URL wasn’t saved in Paystack | Click “Run once” in Make.com before triggering the test payment. Re-check the webhook URL field in Paystack settings was saved (not just typed and navigated away from). |
| Scenario runs but nothing happens downstream | The event filter is blocking everything, including the event you expected | Temporarily remove the filter, run a test, and inspect the actual event value in the payload — it may differ slightly from what you expected (check exact spelling/case). |
| Amount shows as 50000 instead of 500 | Paystack amounts are in kobo/pesewas (smallest currency unit), not in GHS/NGN directly | Add a simple math operation in the field mapping: divide data.amount by 100 before writing it to your sheet or message. |
| Works in Test mode, nothing in Live mode | The Live mode webhook URL field in Paystack wasn’t updated, or you’re still using the test API keys for signature verification | Confirm both the Live webhook URL is set AND, if doing signature verification, that you’re using your Live secret key (not the test secret key) for the HMAC calculation. |
| Signature verification always fails | The HMAC is being computed on a modified/re-serialized version of the body rather than the exact raw bytes Paystack sent | Ensure the signature check uses the raw request body string exactly as received — re-formatting or re-parsing the JSON before hashing will produce a different hash than Paystack’s. |
| Make.com free tier operations running out | Each module execution within a scenario run counts as an operation — a scenario with many modules consumes multiple operations per payment | Combine steps where possible (e.g. one HTTP module instead of several), or upgrade to Make.com’s Core plan (~$9/month for 10,000 operations) once volume justifies it. |
event field, your scenario runs for every webhook Paystack sends — including refunds, failed charges, and transfer events — potentially logging a “refund” as if it were a new sale, or sending a payment confirmation for a failed transaction.event equals exactly the event type your automation is designed for (typically charge.success).5000 in the raw payload. Logging or messaging this number without dividing by 100 makes every recorded amount appear 100× too large.data.amount by 100 when mapping it into sheets, messages, or any downstream system. Double-check this with a real test transaction of a known amount.No — everything in this guide is point-and-click within Make.com’s visual interface and Paystack’s dashboard settings. The most technical step is signature verification (Step 5), which involves an HMAC calculation — Make.com has built-in functions for this, and template scenarios that include signature verification are widely shared in Make.com’s community, which can be adapted rather than built from scratch. If you’re not comfortable with Step 5 initially, recipes for internal-only notifications (Recipe 3) are reasonable to run without it while you get comfortable with the rest of the setup.
The same overall pattern applies — Flutterwave also supports webhooks that POST to a URL you provide, with its own signature verification mechanism (a secret hash you set in your Flutterwave dashboard, sent back in a verif-hash header for you to compare). The specific payload structure and field names differ from Paystack’s, so the field mappings in Steps 3 and 6 would need to be redone based on Flutterwave’s payload, but Make.com’s Custom Webhook trigger works identically as the entry point for either provider.
Paystack retries webhook delivery if it doesn’t receive a successful response, so a brief outage on Make.com’s side typically doesn’t mean a permanently lost event — Paystack will attempt redelivery. That said, webhooks should be treated as a convenience layer for automation, not the sole record of a transaction — your Paystack dashboard remains the authoritative record of all payments regardless of whether downstream automations ran successfully, which is why periodic spot-checks (mentioned in the mistakes section) matter.
Yes — the payload includes a data.channel field (values like card, mobile_money, bank_transfer). Add an additional filter or a Router module (Make.com’s branching tool) after your main event filter to send card payments down one path and Mobile Money payments down another — useful if, for example, you want different confirmation message wording depending on how the customer paid.
The temptation once this is working is to build everything at once. Don’t — get Recipe 1 (order logging) working end to end first, including the signature verification if your automation will touch customer-facing actions. Once that’s reliable, adding Recipes 2–4 to the same scenario is straightforward, since the trigger, filter, and security check are already in place. Each additional recipe is then just a few more modules branching off the same foundation.
Practical guides on automation, online business systems, and growing income from Ghana and across Africa. Visit OurInternetBusiness.com and bookmark it.